Registry inclusion criteria about digital-credentials HOT 8 OPEN

Thinking more about this, I am not sure it makes sense to create a registry at all.

The other thing that I think is worth considering is that the more protocols we have, the fewer interoperable implementations we'll have, and fragment the ecosystem. So, more here isn't necessarily better.

from digital-credentials.

Thanks @OR13! Adding for reference:
https://www.w3.org/2021/Process-20211102/#registries

Which defines the W3C requirements for a Registry.

We can copy/🍝 and adapt the text from the Permissions Registry, which should be similar enough.

from digital-credentials.

For some inspiration: https://datatracker.ietf.org/doc/html/rfc8126#section-4.6

I would suggest assigning some experts, and writing advice for them directly into the spec for the registry.

The advice can be simple, or complicated. I would recommend not allowing "links to expired drafts, or drafts from SDOs that do not represent consensus", this would exclude CG reports, and I-Ds.

from digital-credentials.

Just from call on Feb 8:

• selective disclosure
• encrypted response
• Structure that is "Web IDL" compatible.

from digital-credentials.

Protocol needs to provide detail in the query such that the browser can understand what is a compatible credential and what are the specific data elements being requested, such that the UA can help the user to understand the request prior to selecting a wallet/credential.

from digital-credentials.

Protocol needs to enable passing an indication to the user to explain the context of the request (who is requesting it, why, with what privacy protections, etc.), and/or the elements in the webpage that provided that information.

from digital-credentials.

To expand on the last point from @marcoscaceres here which I believe was related to a point I raised. It would be a failure if say the response from the .get() API for a specific protocol expected additional out of band steps for the relying party to actually get the response, such as following a redirect or calling an API etc. I'm unsure how to articulate that as a crisp registry requirement at the moment though.

from digital-credentials.

Thinking more about this, I am not sure it makes sense to create a registry at all.

Instead it might be better to internalize a fixed set of supported protocols, and require a full document update in order to add further support.

If there is more than 1 protocol listed, there MUST be a single mandatory to implement.

from digital-credentials.