request_uri extension

[tlodderstedt]

This is an attempt to come up with a simplified and more privacy preserving design for the advanced flow (issue #45). The simplification and tightening is achieved by removing the ability to pick client identity and scheme on demand and instead adding the ability to sign the initial request.

It fulfills the following requirements:

• prevention of user tracking through request uri callbacks by adding signature/authentication to the initial request
• ability to tune request object to wallet capabilities
• ability to authenticate/attest the wallet identity and capabilities to the verifier early in the process

It would also allow encryption of the presentation request and to include a wallet provided nonce in the signed presentation request object.

[peppelinux]

Thank you @tlodderstedt,

starting from your very good proposal, I propose some little changes here as well, according to the following notes:

1. authorization request is misleading since the audience in an RP and not an AS. Proposed authorization request -> discovery request
2. discovery request is optional and could not be supported or could not be required by RP. Therefore, the wallet instance must obtain a signed response where the JWS typ header value should explictly indicate the nature of the request. Here I propose "typ": "wallet-discovery-request+jwt"

note also that:

3. wallet metadata can be provided as parameter or wallet metadata uri as well, in the cases where the wallet device doesn't have nothing to say more than what already set by wallet solution and available online for its instances

[paulbastian]

I am still a bit skeptical. What I observe:

• presentation_definition may be more simple based on credential_formats supported by wallet
• 2x user consent
• more complex, additional roundtrip
• no added security compared to sending wallet_attestation in Auth Response
• if there is no technical overlap between wallet and Verifier, both approaches will result in a bad UX/error message, because the wallet is already launched
• one more optional way to implement that is challenging interoperability of the ecosystem

[paulbastian]

Would it be simpler to extend the HTTP GET for request_uri with static wallet metadata and add wallet_attestation as OPTIONAL to the Authorization Response?

[peppelinux]

@paulbastian your points make sense and needs to be clarified because the risks you raise are concrete:

1. 2x user consent -> data exchanged are not related to user's attributes, the consent on evaluating the trust with the RP is not required since it is something that automatically is handled by the trust evaluation mechanisms. Using OIDC or SAML2 the user didn't give the consent to send an authn request to the OP/IDP, because it's just interop where the client/server mutual auth happens without any user consent. Since the RP's request is signed, the wallet instance is able to evaluate the trust with the RP and provide its interop and security capabilities, without providing any user data where the consent is required.

2. more complex, additional roundtrip -> I want this endpoint optional, the JWS typ headers gives the evidence of the desidered flow from the RP perspective. If the signed request is different from the advanced flow typ, or not in JWS format, then the wallet instance is able to evaluate the traditional request object. @tlodderstedt at step number 2 we may provide the request_uri as well, to allow wallet instances that do not support this flow to jump directly to the request_uri endpoint

I didn't get these:

• presentation_definition may be more simple based on credential_formats supported by wallet.
• if there is no technical overlap between wallet and Verifier, both approaches will result in a bad UX/error message, because the wallet is already launched

Can you provide more elements and these last two elements?

then, on this one more optional way to implement that is challenging interoperability of the ecosystem It may seem strange but I fully agree with you. What I see in this "discovery" flow, as I like to define it, is a form of triage that enables many possibilities, such as allowing the user to select the type of flow, whether cross-device or same-device, possibilities that could become requirements in the future, when the wallet ecosystem will not restricted to eIDAS alone.

this discovery method through signed artifacts becomes a mutual authentication between the parties, before the data is released. This, RP side represents a way to protect the response_uri endpoint that could otherwise be subject to abuse. Think of an adversary who brings 8MB of JWS to direct.post with a thousand credentials and the RP that processes every single vp token, think of a hundred requests of this type in 5 seconds. This discovery-advance flow allows to authenticate the wallet instance before the presentation, using OAuth 2.0 Attestation-Based Client Authentication.

This may not represent a priority for our working group and our implementations, and we may even put it on the back burner but let's not abandon it, this work can be useful to us.

[Sakurann]

I like this flow much more, because it reuses Authorization Endpoint. and I think POST makes more sense than GET, just want to understand the implications how disruptive it is.

[tlodderstedt]

Thank you @tlodderstedt,

starting from your very good proposal, I propose some little changes here as well, according to the following notes:

1. authorization request is misleading since the audience in an RP and not an AS. Proposed authorization request -> discovery request

The PR proposes to make the new request type a variation of the authorization request. That's why it is called authorization request. So in contrast to the first PR, it does not require a new endpoint at the wallet.

2. discovery request is optional and could not be supported or could not be required by RP. Therefore, the wallet instance must obtain a signed response where the JWS typ header value should explictly indicate the nature of the request. Here I propose "typ": "wallet-discovery-request+jwt"

Given my argument above, we could use "oauth-authz-req+jwt" or invent a new typ like "oauth-authz-req-extended+jwt"

note also that:

3. wallet metadata can be provided as parameter or wallet metadata uri as well, in the cases where the wallet device doesn't have nothing to say more than what already set by wallet solution and available online for its instances

That's why I included "Metadata MAY also be provided by other means, for example in the wallet attestation."

[tlodderstedt]

I am still a bit skeptical. What I observe:

• presentation_definition may be more simple based on credential_formats supported by wallet
• 2x user consent
  where do you see the need for 2 x user consent?

• more complex, additional roundtrip

Where is the additional roundtrip? The PR just replaces the GET request onto the request_uri by a POST request to a new endpoint.

• no added security compared to sending wallet_attestation in Auth Response

Early refusal? + enhanced privacy since anonymous initiation of a callback (request URI) is impossible due to the signed request.

• if there is no technical overlap between wallet and Verifier, both approaches will result in a bad UX/error message, because the wallet is already launched
• one more optional way to implement that is challenging interoperability of the ecosystem

We are not there yet. Perhaps this request is the one way going forward.

[tlodderstedt]

Would it be simpler to extend the HTTP GET for request_uri with static wallet metadata and add wallet_attestation as OPTIONAL to the Authorization Response?

Can you please explain why that would be a better solution? Note: a GET request MUST be idempotent and does not have a body (which limits parameter size).

[David-Chadwick]

Since we had a signed authz request and presumably a secure channel then signing the presentation request object should be optional

[tlodderstedt]

you are right, we already have authenticated the verifier at that stage.

What do others think? Should we make the signature of the presentation request optional?

[awoie]

I think in the meeting last week, we agreed that having unsigned requests is a viable approach but we should create a new issue for that, after we merged this PR.

[peppelinux]

@tlodderstedt this PR is definitely standing and taking shape in an increasingly consistent way.
The thing I love to bring home is that it satisfies the requirements, and this is the most important thing.

However, the term Authz request is a traditional OAuth 2.0 term used for years in a well established flow; while in this flow in the wallet ecosystem extends the tradtional oauth 2.0 authz request by adding the create_request_uri. For this evidence I'm in favor of using the media type oauth-authz-req-extended+jwt or better another specialized media type tailored for this context oauth-authz-req-wallet+jwt.

I don't like to stress on this, but, the oauth 2.0 flow returns auth code or tokens, while this flow returns artifacts used for doing discovery.

The term create request request is .. weird. WDYT of create pre-request discovery? Or, it the term discovery must not be used (can you pls provide the reason why it should not?) WDYT of create wallet capabilities response

[Sakurann]

also wallet_nonce authorization request parameter needs to be defined somewhere else (authorization request/section 5 probably). this section is wallet's request parameter.

[Sakurann]

I am ok with the mechanism, direction. but I am not comfortable merging as-is without description of the mechanism being brushed up a little more (and I have made concrete suggestions).

also I am a little worried about the terminology for this new request_uri_mode, in some places it tries to be different from JAR, but in other tries to align. at least saying "the wallet retrieves Request Object using POST request" should be fine.

[Sakurann]

Thank you!