I've commented on the tag issue several times at this point, but I will
share it here one more time:
W3C DIDs and W3C VCs are both taking a normative dependency on multiple
structured suffixes:
- https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/
multiple structured suffixes is code for polyglot data types:
- https://tess.oconnor.cx/2023/09/polyglots-and-interoperability
expect to see a lot of "+ld+json" registrations in the future based on:
- https://w3c.github.io/json-ld-syntax/#structured-extension-ld-json
- https://datatracker.ietf.org/doc/draft-ietf-mediaman-standards-tree/
- https://www.w3.org/TR/activitypub/#retrieving-objects
- https://w3c.github.io/vc-data-model/#iana-considerations
- https://www.w3.org/TR/did-core/#application-did-ld-json
Regardless of your opinions on the details of building good media types...
DID Resolvers satisfy an interface that looks like this:
StringOrURI => Media Type.
IPFS / IPLD also have an interesting relationship to media types, in that
unlike HTTPS URLs,
you can't negotiate for a different representation, since the content
identifier encodes the representation... that's why I put "StringOrURI" in
the above interface.
For example:
- https://did-ipid.github.io/ipid-did-method/
- https://w3c-ccg.github.io/did-method-key/#secp256k1
You could "resolve" both of these without processing the "did:method:"
prefixing... that's what implementations do internally today... then they
containerize / transform the result and return it as application/json or
application/ld+json.
This leads to weird behavior where you can negotiate a JWK from a
multicodec encoded did:key... which you probably need to do a lot since
nobody understands multicodec keys right yet.
OS
On Thu, Oct 12, 2023 at 1:07 PM Robin Berjon <robin@berjon.com> wrote:
> On 05/10/2023 21:43, Orie Steele wrote:
> > This led to `application/did+json` being exactly the same as
> > `application/did+ld+json` except with broken / non functional RDF
> interop.
> >
> > I wonder if the charter might resolve this issue of serialization
> > formats before working group members get committed to working on an
> > abstract data model that is exclusively defined in RDF.
> >
> > I'd be supportive of scoping the charter to only JSON-LD / RDF, I'd
> > prefer to not see the work chartered without consensus on doing 1 media
> > type very well, based on the last working group experience.
>
> This is a relatively minor point and I won't block based on it, but if
> we're chartering the group to touch media types, I'd suggest abandoning
> the old authoritative metadata antipattern and aligning on a media type
> for JSON resources that would interoperate well with the rest of the
> web: application/json.
>
> See https://hackmd.io/@robin-berjon/what-did-you-do for earlier notes on
> the issue.
>
> --
> Robin Berjon (he/him)
> Governance & Standards at Protocol Labs
> https://berjon.com/ - https://bsky.app/profile/robin.berjon.com
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>