search

oauth-wg / oauth-sd-jwt-vc

draft-terbu-sd-jwt-vc
Creative Commons Zero v1.0 Universal
20 stars 12 forks source link

Consider supporting IPLD links in vct field #211

Closed oed closed 5 months ago

oed commented 9 months ago

Currently the value for the vct field is defined as follows:

The vct value MUST be a case-sensitive StringOrURI (see [RFC7519]) value serving as an identifier for the type of the SD-JWT VC.

This puts some unfortunate limitations on how the vct can be represented. IPLD is a data format that allows developers to represent "merkle dags", essentially arbitrary hash linked data structures. A key concept within IPLD is the concept of a link, which is represented using the hash of the linked content (encoded as a "CID"). Specifically for dag-json, an link is represented as follows (example below points to a wikipedia mirror):

{
  "wikipedia": { "/": "bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze" }
}

It would be great if the vct could be represented as an immutable object referred to as a hash, and retain compatibility with existing IPLD tooling. Therefore, it would be great if the spec for vct could be extended to support the following:

{
  "vct": { "/": "bafymyhash..." }
}

An alternative approach that would be compatible with the current vct spec would be to represent the hash as an ipfs url, e.g. ipfs://bafymyhash.... However, this would mean that compatibility is broken with existing tooling such as explore.ipld.io

danielfett commented 9 months ago

I think using the URL would be the appropriate way here:

oed commented 9 months ago

it avoids us having a dependency on IPFS specs,

Doesn't need to rely on the IPFS spec, just need more flexibility

it is self-describing and I suppose a resolving strategy is defined somewhere, and finally

It would break resolution in IPLD though. Generally you can query through an IPLD graph with a path: <cid-object1>/field/object2/field where field of object1 contains a CID. This works if the CID conforms to the IPLD data model, but not if you are using ipfs://<cid>

danielfett commented 9 months ago

it avoids us having a dependency on IPFS specs,

Doesn't need to rely on the IPFS spec, just need more flexibility

Changing this would have a lot of consequences for the spec, and if we wouldn't refer to the IPFS spec, allowing this flexibility without a good reason is a hard sell.

it is self-describing and I suppose a resolving strategy is defined somewhere, and finally

It would break resolution in IPLD though. Generally you can query through an IPLD graph with a path: <cid-object1>/field/object2/field where field of object1 contains a CID. This works if the CID conforms to the IPLD data model, but not if you are using ipfs://<cid>

I'm not really familiar with the IPFS concepts, so please excuse my ignorance, but from the outside, what you describe seems like a shortcoming of the URI scheme to me. Or is there something I'm missing?

danielfett commented 5 months ago

There has been some discussion on this here: https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/231#discussion_r1601608898

My questions above are still open - please address @oed

oed commented 5 months ago

@danielfett so this issue actually got resolved by a PR to the dag-jose codec spec: https://github.com/ipld/ipld/pull/326 Essentially making the jose spec use ipfs://<cid> instead of the object approach.

The issue described in #231 is different, basically it wants to avoid a self reference on the vct field since that's incompatible with content addressing.