[Openid-specs-ab] Spec Call Notes 10-Apr-23
Michael Jones
michael_b_jones at hotmail.com
Fri Apr 14 05:10:52 UTC 2023
Spec Call Notes 10-Apr-23
Nat Sakimura
Mike Jones
Aaron Parecki
Naveen CM
Vittorio Bertocci
Joseph Heenan
Aaron Parecki
Tobias Looker
Kristina Yasuda
Dima Postnikov
Events and Initiatives
Our OpenID Workshop will be on Monday, April 17th
Register at https://openid.net/2023/03/17/registration-workshop-at-microsoft/
Registrations are due by tomorrow. Do it now!
IIW immediately follows the OpenID Workshop
RSA is the week after IIW
Vittorio will describe all the different OpenID logout mechanisms in a presentation at RSA
There's an OECD event on privacy and security the same week in Paris
OASIS is starting a working group on schemas for Verifiable Credentials, led by Abbie Barbir
EIC in Berlin is in three weeks
External Orgs
We sent a liaison statement to ISO/IEC JTC 1/SC 27/WG 5 (Identity Management and Privacy)
OpenID Connect Federation Specification Status
Mike summarized current discussions about the OpenID Connect Federation specification
Spec currently establishes cryptographic trust between participants using Entity Statements secured as signed JWTs
Some also want us to enable the use of the Web PKI trust model
For instance, .well-known/openid-configuration and its "jwks-uri" value use this trust model
The GAIN POC uses Federation by also relies on the Web PKI trust model in some cases
This is used, for instance, to retrieve metadata from https .well-known endpoints
Tobias spoke in favor of retrieving metadata from .well-known endpoints being conformant behavior
The Research and Education community using SAML-based federations explicitly chose not to rely on Web PKI
This was due, in part, due to past breaches of and problems with TLS certificates and certificate authorities
The Federation spec, to date, which targets this community's use cases, followed this example
Some reviewers and deployers want to give deployers a choice of trust models
They want deployments depending upon Web PKI to be compliant with the specification
Mike said that the editors agree that the next set of edits will normatively add that choice to the spec
At the same we're not going to break anything that is already in use
We'll be adding choices, not removing or breaking anything
Then we plan to publish another Implementer's Draft
After that, unless developers and deployers tell us to do otherwise, we'll go for Final status soon thereafter
Kristina expressed that there are currently readability challenges with the specification
She said that features are defined but the big picture is hard to understand
Mike cited the example of the Messages and Standard specs from a decade ago
You had to read both of them together to get the big picture, which developers hated
We therefore merged them to create Core, which was *a lot* of work, but vastly improved readability
Mike said that editing using PRs is like looking through small keyhole, making it hard to see the big picture
Mike said that he plans to review and revise the spec in its entirety to improve its readability
Kristina asked about potential renaming
Mike said that Giuseppe is willing to shorten "OpenID Connect Federation" to "OpenID Federation"
This would parallel the use of "OpenID" by OpenID4VP and OpenID4VCI
We should seriously consider the impact of changing the existing branding when the spec is already in production use
Kristina said that core functionality of the spec is trust establishment, and the name should reflect that
Dima said that the Trust Registry Task Force in TrustOverIP is developing trust management mechanisms
The Federation spec could be applicable as a solution
He said that you need to be able to look up entities that you're interacting with
OpenID Foundation Process
Nat brought up a process point about the use of "OpenID" in specification titles
Mike wants to amend the process document to allow OpenID Foundation working groups to use "OpenID" in titles
In practice, this is already common usage by working groups
Mike also wants to amend the process document to legitimize using hosted services controlled by the Foundation
such as bitbucket.org/openid and github.com/openid
While relevant to the working group, these are actually board-level discussions
FAPI Profile of Federation
Joseph asked about having a FAPI profile for Federation
Dima said that there are profiles for FAPI such as the Brazilian profile
These profiles pick and choose what parts of the specs they use
He said that a profile might need 50% of FAPI, 30% of Federation, 10% of eKYC-IDA, parts of CIBA, etc.
ConnectID wants all-in-one certification profiles for its customers
We announced the OpenID4VP vote today
https://openid.net/2023/04/10/notice-of-vote-for-proposed-second-implementers-draft-of-openid-for-verifiable-presentations-specification/
Voting opens Monday, April 17th - the day of the OpenID Workshop
PRs
https://bitbucket.org/openid/connect/pull-requests/
PR #508: OID4VP editorial after the full read.
Oliver created PR #509 suggesting minor changes
Kristina will merge it into her branch and then correct a few things
Kristina will then merge and Mike will publish, updating the review blog post
PR #448: [Federation] Added appendix on using Web PKI cryptographic trust
Mike described in-person discussions on the PR in Yokohama
He described the desire to use existing metadata locations
It would then be a deployment choice
Kristina supported that
Kristina said that we also discussed the philosophy of not trusting TLS
She said that there are multilateral federations that are willing to trust TLS
Kristina said it will confuse people if the whole spec says not to trust TLS but then allows it sometimes
Dima said that he sees a need to be able to profile the Federation spec
He said that GAIN is using Automatic Registration and doesn't need Explicit Registration implementation
At this point, we think this PR be replaced by the more comprehensive edits proposed by Mike earlier in the call
PR #463: removing the requirement around JSON-LD processing (Issue #1840)
Kristina said there is still an ongoing conversation, so this isn't ready to merge
Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1912: Implementers that are willing to trust TLS
Kristina wrote down some of what we discussed in Yokohama
Lots of issue SPAM :-(
Mike to delete
#1887: Wallet attestation in SIOPv2 (implementation considerations)
Discussed in person in Yokohama
Depending upon how trust occurs, having a JWT attestation might be useful
(This is related to #1886)
#1886: New client authentication method for Wallet attestation
This may require a new JWT attestation client authentication method
This is waiting for a concrete proposal
Needed changes for next Implementer's Drafts
SIOPv2
Add client_id_scheme
Possibly refactor
OpenID4VCI
Add client_id_scheme
There are several important PRs outstanding
Cleaning up deferred issuance endpoint
There are PRs addressing feedback received, including from Taka
Refresh implementation considerations will be added
There are jurisdictions requiring periodic resigning over data to keep the signatures fresh
It's unclear that managing changing claim values is required functionality
We discussed using access tokens issued to the wallet, when the wallet can be a public client
We shouldn't be using long-lived tokens with public clients
DPoP is recommended for public clients that want to reuse tokens
Ideally they would be sender-constrained
Federation
Add description of option to use existing metadata in some profiles
Add description of option to trust Web PKI in some profiles
Technical issue about trust mark issuers
Liaisons
Nat asked people for quick review of his e-mail "Liaison statements to ISO/IEC JTC 1/SC 27"
Nat reported that we submitted several public comments on NISTR 8389 - Security Considerations for Open Banking
We also commented on the OECD Guidelines for Digital Identity
OECD guidelines were influential in creating GDPR
Next Call
The next call will be Thursday, April 13th at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230414/26ee0840/attachment-0001.html>
More information about the Openid-specs-ab
mailing list