Added examples for 3 Authz request options #218

deshmukhrajvardhan · 2024-07-17T22:40:48Z

PR Checkpoints

official html rendering, which is generated using mmark - Download it from the GitHub action tab, https://github.com/openid/OpenID4VP/pull//checks - by clicking on 'artifacts' and then 'output'
>=4 approvals OR >=2 if editorial PR
>=1 week since PR's final state
Only Chairs can merge the PR

Summary

I used https://jwt.io/ to create the signed and encoded payload for request.
Paste the payload in there to decode it and verify the signature

Related Issue(s)

Closes #78

Special notes for your reviewer

openid-4-verifiable-presentations-1_0.md

Sakurann

minor nit, but overall, looks good to me, thank you!

it is an editorial PR, so no need for 4 >= approvals :)

authorization request defined in rfc9101 Co-authored-by: Kristina <[email protected]>

deshmukhrajvardhan · 2024-07-23T19:20:10Z

Thanks @Sakurann !
I've committed your suggested change :)
Ah! gotcha. How many approvals do we need for editorial change?

openid-4-verifiable-presentations-1_0.md

jogu · 2024-07-23T20:48:59Z

openid-4-verifiable-presentations-1_0.md

+    response_type=vp_token
+    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
+    &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS92MiIsInJlc3BvbnNlX3R5cGUiOiJ2cF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwcy8vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwic2NvcGUiOiJvcGVuaWQiLCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6ImV4YW1wbGVfand0X3ZjIiwiaW5wdXRfZGVzY3JpcHRvcnMiOlt7ImlkIjoiaWRfY3JlZGVudGlhbCIsImZvcm1hdCI6eyJqd3RfdmNfanNvbiI6eyJwcm9vZl90eXBlIjpbIkpzb25XZWJTaWduYXR1cmUyMDIwIl19fSwiY29uc3RyYWludHMiOnsiZmllbGRzIjpbeyJwYXRoIjpbIiQudmMudHlwZSJdLCJmaWx0ZXIiOnsidHlwZSI6ImFycmF5IiwiY29udGFpbnMiOnsiY29uc3QiOiJJRENyZWRlbnRpYWwifX19XX19XX0sIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.m1KYXT4r5Pj7Jh8gUlngpvjUoEZnOcbL8lXuDxbLbQyhLG9mro9EpT3I4YOm25tnxFx2mrKb42dFPxXOwLO5NbBmoYmY8wxH85H98RtpPGaTwCD6duxbp4eZm6LO-fdxpSvjzCAKoU3kzloh1Q1ijkP_ZQgwmS-uQba9qpu61hMjF6KIIjz59sJHpZOI0cEz4LqrLwXXIht0hyZXdE_vJIBEwfafoLZgggF9adNGUQnE3dXLi_is6XrDk7BS0VZds6IaNTVlIlS5NfHg6Lp1IpbiFta_6CWrFxtC1QoCIrhIzbJgnF4GRboy0SfYRXD8Vt8qbPzLIeUvE-LyObGN5g


For consistency with other examples we should use two space indents here:

Suggested change

response_type=vp_token

&client_id=https%3A%2F%2Fclient.example.org%2Fcb

&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS92MiIsInJlc3BvbnNlX3R5cGUiOiJ2cF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwcy8vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwic2NvcGUiOiJvcGVuaWQiLCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6ImV4YW1wbGVfand0X3ZjIiwiaW5wdXRfZGVzY3JpcHRvcnMiOlt7ImlkIjoiaWRfY3JlZGVudGlhbCIsImZvcm1hdCI6eyJqd3RfdmNfanNvbiI6eyJwcm9vZl90eXBlIjpbIkpzb25XZWJTaWduYXR1cmUyMDIwIl19fSwiY29uc3RyYWludHMiOnsiZmllbGRzIjpbeyJwYXRoIjpbIiQudmMudHlwZSJdLCJmaWx0ZXIiOnsidHlwZSI6ImFycmF5IiwiY29udGFpbnMiOnsiY29uc3QiOiJJRENyZWRlbnRpYWwifX19XX19XX0sIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.m1KYXT4r5Pj7Jh8gUlngpvjUoEZnOcbL8lXuDxbLbQyhLG9mro9EpT3I4YOm25tnxFx2mrKb42dFPxXOwLO5NbBmoYmY8wxH85H98RtpPGaTwCD6duxbp4eZm6LO-fdxpSvjzCAKoU3kzloh1Q1ijkP_ZQgwmS-uQba9qpu61hMjF6KIIjz59sJHpZOI0cEz4LqrLwXXIht0hyZXdE_vJIBEwfafoLZgggF9adNGUQnE3dXLi_is6XrDk7BS0VZds6IaNTVlIlS5NfHg6Lp1IpbiFta_6CWrFxtC1QoCIrhIzbJgnF4GRboy0SfYRXD8Vt8qbPzLIeUvE-LyObGN5g

