Added examples for 3 Authz request options

[deshmukhrajvardhan]

PR Checkpoints

• [x] official html rendering, which is generated using mmark - Download it from the GitHub action tab, https://github.com/openid/OpenID4VP/pull/<PR number>/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

[deshmukhrajvardhan]

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

[deshmukhrajvardhan]

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!

[bc-pi]

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]

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]

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

[cyberphone]

@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.

https://github.com/openid/OpenID4VP/issues/188

[bc-pi]

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

[cyberphone]

@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]

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.

[Sakurann]

@deshmukhrajvardhan looks like the content is good to go and can be merged but there are so many conflicts, it might be easier to do a new PR to the most recent version of the spec and add content from this PR to it? (we can merge it without additional review period based on the reviews on this PR if you can do a new PR) (you can also resolve conflicts on this PR) please let us know how you would like to proceed.

[deshmukhrajvardhan]

@deshmukhrajvardhan looks like the content is good to go and can be merged but there are so many conflicts, it might be easier to do a new PR to the most recent version of the spec and add content from this PR to it? (we can merge it without additional review period based on the reviews on this PR if you can do a new PR) (you can also resolve conflicts on this PR) please let us know how you would like to proceed.

@Sakurann I agree with your suggestion. A new PR would be easier. Will create and attach the link in the next comment.

[deshmukhrajvardhan]

https://github.com/openid/OpenID4VP/pull/464/files Ready for review @Sakurann

[Sakurann]

replaced by #464