Advanced flow for OpenID4VP

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1401

Original Reporter: tlodderstedt

The current cross device flow works fine, however it forces the RP to make assumptions about the SIOP/wallet the user might choose to process the SIOP request.

I propose to investigate an advanced flow that involves an advertisement/discovery step and allows Rp and SIOP to better adjust the flow to each others capabilities.

The RP could render a QR code that give rise to its capabilities and endpoints. The user then scans that QR code with the wallet of her choice.

The wallet uses the QR code data and send a request to the RP containing its capabilities and endpoints/identifiers in a direct HTTPS POST request.

In the HTTPS POST response, the RP directly sends with the authentication request data (tailored for the particular SIOP).

As already noted, this flow would allow the RP and the SIOP to tailor the requests to each others capabilities. Also, the QR code could potentially be static and concise.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

This sounds similar to the Condatis approach. It should also help to alleviate phishing attacks because the user will presumably know the DNS name of the web site displaying the QR code and this can be compared to the URL contained in the QR code, so that if the QR code is replaced by a phisher’s URL there will be a mismatch that will be visible. Its not foolproof, but could we add rules to the format of the QR code to make it more difficult for a phisher to replace?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwaite40

I think this approach, defined appropriately as a new protocol, would be much better than the current response_mode approach.

If I POST my OP metadata to get a request, I should just POST the response back to the same place once I’m done without the variability of front-vs-back-channel redirects, redefinition of redirect_uri as an API endpoint vs web endpoint, etc.

It also can be applied to non-SIOP use cases, e.g. the QR code could just take me to a page for a more stock ‘log in on your phone’ authentication flow.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

This is the Condatis approach David C. is referring to: https://bitbucket.org/openid/connect/issues/1212/siop-chooser#comment-61693433

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

2022-01-27 call, agreed to create a PR, and continue discussion there

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Is this about

1. differentiating whether cross-device flow or same-device flow is being used?

   1. those have different protocol implications (HTTP POST vs redirect, etc.) and I don’t think SIOP currently has a clear way of differentiating the two - in the lack of such mechanism, our implementation, for example, supports only cross-device flow to accommodate more use-cases.

2. or about differentiating between SIOPs

   1. preventing NASCAR screen - SIOP chooser, Condatis approaches

I think those are different topics and by re-reading the issue/comments it was not clear which one we are talking about..

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

bringing this issue up again as we agreed to come back to it after we extend SIOP to support not just Implicit flow.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

@{557058:64689aae-f6d2-4db5-b56a-8b21020634d2} suggested using DID Documents to discover metadata as an option.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Using DID Documents opens up the flood gates to hundreds of different ways to discover metadata. I think the use of DIDs is not a particularly good idea as it leads to many different islands of (non)interop. Having a single defined method is the best approach in my opinion.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

the proposed flow is exactly an ISO mDL flow.. where step 1 is mainly used to 1/select between protocols to use (BLE/NFC/Wifi Aware, etc) and exchange ephemeral keys to enable applicaiton level end-to-end encryption of the entire step 2, as opposed to communicating metadata for one specific protocol.

step 1

• velifier → wallet: “here are my capabilities and endpoints“.

• wallet → verifier: “here are my capabilities, endpoint (?), identifiers”

step 2

• verifier → wallet: Authorization Request

• wallet → verifier: VC/VP

in OID4VP, we already enabled a lot of flexibility for the verifiers to communicate metadata both within and before sending an Authorization Request. for the wallet, right now it is either pre-discovery or static metadata which i agree seems a little inflexible, but i always thought that the ultimate decision making was left to the wallet to choose formats/crypto within the range of what verifiers support (just like AS makes an ultimate decision).

I quesiton if we need this advanced flow.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: gffletch

Is it possible that the requirements of the verifier could change based on the request? If thinking about this in the context of a browser navigating to the verifier, the verifier could run a risk assessment on the browser connection and based on that risk assessment have a different set of requirements the wallet needs to meet. If so, then I’m not sure discoverable metadata is sufficient.

I also believe that for many RPs/verifiers as they roll out support for wallets will chose to first require the user to enter a login_id of some ilk and then transition to the QR code for the authorization request. This allows the verifier to apply some additional per user risk assessment before issuing the authorization_request to the wallet.

As long as the current specs allow for per transaction adjustment of the authorization_request based on the context of the request or the “user” involved, then we probably don’t need an advanced flow. However, I do believe this dynamic capability is required.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I would like to bring this issue up again and extend it. I think a advertisement/discovery extension could be useful in same and cross device scenarios.

Here is how I would envision it to work:

1) There is a new type of message, let’s call it verifier advertisement for the moment. In case of same device, it is sent to a newly defined endpoint. In case of cross device, there is a dedicated custom scheme for it (openid-advertisement) in the QR Code.

2) The advertisement message contains contains a message identifier and the URL of a new endpoint at the verifier, let’s call it start presentation for the moment.

Note: I intentionally do not use any OAuth parameters in the advertisement message as I would like to give the verifier as much flexibility as possible to tailor the actual authorization (presentation) request to the wallet that will call the verifier (see George’s comment). I also would like to enable the advertisement to be used for different transactions. So this message could be printed out, put on a wall and scanned by several people to start a presentation transaction.

3) The wallet sends a POST request to verifier’s start presentation endpoint. This request contains the message identifier and the issuer URL of the actual wallet. This means the verifier learns what concrete wallet (product/service) it will talk to and can adjust its behavior accordingly. It can obtain all sorts of metadata including endpoints. For example, the verifier can determine the client id and client id scheme to be used with this particular wallet.

Further parameters could be:

• a nonce - to be included in the authorization request produced by the verifier in response to the POST request
• an ephemeral key - to be used to encrypt the authorization request
• authentication data - so the wallet could even authenticate towards the verifier
• version information (?)

4) The verifier creates a fresh authorization (presentation) request and sends it in the response of the POST request.

The rest of the process works like before.

Benefits if the proposed approach:

• Requests can be tailored to wallet’s capabilities (trust framework, features, capabilities). As an example, a verifier might be looking for person identification data and supports mDL as well as SD-JWT VC based identity credentials. If the wallet only supports mDL, the presentation request can be specified in a much simpler fashion.
• I assume having a wallet provided nonce in the signed authorization request allows for early refusal of replayed requests. This clearly needs to be verified (including other consequences of the proposed approach).
• I hope we could get rid of ecosystem/trust framework specific custom schemes and replace them by a kind if dynamic negotiation between wallet and verifier.
• The request is provided through an TLS protected connection, which elevates the protection of the request payload (very much like PAR does).
• On top of it, one might also encrypt the request on the application level (if desired).
• As already mentioned above: as the advertisement is static, the proposed approach is a simple solution for credential presentation in proximity scenarios. It might not be as sophisticated as BLE or NFC, but HTTPS has been demonstrated to work in such scenarios, too.
• The verifier can authenticate the wallet (disclaimer: I’m a bit worried wallet authentication could lead to privacy issues, so we need to analyse the consequences on the privacy).

‌

[alenhorvat]

@tlodderstedt see #28 (comment)

Combining SIOP with another SIOP or OID4VP can solve the problem.
Wallet acts like a (SI)OP, "verifier" acts like RP
Since Verifier requires additional information (e.g., wallet metadata, wallet attestation, ...) Verifier starts a new intermediate SIOP/OID4VP flow, where the roles are reverted
After the intermediate flow the original flow continues

Here's a high-level overview of how we combined the two: https://api-pilot.ebsi.eu/docs/ct/verifiable-presentation-exchange-guidelines-v3#context
Good thing about the approach is that it re-uses the existing specifications as they are.