[Openid-specs-ab] SIOP Special Topic Call Notes 10-Nov-22

[Mike Jones]

SIOP Special Topic Call Notes 10-Nov-22

Mike Jones
Kristina Yasuda
David Chadwick
Andrew Hughes
Torsten Lodderstedt
Petteri Stenius
Tom Jones

IETF 115 is in London this week
              There's been good discussions on the use of client_id in the OAuth ecosystem

Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              PR #327: clarified the definition of response mode post - Issue #1626
                           Merged
              PR #351: relaxed client id requirements for pre-authz code grant type
                           Tobias and Torsten are discussing
                           One idea was an error code for when receiving an anonymous request when it is not supported
                           Torsten wants another metadata parameter indicating support for anonymous requests
                           Mike said that bring-your-own-client_id and anonymous clients are different
                                         Torsten agreed and said that it would only be anonymous if there's no client_id at all
                           Torsten said that this PR is about not providing a client_id at all
                                         Mike agreed to review it in that light
              PR #345: Update Introduction and Overview of OpenID4VP specification to better explain the new model
                           Kristina updated it to address Torsten's and Mike's comments
                           Kristina and Mike are disagreeing about commas ;-)
              We would like to merge these PRs shortly

Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              David said that issues that can be closed are 1434, 1438, 1436
              #1686: op_state in pre-authz
                           Torsten said that you don't send the pre-authorized code to the authorization request
                           Torsten said that op_state is really tied to the authorization flow
                           Torsten: op_state is used with the authorization endpoint, the pre-authorized code is used at the token endpoint
                           Kristina asked whether both should be permitted
                                         Torsten said that you cannot use both
                           Torsten thinks that the pre-authorized code takes precedence
                                         Kristina said that she doesn't think we should be the ones to define the precedence
                           Torsten agreed to do a PR
              #1648: passing issuance initiation request by reference
                           Kristina said that op_state becomes huge because it's an encrypted token
                                         It blows up the QR code
                           Kristina asked if there could be a way to pass it by reference
                                         Torsten doesn't see a need for passing it by reference
                                         The op_state is created by the issuer and consumed by the issuer
                           Torsten said that we'd be forcing the wallet to fetch a huge block of binary data and pass it to the authorization request
                                         Torsten suggested having access to the state happen within the AS
                           Kristina said that this is about having the AS be able to be stateless
                           Torsten said that using a request_uri introduces state at the AS
                           Torsten said that the value of the op_state could be a database table index, since it's opaque to others
              #1687: Do we need to support signed issuer initiated issuance requests?
                           Torsten thought that signing the request would authenticate the requester
                           David said that you'd have to social engineer the user to get them to go to the wrong site in the first place
                                         Torsten said that signing would let the request be matched against a list of authorized issuers
                                         Tom was skeptical of there being a list of authorized issuers
                           Mike agreed that signing the request would enable authenticating the requester
                           Torsten proposed asking Daniel Fett for a security assessment
              #1570: Rename Initiation issuance Request to..? Credential Offer?
                           We discussed whether we can find an easier-to-say term than Issuer Initiated Request (IIR)
                           We want people to understand that this flow reverses roles
                                         It's a request for the issuer to make a request
                                         Mike called it a "Request Request" on the call
                           People are encouraged to suggest better names
              #1720: define user identifier when proof is signed using JWK
                           It would be a JWK Thumbprint URI
                           Kristina will write a PR

PRs:
              PR #255: Determining if one party may be able to trust a second party.
                           David explained the problem on the call
                           Mike said that this is meta-protocol information
                                         It's not clear that we want to pass this at runtime
                           Torsten said that it's not clear why you would trust the trust information passed to the request
                           Torsten disagreed with the term "trust framework"
                                         David said that it's now "trust method"
                           David said that each trust method would determine the payload for its trust method information
                           Torsten wasn't in favor of doing this
                                         He said that SIOP already specifies how to determine this information
                           Kristina plans to close the PR to consolidate the conversation in the issue
                                         The issue is #1551: Administrative Trust in the RP

Issues:
              #1707: cryptographic_binding_methods_supported Support for listing specific DID methods?
                           People thought this is reasonable
              #1689: Encoding of Issuer Initiated Issuance Requests
                           We discussed possible alternative encodings: form-url, base64url
                           We are currently using a JSON object passed form-url encoding
                                         Mike thinks the current approach is fine

Next Call
              We plan to cancel the SIOP call next week because of IIW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20221110/70759af5/attachment-0001.html>