[Openid-specs-ab] Spec Call Notes 14-Feb-22
Mike Jones
Michael.Jones at microsoft.com
Tue Feb 15 17:28:30 UTC 2022
Spec Call Notes 14-Feb-22
Mike Jones
Nat Sakimura
David Waite
Vittorio Bertocci
Kristina Yasuda
Tom Jones
Edmund Jay
David Waite
Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1400: Issuer Handling in SIOP
Also see PR #120: Issuer Handling SIOP
Vittorio wants us to enumerate use cases where the values might be different
He's asking for clarity - not pushing back on potentially doing it
Kristina pointed out that in SIOP v1, the "sub" was the key, whereas the "iss" was the constant https://self-issued.me/
Kristina said that use cases for multiple accounts are absolutely valid
Kristina said that we might provide information about software, certification, etc. via an attestation
Vittorio said that we already have "iss" and "sub" as distinct entities, which we can already use
A fundamental point in traditional OpenID Connect is the ability to acquire a key via the issuer
Making "iss" == "sub" moves us in this direction
Vittorio suggested that we need guidance on *why* to use different features - not just implement the cartesian product of possibilities
DW said that in traditional OpenID Connect, "iss" can be used to judge the reputation of the issuer
He said that in OpenID Connect Federation, there's a whole resolvable tree of reputation information
DW said that Ping was intending to use the issuer to identify a trust framework
He agreed to file an issue comment about that
Claims Aggregation Spec
Edmund reports that he's merged some of the PRs
New issue #1435: Listing of of individual claimset claims instead of single list of claims
Mike suggested that we use the existing "claims_supported" metadata element
More Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1429: Replace JWK Thumbprint URI with JWK URI
We reviewed the issue comments
Mike doesn't want to break the invariant that "sub" is the primary key identifying the account
In SIOP v1, we defined JWK Thumbprint so that there was a limited-size stable "sub" identifier
For some post-quantum algorithms, the keys are huge
DW said that even for RSA keys, JWK URIs wouldn't necessarily fit into usable ID Tokens due to browser URL limitations
Mike (not as chair) said that he doesn't see sufficient support for doing this because of all that it breaks, so we should close the issue in a week
DW said that this wouldn't be a replacement for JWK Thumbprint URIs - that it would be an option alongside the others
Nat (as chair) said that we might close this if there isn't sufficient support soon
There was a discussion about key rotation, which using a key (or key thumbprint) as the identifier doesn't support
#1434: Dubious support for authentication
Kristina said that there's confusion between the user identifier in the ID Token and the user identifier in a VC
Kristina said that David Chadwick may be thinking of use cases where the OP is also the issuer of a VC
Vittorio said that we've decoupled identity from credentials
"We decoupled the subject identification from the raw credentials necessary to identify/authenticate"
And that we introduce confusion when we mix them together
Nat said that David's issue seems to be conflating user authentication and claims about that user
Claims about the user are usually not sufficient to authenticate the user
Nat said that we cannot use the VC as proof of user authentication
OSW
Registration has opened for the OAuth Security Workshop
https://oauth.secworkshop.events/osw2022
Next Call
The next call will be a SIOP special topic call on Thursday, February 17, 2022, at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220215/bec2d3ec/attachment.html>
More information about the Openid-specs-ab
mailing list