Skip to content
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

Open
marcoscaceres opened this issue Jan 25, 2024 · 12 comments · May be fixed by #157
Open

Registry inclusion criteria #58

marcoscaceres opened this issue Jan 25, 2024 · 12 comments · May be fixed by #157

Comments

@marcoscaceres
Copy link
Collaborator

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.

@OR13
Copy link
Contributor

OR13 commented Jan 25, 2024

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.

@marcoscaceres
Copy link
Collaborator Author

marcoscaceres commented Jan 27, 2024

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.

@marcoscaceres
Copy link
Collaborator Author

marcoscaceres commented Feb 8, 2024

Just from call on Feb 8:

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

@npdoty
Copy link

npdoty commented Feb 8, 2024

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.

@npdoty
Copy link

npdoty commented Feb 8, 2024

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.

@tplooker
Copy link

tplooker commented Feb 8, 2024

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.

@OR13
Copy link
Contributor

OR13 commented Feb 8, 2024

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.

@samuelgoto
Copy link
Collaborator

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.

@timcappalli
Copy link
Member

From #43:

support for selective disclosure could be mandated to be included in the registry for "protocol"

@Sakurann
Copy link
Contributor

Sakurann commented Aug 1, 2024

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

@marcoscaceres marcoscaceres linked a pull request Aug 7, 2024 that will close this issue
@marcoscaceres
Copy link
Collaborator Author

First stab at some inclusion criteria:
#157

@marcoscaceres
Copy link
Collaborator Author

@npdoty, @OR13, and @Sakurann, would really like your input on #157 as it would affect you/the groups you are involved in directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants