Coder Social home page Coder Social logo

cacao-zcap-rs's People

Contributors

chunningham avatar clehner avatar cobward avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cacao-zcap-rs's Issues

Representing allowedActions

@chunningham wrote in spruceid/cacao-zcap#6 (comment):

https://github.com/spruceid/cacao-zcap/blob/158613b784c189685cdf22203bccebc62419f935/index.html#L220
when we delegate, we often delegate multiple capabilities at once (e.g. read + write) for multiple resources. this is currently represented in the siwe message as a set of resources <resourceUri>#<action>. in zcaps it seems that restricting to a single URI is common, but allowing for multiple actions via allowedActions: string[]. this would again map to a set of resources with a common base. if we interpret only the first resource as the invocationTarget without additional context like allowedActions, we will need more SIWE flows per login/initial session key delegation (e.g. 5 for space drop, read + write + delete + list + metadata)

I also see that zCaps are using a single invocationTarget; although it doesn't look like that is required (maybe an array could be used for invocationTarget); there is just one allowedActions property though, not a per-invocationTarget allowedActions, so I would assume if there are multiple invocation targets that the allowed actions intended to apply to all of them. That should still work with attenuation.

Currently allowedActions is not mentioned in CACAO-ZCAP. Since delegations attenuate capabilities, I would interpret it that by default all actions allowed (unless the application requires the allowed actions to be listed explicitly, in which case this doesn't work). So a delegation without allowedActions could be subdelegated with a non-CACAO ZCAP using allowedActions. But that does not help if the goal is to delegate only specific allowed actions in the first delegation.

Using action strings as fragments in the resources array looks like a possible solution; but it doesn't look to me like a correct use of URIs.
The meaning of the fragment is supposed to be specific to the media type of de-referenced resource: https://datatracker.ietf.org/doc/html/rfc8820#section-2.5. Typically it refers to a subset of the resource. But the resources we are referring to as invocation targets I assume could be arbitrary file types. We would also have to exclude resources with fragments from being themselves invocation targets (as multiple fragments is not valid in a URI).

With the resources array being used for the capability chain (root delegation id, embedded parent delegation (#6), other previous delegation ids, and possibly a type/specification identifier (#7))... we could possibly detect a repeated invocation target URI with different fragment identifiers corresponding to actions, but I'm not sure it would be good idea, for the reasons above.
Alternatively, actions could be represented elsewhere in the resources array and/or in the statement.
Some possibilities:

  1. Reserve the array entry following the invocation target to be for a list of actions
    • A list as a URI seems non-idiomatic. What would the URI scheme be?
  2. Each array entry following the invocation target up to the next delegation could be an action URI.
    • The next delegation is detected by its use of a UUID URN (and/or data URL in #6). Action URIs could then be defined to be not UUIDs or data URLs.
  3. Each N resources following the invocation target could be action URIs, where N is mentioned in the statement in some structured way.
  4. Represent allowed actions fully in the statement string.
    • The statement string should probably then not be passed through into the ZCAP but would need a syntax defined (generically, or per-application, or in an extensible way?)

CID -> UUID for delegation id

w3c-ccg/zcap-spec#39 proposed to use UUID URNs for delegation ids, and not other schemes: w3c-ccg/zcap-spec#39 (comment).
CACAO is defined as an IPLD data structure, which has a CID (content hash) [Actually it can have many CIDs, per serialization format and hash algorithm... I'm not sure if one can be defined as canonical, or if that does not matter].
We could define a mapping to [serialize the CACAO to a specific kind of CID, then] convert the CID into a UUID, and use that as the delegation id.
The requestId CACAO parameter (currently used as delegation id) could then be passed through into the delegation or proof as a new property.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.