response_type=vp_token

&client_id=https%3A%2F%2Fclient.example.org%2Fcb

&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS92MiIsInJlc3BvbnNlX3R5cGUiOiJ2cF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwcy8vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwic2NvcGUiOiJvcGVuaWQiLCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbiI6eyJpZCI6ImV4YW1wbGVfand0X3ZjIiwiaW5wdXRfZGVzY3JpcHRvcnMiOlt7ImlkIjoiaWRfY3JlZGVudGlhbCIsImZvcm1hdCI6eyJqd3RfdmNfanNvbiI6eyJwcm9vZl90eXBlIjpbIkpzb25XZWJTaWduYXR1cmUyMDIwIl19fSwiY29uc3RyYWludHMiOnsiZmllbGRzIjpbeyJwYXRoIjpbIiQudmMudHlwZSJdLCJmaWx0ZXIiOnsidHlwZSI6ImFycmF5IiwiY29udGFpbnMiOnsiY29uc3QiOiJJRENyZWRlbnRpYWwifX19XX19XX0sIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.m1KYXT4r5Pj7Jh8gUlngpvjUoEZnOcbL8lXuDxbLbQyhLG9mro9EpT3I4YOm25tnxFx2mrKb42dFPxXOwLO5NbBmoYmY8wxH85H98RtpPGaTwCD6duxbp4eZm6LO-fdxpSvjzCAKoU3kzloh1Q1ijkP_ZQgwmS-uQba9qpu61hMjF6KIIjz59sJHpZOI0cEz4LqrLwXXIht0hyZXdE_vJIBEwfafoLZgggF9adNGUQnE3dXLi_is6XrDk7BS0VZds6IaNTVlIlS5NfHg6Lp1IpbiFta_6CWrFxtC1QoCIrhIzbJgnF4GRboy0SfYRXD8Vt8qbPzLIeUvE-LyObGN5g

good catch!

jogu · 2024-07-23T20:53:00Z

openid-4-verifiable-presentations-1_0.md

+  "nonce": "n-0S6_WzA2Mj"
+}
+```
+With these keys:


There's only one key, so "keys" is wrong. Suggest a slightly more verbose wording too:

Suggested change

With these keys:

The example request object above is signed with this key:

jogu · 2024-07-23T20:55:15Z

openid-4-verifiable-presentations-1_0.md

 ```
 GET /authorize?
-  client_id=client.example.org
+  response_type=vp_token


response_type isn't legal here as I mentioned here: #78 (comment)

Suggested change

response_type=vp_token

jogu · 2024-07-23T20:55:30Z

openid-4-verifiable-presentations-1_0.md

 ```
 GET /authorize?
-  client_id=client.example.org
+  response_type=vp_token
+  &client_id=https%3A%2F%2Fclient.example.org%2Fcb
  &client_id_scheme=x509_san_dns
  &client_metadata=...


client_metadata also isn't legal here (see link in previous comment)

jogu · 2024-07-23T20:57:19Z

openid-4-verifiable-presentations-1_0.md

  &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
 ```
+And, later use the `request_uri` for the below request:


I think this is what is meant?

Suggested change

And, later use the `request_uri` for the below request:

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

jogu · 2024-07-23T20:57:53Z

openid-4-verifiable-presentations-1_0.md

  &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
 ```
+And, later use the `request_uri` for the below request:
+```
+POST /request HTTP/1.1


To match the above example it needs the full path that was passed in request_uri parameter:

Suggested change

POST /request HTTP/1.1

POST /request/vapof4ql2i7m41m68uep HTTP/1.1

jogu · 2024-07-23T21:01:32Z

openid-4-verifiable-presentations-1_0.md

+  "response_type": "vp_token",
+  "client_id": "s6BhdRkqt3",
+  "redirect_uri": "https//client.example.org/cb",
+  "scope": "openid",


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.

Good point! Agreed!

Formatting space Co-authored-by: Joseph Heenan <[email protected]>

bc-pi · 2024-07-25T01:25:42Z

openid-4-verifiable-presentations-1_0.md

