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

Added examples for 3 Authz request options #218

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
104 changes: 97 additions & 7 deletions openid-4-verifiable-presentations-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -232,8 +232,6 @@ Presentation of Verifiable Credentials using OpenID for Verifiable Presentations

The Authorization Request follows the definition given in [@!RFC6749] taking into account the recommendations given in [@!I-D.ietf-oauth-security-topics].

The Verifier MAY send an Authorization Request as a Request Object either by value or by reference, as defined in the JWT-Secured Authorization Request (JAR) [@RFC9101].

This specification defines a new mechanism for the cases when the Wallet wants to provide to the Verifier details about its technical capabilities to
allow the Verifier to generate a request that matches the technical capabilities of that Wallet.
To enable this, the Authorization Request can contain a `request_uri_method` parameter with the value `post`
Expand Down Expand Up @@ -283,28 +281,120 @@ The following additional considerations are given for pre-existing Authorization
: OPTIONAL. Defined in [@!RFC6749]. The Wallet MAY allow Verifiers to request presentation of Verifiable Credentials by utilizing a pre-defined scope value. See (#request_scope) for more details.

`response_mode`:
: OPTIONAL. Defined in [@!OAuth.Responses]. This parameter is used (through the new Response Mode `direct_post`) to ask the Wallet to send the response to the Verifier via an HTTPS connection (see (#response_mode_post) for more details). It is also used to request signing and encrypting (see (#jarm) for more details). If the parameter is not present, the default value is `fragment`.
: OPTIONAL. Defined in [@!OAuth.Responses]. This parameter is used (through the new Response Mode `direct_post`) to ask the Wallet to send the response to the Verifier via an HTTPS connection (see (#response_mode_post) for more details). It is also used to request signing and encrypting (see (#jarm) for more details). If the parameter is not present, the default value is `fragment`.

The Verifier MAY send an Authorization Request using either of these 3 options:

The following is a non-normative example of an Authorization Request:
1. Passing as URL with encoded parameters
2. Passing a request object as value
3. Passing a request object by reference
deshmukhrajvardhan marked this conversation as resolved.
Show resolved Hide resolved

2 and 3 are defined in the JWT-Secured Authorization Request (JAR) [@RFC9101].

The following is a non-normative example of Authorization Request with URL encoded parameters:
```
GET /authorize?
response_type=vp_token
&client_id=https%3A%2F%2Fclient.example.org%2Fcb
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&presentation_definition=...
&scope=openid
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced it's a good idea to add scope=openid here, it makes it not a pure VP request and I think we want to show a basic VP request here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should i remove it from all 3 examples then?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, yes, please - it's not there in any of the examples currently in the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

&nonce=n-0S6_WzA2Mj HTTP/1.1
```

The following is a non-normative example of an Authorization Request with a `request_uri_method` parameter (including the additional `client_id_scheme` and `client_metadata` parameters):
The following is a non-normative example of Authorization Request with request object as value:
```
GET /authorize?
response_type=vp_token
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

response_type isn't legal here, when request= is used response_type can only be inside the request object, it should be removed:

Suggested change
response_type=vp_token

Copy link
Contributor Author

@deshmukhrajvardhan deshmukhrajvardhan Aug 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! good catch! I've made the change

&client_id=https%3A%2F%2Fclient.example.org%2Fcb
&request=eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6Ik1LQkNUTkljS1VTRGlpMTF5U3MzNTI2aURaOEFpVG83VHU2S1BBcXY3R
DQiLCJ5IjoiNEV0bDZTUlcyWWlMVXJONXZmdlZIdWhwN3g4UHhsdG1XV2xiYk00SUZ5TSIsInVzZSI6ImVuYyIsImtpZCI6IjEiLCJhbGc
iOiJQUzI1NiJ9.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS92MiIsInJlc3BvbnNlX3R5cGU
Copy link
Member

@bc-pi bc-pi Jul 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the header of this thing decodes to the following, which isn't ok

{
  "kty": "EC",
  "crv": "P-256",
  "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
  "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
  "use": "enc",
  "kid": "1",
  "alg": "PS256"
} 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the key and shortened the jwt to be eyJrd... as no key is specified.

Let me know if this looks good.

iOiJ2cF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwcy8vY2xpZW50LmV4YW1wbGUub3JnL
2NiIiwic2NvcGUiOiJvcGVuaWQiLCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6ImV4YW1wbGVfand0X3ZjIiwiaW5wdXRfZGV
zY3JpcHRvcnMiOlt7ImlkIjoiaWRfY3JlZGVudGlhbCIsImZvcm1hdCI6eyJqd3RfdmNfanNvbiI6eyJwcm9vZl90eXBlIjpbIkpzb25XZ
WJTaWduYXR1cmUyMDIwIl19fSwiY29uc3RyYWludHMiOnsiZmllbGRzIjpbeyJwYXRoIjpbIiQudmMudHlwZSJdLCJmaWx0ZXIiOnsidHl
wZSI6ImFycmF5IiwiY29udGFpbnMiOnsiY29uc3QiOiJJRENyZWRlbnRpYWwifX19XX19XX0sIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.
QcQkoxVRdGtVBtqmO4pFdDqgiLVvgPo1nah0enAxXDrMd-q3lA8NXLASG8xb9VT_iY4iyD23ULx5YW4ENUUx-v4kpKAQZnPVH8U7mbjulk
7bV8yph_RFt8SwvfSRWWWgPduTxJFAscmph-r2t77kBGbxI0Le58eYwMbXgB7yUQx-4TarIqr9E2lSD44ru8GVfC1zWUIjZPXD98xOcH-V
IPJamxpWKZ2GJOKhUbxc-GTgUp6knTfc_oIkcdr7kIUUaZwqYGOsQARA1R75y9DVXCGYTrRm0Ssl54MMKD5Fze9hb8Oj3AqdYG6RWviR1e
Jf3EzMstmkx92yHYdrNTux1Q
```
Where the contents of `request` consist of base64url-encoding and signing (in the example with RS256 algo)
this json:
```
{
"iss": "s6BhdRkqt3",
"aud": "https://self-issued.me/v2",
"response_type": "vp_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https//client.example.org/cb",
"scope": "openid",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd have probably preferred if all three examples showed the same request so that we were just highlighting the differences of the 3 formats (e.g. this request has scope=openid and the above one doesn't) but I don't feel strongly about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! Agreed!

"presentation_definition": {
"id": "example_jwt_vc",
"input_descriptors": [
{
"id": "id_credential",
"format": {
"jwt_vc_json": {
"proof_type": [
"JsonWebSignature2020"
]
}
},
"constraints": {
"fields": [
{
"path": [
"$.vc.type"
],
"filter": {
"type": "array",
"contains": {
"const": "IDCredential"
}
}
}
]
}
}
]
},
"nonce": "n-0S6_WzA2Mj"
}
```
The example request object above is signed with this key:
```
{
"kty": "EC",
"crv": "P-256",
"x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
"y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
"use": "enc",
"kid": "1",
"alg": "PS256"
}
```

The following is a non-normative example of Authorization Request with request object as reference:
```
GET /authorize?
client_id=client.example.org
&client_id=https%3A%2F%2Fclient.example.org%2Fcb
&client_id_scheme=x509_san_dns
&client_metadata=...
&request_uri=https%3A%2F%2Fclient.example.org%2Frequest%2Fvapof4ql2i7m41m68uep
&request_uri_method=post HTTP/1.1
&scope=openid
```
And, later the wallet might send the following non-normative example request to the `request_uri`:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
And, later the wallet might send the following non-normative example request to the `request_uri`:
Later, the wallet might send the following non-normative example request to the `request_uri`:

```
POST /request/vapof4ql2i7m41m68uep HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

wallet_metadata=%7B%22vp_formats_supported%22%3A%7B%22jwt_vc_json%22%3A%7B%22alg_values_supported
%22%3A%5B%22ES256K%22%2C%22ES384%22%5D%7D%2C%22jwt_vp_json%22%3A%7B%22alg_values_supported%22%3A%
5B%22ES256K%22%2C%22EdDSA%22%5D%7D%7D%7D&
wallet_nonce=qPmxiNFCR3QTm19POc8u
```

## `presentation_definition` Parameter {#request_presentation_definition}
Expand Down
Loading