-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registry inclusion criteria #58
Comments
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: 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:
|
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 |
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. |
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:
|
+1 |
First stab at some 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.
The text was updated successfully, but these errors were encountered: