[Openid-specs-ab] SIOP Special Topic Call Notes 6-Oct-22

[Mike Jones]

SIOP Special Topic Call Notes 6-Oct-22

Mike Jones
Brian Campbell
Joseph Heenan
Torsten Lodderstedt
Bjorn Hjelm
Kristina Yasuda
Oliver Terbu
David Waite (DW)
David Chadwick

Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              PR #251: adding an example of presenting an LDP_VC signed using bbs
                           Kristina requested that Torsten review
              PR #310: Clean up of SIOPv2
                           Kristina addressed comments received
                           Re-reviews requested
              PR #299: Add Error Codes
                           David Chadwick made an updated proposal in issue #1631
                           Torsten suggested that we not define new error codes, but give guidance to how to use existing ones
                           Torsten said that we need a Credential Issuance Error Response section
                           Torsten said that Daniel Fett is doing a security assessment of the error responses
              PR #285: Adding batch credential endpoint: fixes #1544
                           Torsten and Oliver discussed the mechanisms
                           Oliver plans to update the PR accordingly
                           Torsten suggested adding a Batch Credential Issuance Error section
                           Torsten doesn't understand why a c_nonce would be returned in the error response for every slot requested
                                         He suggested returning only one c_nonce from the batch issuance endpoint

Rebooting the Web of Trust (RWoT)
              People shared points about the recent RWoT workshop
              Torsten had a discussion about higher-assurance issuance using OpenID4VCI
              Torsten said that Manu Sporny believes that CHAPI and OpenID4VCI can go together
                           Manu plans to support OpenID4VCI in CHAPI
              Oliver recruited people to work on the holder binding proposal
                           They wrote a paper about that
                           It will be sent to the W3C VC working group
              Also, see the draft whitepaper https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/credential-profile-comparison.md

Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1577: [needs-PR] Cryptographic proof of possession nonce management
                           Torsten described that AnonCreds wouldn't use the nonce mechanisms
                           He said that the proposal is light weight for anyone using JWS or JWT proof formats
                           He said that we will likely have profiles that are credential-format specific
                           Oliver asked how c_nonce would work with a stateless issuer
                                         Kristina responded that the server would recognize a nonce that it created
                           Torsten suggested we describe how to achieve replay protection
                                         Server-provided nonce or client-provided nonces are options
                                         Kristina is reluctant to remove the server-provided nonce, but wants to see more implementation experience
                           Oliver asserted that stateless servers need c_nonce for replay protection
                           Oliver and Torsten will write a PR together about c_nonce and replay
                                         Kristina requested that this happen soon so we can merge it in a couple of weeks
              #1651: [has-PR] Clarifying jwt_vp example in OIDC4VP
                           Please review PR #314
              #1612: [has-PR] Define which object should be returned for `mdl_iso_cbor`
                           Please review PR #315
              #1626: response_mode=post should define response format & add an example
                           Kristina asked whether the response should be form-url-encoded
                           Brian said that this seems pretty undefined
                           Torsten said that the endpoint is determined by the redirect_uri parameter
                           Brian asked if this was sort of a reverse PAR
                           Mike asked where this is specified
                                         It isn't currently specified
                           Brian said that the size doesn't matter because you're posting directly to the server
                           Torsten said that this can work without the wallet exposing an endpoint
                                         The RP needs to expose an endpoint
                                         The requirement for the RP to expose an endpoint reachable from the wallet is an addition for the cross-device flow
                                         This is simpler than some other solutions available
                           Torsten said that he will add the text that Joseph proposed about the encoding
              #1642: issuance initiation request options
                           Joseph said that we need to define an error response in additional to a successful response

Next Call
              The next call is at 4pm Pacific Time on Monday, October 10, 2022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20221006/b17685a1/attachment-0001.html>