[Openid-specs-ab] SIOP Special Topic Call Notes 2-Feb-23

Mike Jones Michael.Jones at microsoft.com
Thu Feb 2 16:21:43 UTC 2023


SIOP Special Topic Call Notes 2-Feb-23

Mike Jones
Judith Kahrer
Brian Campbell
Oliver Terbu
Pieter Kasselman
Kristina Yasuda
Bjorn Hjelm
Dmitri Zagidulin
David Waite

Judith Kahrer from Curity introduced herself

Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              We merged a number of PRs during the week, including PR #419
              PR #432 should be good to go - reviews solicited
              PR #433 and #434
                           Describes use of cross-device flow on same device
              PR #425: add terminology source and delete base64url encoding definition (Issue #1789)
                           Kristina proposes to merge this after the call
              PR #427: OID4VP: client id format
                           Kristina explained the intent of this PR
                           Brian pointed out that the X.509 mechanism wasn't previously there
                                         We will separate this out
                           Issue #1798 is part of the discussion: OID4VPs - need to specify the trust model
                                         Signing requests in multiple ways would be problematic
                           ISO is interested in doing a pre-negotiation step before authorization
                           Mike asked why the additional parameter is necessary when we haven't needed it so far
                                         The OP has been able to look at the Client ID syntax and determine what it is
                                         Either it's pre-registered, or it's a Redirect URI or it's an Entity Statement URL
                                         ISO mdocs want to use X.509 certs
                                                       We need to define what the Client ID is in that case
                           DW asked whether the different Client ID schemes can be differentiated via their URIs
                                         He is concerned about attacks
                                         He is worried about client impersonation attacks
                           Kristina said that, for instance, in OpenID Federation, one would have to control the domain name of the .well-known to accomplish anything
                           Kristina said that having one mechanism per scheme may be impractical
                           DW said that having a Client Format makes the format part of the identity of the entity
                           Mike asserted that the existing formats can be distinguished without the format parameter
                                         He said that we shouldn't add it until it's clear that we need it
                           Kristina said that X.509 distinguished names might be indistinguishable from domain names
                           Brian said that additional mechanisms that are not well thought out were added to the PR
                                         These areas could be problematic
                                         Mike agreed that we shouldn't add X.509 and other mechanisms that aren't well-defined at first
                           Brian has concerns with the way that we're adding in dynamic client registration
                                         It's a mess and problematic
                                         He said that the idea of trying to make it explicit seems helpful
                           Mike agreed to add an issue comment with his views
                           Brian doesn't think that DIDs should be a Client ID format
                                         Kristina asked Brian to file PR comments
                           Kristina said that the editors have been incorporating feedback on the PR
                                         We're trying to minimize breaking changes after the second Implementer's Draft

Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation&component=Credential%20Issuance
              #1807: Signed Requests and Replay Prevention
                           Mike doesn't understand why making a second request with the same parameters as the first constitutes an attack

Next Call
              The next call will be Monday at 3pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230202/5db5e3da/attachment.html>


More information about the Openid-specs-ab mailing list