+```
+{
+  "kty":"RSA",
+  "kid":"k2bdc",


this key sure does bring back some memories, thanks for that, but this is not really consistent with how examples are provided in the rest of this document, is it?

Updated to use existing key

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

wait, what, the encryption key from one of the examples in the W3C Digital Credentials API section? that doesn't seem good. and where did you find the private key? so many questions...

wow the private key is apparently here https://datatracker.ietf.org/doc/html/rfc7517#appendix-A.2 which is fun

but maybe that's not even relevant

sorry

i am genuinely confused

and by confused #218 (comment) i mean I don't understand what's going on here

Thanks for your review and I hope to learn!

I found the key in this repo https://github.com/openid/OpenID4VP/blob/main/examples/digital_credentials_api/signed_request_payload.json#L19 and the draft https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html
you are right it is the same one as in that doc in section A1 https://datatracker.ietf.org/doc/html/rfc7517#appendix-A.1 and A.2 section has the private key.

Lmk, if I should use a different key as its private key is readily available? Or do I need to create a new key pair and mention them in the doc? or something else?

Happy to get feedback and incorporate changes.

The idea of providing the key in a spec to allow for verification of examples is nice. But I don't think that's something that's been done much or at all in the 4VC family of documents. So doing it here is kind of out of place. And there are already plenty of opportunities for that in PAR, JAR, JWT, etc so it's arguably not necessary or even particularly useful to do here.

It's pretty well accepted that using the same key pair for both singing and encryption is a bad and potentially dangerous thing. So we should avoid doing anything that looks like it's condoning or encouraging the practice.

Thanks for the guidance! That makes sense!
I have removed the key and shortened the jwt to be eyJrd... as no key is specified.

Let me know if this looks good.

jogu · 2024-07-26T21:07:57Z

openid-4-verifiable-presentations-1_0.md

 ```
 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


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.

Should i remove it from all 3 examples then?

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

bc-pi · 2024-07-27T02:51:43Z

openid-4-verifiable-presentations-1_0.md

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


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" }

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

Let me know if this looks good.

bc-pi

Friday night after IETF week is probably not an ideal time to be reviewing PRs, sorry, but this needs some care and feeding

deshmukhrajvardhan · 2024-07-30T03:22:41Z

Friday night after IETF week is probably not an ideal time to be reviewing PRs, sorry, but this needs some care and feeding

No problem and thanks for the review. I am happy to nurture it as much as needed with help from reviewers and reiterate until we are at a good spot!

TallTed · 2024-07-30T05:19:24Z

openid-4-verifiable-presentations-1_0.md

  &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`:


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`:

bc-pi · 2024-07-31T17:15:07Z

No problem and thanks for the review. I am happy to nurture it as much as needed with help from reviewers and reiterate until we are at a good spot!

Appreciate that attitude, thank you! I'm attempting to help as a reviewer but, like all of us, have only limited cycles and have to try and manage where they are applied.

cyberphone · 2024-08-18T19:27:31Z

F.Y.I.
Another wallet scheme uses Deterministically Encoded CBOR and an enveloped signature, here shown in diagnostic nation. You may try it yourself: https://test.webpki.org/csf-lab/home

{
  1: {
    1: "Space Shop",
    2: "435.00",
    3: "USD"
  },
  2: "spaceshop.com",
  3: "FR7630002111110020050014382",
  4: "https://banknet2.org",
  5: "05768401",
  6: "2022-09-29T09:34:08-05:00",
  7: {
    1: 38.8882,
    2: 77.0199
  },
  / Enveloped signature object /
  -1: {
    / Signature algorithm = ES256 /
    1: -7,
    / Public key descriptor in COSE format /
    4: {
      / kty = EC /
      1: 2,
      / crv = P-256 /
      -1: 1,
      / x /
      -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5',
      / y /
      -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8'
    },
    / Signature value /
    6: h'5f21112b9f5c1a93743409596421e673f88e59cf34610d53a7cd00f4017327c8f603ea7344a9286db26c52c2a661dff6e4fabc0f2384fe7d1de6c0a23a3f5c21'
  }
}

I could not find anything in the example that looked like payment transaction data.

bc-pi · 2024-08-19T03:29:08Z

@cyberphone, how exactly is that comment helping progress this PR?

cyberphone · 2024-08-19T08:37:38Z

@bc-pi Pardon me for disturbing the order. Anyway, the EUIDW payment project currently seems to lack a sequence diagram making transaction request data PRs somewhat less interesting. I haven't found any specification of virtual payment credentials either. In addition, I believe deterministically encoded CBOR would be a better mousetrap than JSON.

#188

bc-pi · 2024-08-19T11:00:05Z

@cyberphone, how exactly does that comment help answer the question about how exactly the previous comment is helping progress this PR?

cyberphone · 2024-08-19T11:22:08Z

@bc-pi Is this PR supposed to cover payment requests as well? If so, I would put it on hold because it doesn't seem to match this use case. See also: https://www.w3.org/TR/payment-request/

bc-pi · 2024-08-19T14:15:22Z

