Add initial spec #57
Add initial spec #57
Conversation
marcoscaceres
force-pushed
the
initial_spec
branch
from
f5269ff to
49383bd
Compare
marcoscaceres
requested review from
samuelgoto,
RByers,
timcappalli and
hlozi
marcoscaceres
force-pushed
the
initial_spec
branch
from
49383bd to
096d655
Compare
index.html
Outdated
| </h2> | ||
| <pre class="idl"> | ||
| partial interface CredentialsContainer { | ||
| Promise<DigitalCredential> requestIdentity(IdentityRequestOptions options); |
There was a problem hiding this comment.
Reiterating from the call: It may be useful to abstract the DigitalCredential return type here and design an algorithm that both FedCM and DigitalCredential can hook into to provide identities. That way FedCM can intermingle in UI with 3-party ids and also with WebAuthN, but mDLs and WebAuthN can't be requested interchangably, which was the motivating concern for this API shape IIRC.
There was a problem hiding this comment.
I haven't read the FedCM spec yet... but yeah, so long as this can be a generic thing without a normative requirement on FedCM, then that works.
I'm imagining DigitalCredential (or whatever we end up calling it) will end up in the Credential Management spec eventually.
There was a problem hiding this comment.
That sounds perfect. That just means FedCM would subclass DigitalCredential, in the same way it currently subclasses Credential and would put itself in the registry.
I agree that the generic DigitalCredential (or whatever) would live well in the Credential Management spec.
There was a problem hiding this comment.
Can we try to agree with the goals here first?
both FedCM and DigitalCredential can hook into to provide identities
This matches much of my intuition, and it is what Chrome would like to see this design converge to.
@marcoscaceres, does this match your intuition?
There was a problem hiding this comment.
I don't have a strong opinion (because I'm still not very familiar with FedCM). If both specs can use the same thing, then great. However, the challenge remains with .get() conflating requesting multiple credential types, and it's impossible for an implementation to distinguish (because they are all part of the same CredentialCreationOptions dictionary).
In the Extensions Points section, the CM spec encourages spec authors to define "a reasonable mechanism for dealing with requesting credentials of distinct types", which is what .requestIdentity() is trying to do, and then to pitch that to the Web App Sec WG.
I think we need to document our options here #61 and present our options to the Web App Sec WG to help us decide what the right course of action is here.
I think we have general agreement that this poses issues:
const opts = { publicKey , identity, providers };
// who wins? what happens? What UI gets shown?
navigator.credentials.get(opts);Which, again, is the core of the problem - which the CM spec acknowledges is a problem, by asking for "a reasonable mechanism for dealing with requesting credentials of distinct types."
The . requestIdentity() disambiguates the problem by providing a unique method signature, only allowing this new DigitalCredentialRequestOptions dictionary, which deliberately does not inherit from CredentialRequestOptions to avoid its limitations, while providing the same functionality (i.e., it's built for purpose).
There was a problem hiding this comment.
Just as tl;dr: let's move this discussion to #61
There was a problem hiding this comment.
Ok, I think we arrived at a good conclusion on #61. This issue here is now resolved from where I stand, and since we are following @bvandersloot-mozilla 's suggestion, I think it would be consistent with his thoughts. @marcoscaceres is there anything else that you think is actionable here?
There was a problem hiding this comment.
I'm happy to proceed. Let's do additional discussions in a follow up.
Co-authored-by: sam goto <samuelgoto@gmail.com>
Co-authored-by: sam goto <samuelgoto@gmail.com>
Co-authored-by: sam goto <samuelgoto@gmail.com>
Co-authored-by: sam goto <samuelgoto@gmail.com>
Co-authored-by: Orie Steele <orie@or13.io>
There was a problem hiding this comment.
This PR really captured what I think is a design that will reconcile many different aspects of the space: reconciling the two party model with the three party model, reconciling the distinction between identity verification and sign-in, reusing the Credential Management spec and algorithms, etc.
I made some comments to try to clarify what I think is already shared understanding.
The backbone and the structure of this PR is solid. I'm playing with the code to see what would be involved in implementing, but my intuition is that this would set us in the right long term direction.
@bvandersloot-mozilla WDYT?
| TBW | ||
| </p> | ||
| <h2> | ||
| Model |
There was a problem hiding this comment.
We are operating at the browser level, so our definition of "Credential" (in the Credential Manager sense) is different than other group's definition of "Credential", but there are many other concepts that I think are well articulated by the ISO and Verifiable Credentials community.
Here is one example of a data model that I think has a lot of good definitions.
I'm wondering if we are going to get held back agreeing on these definitions, and if we are better off just having the WebIDLs in this initial PR to unblock implementation ... WDYT?
Happy to go either way, but my intuition is that the WebIDL without the definitions more minimally viable.
There was a problem hiding this comment.
Let's run with this for now but let's definitely start taking definitions/concepts from other specs if we can. However, we should control whatever we feel strongly fall squarely in the purview of our spec.
Co-authored-by: sam goto <samuelgoto@gmail.com> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: sam goto <samuelgoto@gmail.com>
Co-authored-by: sam goto <samuelgoto@gmail.com>
|
retroactive LGTM as well, I like this direction. Thanks Marcos and Sam! |
|
Is the "rendered" version of this available and if so where? (sorry if that's an ignorant question - I am largely unfamiliar with w3c tooling and stuff) |
|
Thanks @samuelgoto ! |
|
Renamed it to https://wicg.github.io/digital-identities/ ... to match the new spec title. |
Adds the initial spec based on latest proposal.
closes #61
💥 Error: 502 Bad Gateway 💥
PR Preview failed to build. (Last tried on Feb 3, 2024, 12:42 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.