digital-credentials
digital-credentials copied to clipboard
WICG
Registry inclusion criteria
We need to come up with a registry governance and inclusion criteria.
For inclusion, at a minimum, there should be implementation support, and we talked about having some privacy checks too.
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.
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.
Just from call on Feb 8:
- selective disclosure
- encrypted response
- Structure that is "Web IDL" compatible.
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.
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.
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.
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.
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 #43:
support for selective disclosure could be mandated to be included in the registry for "protocol"
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.
+1
First stab at some inclusion criteria: https://github.com/WICG/digital-credentials/pull/157
@npdoty, @OR13, and @Sakurann, would really like your input on #157 as it would affect you/the groups you are involved in directly.
I'd like to see the part(s) that talk about the "specification MUST be a stable URL that points to the authoritative source for the protocol, including validation rules" also include some criteria about the authoritative source at that URL being open and freely available.
There's been a lot of talk about developer ergonomics in the context of these protocol identifiers. One of the least ergonomic things a developer can run into is hitting a pay-walled document when just trying to do their job.
Would a lack of open documentation for developer reference preclude inclusion of e.g. mdoc-related identifiers from the registry? I'm not saying I agree or disagree with that, just thinking through potential implications.
Would a lack of open documentation for developer reference preclude inclusion of e.g. mdoc-related identifiers from the registry? I'm not saying I agree or disagree with that, just thinking through potential implications.
Only to the extent that ISO would choose to make such document(s) available at a cost.
@MasterKale
Would a lack of open documentation for developer reference preclude inclusion of e.g. mdoc-related identifiers from the registry? I'm not saying I agree or disagree with that, just thinking through potential implications.
No. There's nothing preventing MDN (or anyone really) from writing documentation.
@bc-pi
Only to the extent that ISO would choose to make such document(s) available at a cost.
Right, or maybe for free? Or something the community documents on MDN? (I don't know if they would have any issue with that).