I commend the relentlessly consistent approach @cyberphone takes here and in many other forums. I apologize to anyone reading these PR comments, and especially folks subscribed and receiving notifications, for my momentary laps of judgement in thinking that engaging in this context could possibly have had a different outcome.

jogu · 2024-08-25T14:11:44Z

openid-4-verifiable-presentations-1_0.md

@@ -1909,7 +1973,6 @@ The following is a non-normative example of a request that combines this specifi
 ```
 GET /authorize?
  response_type=vp_token%20id_token
-  &scope=openid


This scope=openid should actually stay, as this section is showing an example of a SIOP request which does require openid. (openid should still be omitted in the new examples you're adding)

Thanks! i wasn't sure about this earlier.
I've made the change.

jogu · 2024-08-25T14:14:42Z

openid-4-verifiable-presentations-1_0.md

+The following is a non-normative example of Authorization Request with request object as value:
+```
+GET /authorize?
+  response_type=vp_token


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

Thanks! good catch! I've made the change

Added examples for 3 Authz request options

316eacd

deshmukhrajvardhan mentioned this pull request Jul 17, 2024

Specification is missing examples for request objects #78

Open

deshmukhrajvardhan requested review from jogu, Sakurann, paulbastian, awoie and c2bo July 17, 2024 22:43

Sakurann reviewed Jul 23, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

Sakurann approved these changes Jul 23, 2024

View reviewed changes

Update openid-4-verifiable-presentations-1_0.md

ea4dcf1

authorization request defined in rfc9101 Co-authored-by: Kristina <[email protected]>

jogu reviewed Jul 23, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Show resolved Hide resolved

jogu reviewed Jul 23, 2024

View reviewed changes

deshmukhrajvardhan and others added 2 commits July 23, 2024 14:10

Update openid-4-verifiable-presentations-1_0.md

8d97183

Formatting space Co-authored-by: Joseph Heenan <[email protected]>

Addressed jogu's comments and cleanup

d362b31

bc-pi reviewed Jul 25, 2024

View reviewed changes

Use existing key

dbd4ab6

deshmukhrajvardhan requested review from jogu and bc-pi July 26, 2024 18:11

jogu reviewed Jul 26, 2024

View reviewed changes

bc-pi reviewed Jul 27, 2024

View reviewed changes

TallTed reviewed Jul 30, 2024

View reviewed changes

Removed key and scope from examples

7b03a40

deshmukhrajvardhan requested review from jogu, TallTed and bc-pi July 31, 2024 18:16

TallTed approved these changes Aug 1, 2024

View reviewed changes

deshmukhrajvardhan removed request for c2bo, awoie and paulbastian August 6, 2024 19:17

Sakurann self-requested a review August 13, 2024 18:17

jogu reviewed Aug 25, 2024

View reviewed changes

incorporated feedback

64b0161

deshmukhrajvardhan requested a review from jogu August 27, 2024 22:34

nit

53942c0

jogu approved these changes Sep 10, 2024

View reviewed changes

jogu added the editorial label Sep 27, 2024

	With these keys:
	The example request object above is signed with this key:

	And, later use the `request_uri` for the below request:
	And, later the wallet might send the following non-normative example request to the `request_uri`:

	POST /request HTTP/1.1
	POST /request/vapof4ql2i7m41m68uep HTTP/1.1

	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`:

Added examples for 3 Authz request options #218

Are you sure you want to change the base?

Added examples for 3 Authz request options #218

Conversation

deshmukhrajvardhan commented Jul 17, 2024 • edited Loading

PR Checkpoints

Summary

Related Issue(s)

Special notes for your reviewer

Sakurann left a comment

Choose a reason for hiding this comment

deshmukhrajvardhan commented Jul 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi Jul 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi Jul 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi left a comment

Choose a reason for hiding this comment

deshmukhrajvardhan commented Jul 30, 2024

Choose a reason for hiding this comment

bc-pi commented Jul 31, 2024

cyberphone commented Aug 18, 2024

bc-pi commented Aug 19, 2024

cyberphone commented Aug 19, 2024 • edited Loading

bc-pi commented Aug 19, 2024

cyberphone commented Aug 19, 2024

bc-pi commented Aug 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deshmukhrajvardhan Aug 27, 2024 • edited Loading

Choose a reason for hiding this comment

deshmukhrajvardhan commented Jul 17, 2024 •

edited

Loading

bc-pi Jul 27, 2024 •

edited

Loading

bc-pi Jul 27, 2024 •

edited

Loading

cyberphone commented Aug 19, 2024 •

edited

Loading

bc-pi commented Aug 19, 2024 •

edited

Loading

deshmukhrajvardhan Aug 27, 2024 •

edited

Loading