[Openid-specs-ab] SIOPv2 Use Case question

[David Waite]

> On Apr 15, 2022, at 11:14 AM, George Fletcher via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> I've been reading through the SIOPv2 spec and wondering what the work
> group thinks is the best way to handle the following use case.
> 
> There is an existing RP that already supports "Sign-in with Google" and
> "Sign-in with Microsoft" via OpenID Connect. The RP want's to support
> Self-Issued OpenID Providers as well.
> 
> This leads to the following questions:
> 
> 1. What is the best way to make this option available to the users of the RP?

This depends a lot on the specifics of their use case. If they are just using these as authentication factors, they can use SIOPv2 via a button which kicks off an ‘openid’ scheme link, and not ask for any VCs to be presented.

If they are going to request VCs, They could use the ‘openid’ URL scheme, but there is no guarantee the SIOP will be able to handle their request. 

Our vision is that there are trust frameworks which define rules (and corresponding metadata) for what is supported, including what credentials are supported. These could be invoke their own URL scheme, or a App Link/Universal link to ‘claim’ a HTTPS URL. Such claimed URL can be mapped to multiple native applications, allowing one of many wallets to be invoked. If there is no native software, there is the benefit of the actual HTTPS page being loaded in the browser as a fallback, for instance to present user instructions and provide a ‘cancel’ button that returns to the RP.

> How does the RP know which wallets the user might have? 


We still haven’t solved this NASCAR problem, and both websites and RP applications are sandboxed from seeing details on what else is available on the system. URL-based invocation using URL schemes is a leap of faith - it either works or it fails. Failure might be due to no suitable app being available.

Longer term, I hope the platform provides mediation in much the same way that account chooser provided. With URL-scheme-based or AppLink-based invocation, we can only inherit the current behavior of the underlying platform.

> Does the RP need to pre-select only working with a few wallets and ignore the others?

So far, we have detached decisions based on issuer URL and associated authorization endpoint and instead operate based on prior interactions with the RP. So the vision for our SIOP implementation is that you could invoke with (hypothetically) a ‘openid:’ scheme, or with a ‘https://ping-wallet.com <https://ping-wallet.com/>' authorization endpoint, or with a customer-specific App Link. All three would put the choice of how to respond in the hands of the user, and all three responses would wind up looking similar (although with different op identifiers per the newest proposal).

In this scenario, the ‘ping-wallet’ system would only open that one wallet, and could be behind a branded button. In practice, I suspect this is only really ideal for testing and demonstrations. The flexibility above in responding in very similar ways to different invocations is meant to reduce impact of migrating away from someone launching with a ‘button per wallet’ NASCAR approach.

> 2. The RP will need to handle a "registration" event for the user of the SIOP. Is that an explicit event vs an implicit one? During registration the RP needs some set of claims while during normal authentication events, the RP just needs to have the SIOP solve the authentication request.

An RP which wants to distinguish between registration UX and authentication UX would make two different style requests, same as OIDC today. 

I would expect that wallets would optimize the UX they present to the user for consent to indicate that the user is repeating an action that they have given consent for in the past, but there is no requirement for them to do so within core spec.

> 3. How does the RP know what verifiable claims the wallet might be able to provide? As an RP self-asserted claims may not be sufficient.

Alluded to above, another supported issuer URL could correspond to additional capabilities/requirements for wallets beyond https://self-issued/v2 . This wouldn’t let you know before redirect that a SIOP _has_ the credential, but invoking via the authorization endpoint of this other issuer URL would let you know you are invoking a wallet that at least has the capability of answering your question correctly. 

A trust framework may also define how wallets should deal with the case where they do not have the credential, such as presenting user instructions or guiding them toward an inline a credential issuance flow.

> 4. What if self-asserted claims are sufficient but the SIOP wallet doesn't support the required requested claim in the authentication request?

I don’t entirely understand this question, sorry.

> 5. The user may have a "merge" required (say RP requested email address and the one provided in the response matches an existing identity at the RP). Are there any unique aspects to "merging" when leveraging "SIOPv2"?

There are with OIDC4VP. A VC IMHO is closer to identity proofing or a verified document than it is to authentication. If I use a new wallet it may be using different subject identifiers to represent the user - but if I include a VC, the RP might evaluate that and decide that this ’new user’ is actually likely an existing user - then steer them down prompts and additional checks before associating the new subject with an existing account.

> 6. If a user loses access to their SIOP, how does the RP support recovery? Should registration require additional identification and authentication methods to allow the user to recover their account in a more traditional way?

1. There are separately ideas of wallet backup and recovery, which would include hosting information in a vault. Such vaults might allow multiple SIOPs to use the same data. These are all out of scope

2. When using DIDs for the subject identifier, there is an abstraction. If the DID is not exclusively owned and managed by the wallet, the user may have another means to prove ownership of the DID and recover at that level.

3. A verifiable credential can be used to make identity proofing decisions, per above, as part of an account recovery process. I may need to go through an authentication or recovery process with the _issuer_ of the VC in order to have it within my new wallet.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220415/57f6a67e/attachment.html>