[Openid-specs-ab] SIOP Special Topic Call Notes 19-May-22
Mike Jones
Michael.Jones at microsoft.com
Thu May 19 18:56:45 UTC 2022
SIOP Special Topic Call Notes 19-May-22
Kristina Yasuda
Mike Jones
Nat Sakimura
Torsten Lodderstedt
Giuseppe de Marco
Brian Clickenbeard
Jo Vercammen
Tony Nadalin
Kristina said that perhaps we should start calling this the OpenID for Verifiable Credentials special topic call
SIOP Whitepaper
We published the first editor's draft of the whitepaper
https://openid.net/2022/05/12/openid-for-verifiable-credentials-whitepaper/
We plan to update the use cases description
We plan to enhance the comparison to DIDcomm
Good comments are coming in
We will continue working in the Google Doc
https://docs.google.com/document/d/1H556GIM_xD1yKl7rw1seq4bu83movFCkU8fQ7T8b1dI/edit#heading=h.vwd38qa4vfe4
Some changes in the published Word doc are not yet in the Google Doc
Kristina plans to incorporate these changes into the Google doc next week
Open Pull Requests
https://bitbucket.org/openid/connect/pull-requests/
PR #176: Base OpenID for Verifiable Presentations on OAuth
Torsten asked if it's beneficial to be able to do presentation without an ID Token
Existing wallets have presentation as the primary use case
Torsten said that implementing the ID Token functionality is an additional implementation barrier
Torsten said that scope values can be used to request credentials
These are structured scope values (much like FHIR did)
Mike said that AAD doesn't support dynamic scope values
Kristina said these values will be static for a given deployment
Torsten said that this isn't like the Berlin Group scopes, which are truly dynamic
Mike said that he believes that AAD also doesn't support scope names with colons in them
Kristina asked if people agree with the general direction of this PR
Mike agreed with it
Tony disagrees with overloading scope in this manner
He said that we fought to keep scopes unstructured in RFC 6749
Torsten said that should get feedback from implementers
Torsten said that the "openid" scope introduces dependencies among scope values ("profile", "email", etc.)
Whereas the scopes in this PR can be processed independently
Brian said that Occam's Razor says to keep things simple
He said that the challenge is to communicate the technical experts' context to implementers
Brian said that people at top corporations don't understand how OAuth or OpenID Connect work
Or what value they provide
He's constantly explaining the difference between OAuth and OpenID
And the developers can still be lost
Mike said that OpenID Connect is plumbing - not a consumer brand
and we define End-User as being the human participant
PR #170: rename to openid for credential issuance
People suggested the name "OpenID for Verifiable Credential Issuance"
This aligns with the branding in the whitepaper
Tony said that some people will misunderstand this
Kristina said that we'll need to keep evangelizing our definition of the term "Verifiable Credential"
PR #157: Building Trust between Wallet and Issuer
Torsten said that this is mostly security considerations
Torsten said that he'd addressed Mike's comments about the use of "x5c"
Mike agreed to re-review
Nat asked Torsten to create a related issue
He wants us to record discussions in issues
Torsten said that, practically, some people will comment in issues and some will comment in PRs
So it can be hard to keep track of both
Torsten and Kristina said that there's already an issue on trust models for wallets
Related issues are #1457 and #1461
Nat brought up the situation where the issuer goes out of business
We want the person to still be able to use the verifiable credential
Torsten said that in high-security scenarios, the issuer should be responsible for the whole lifecycle
Giuseppe asked about having signed_jwk as a claim
This is closer to the trust model used by eIDAS2
Torsten said that we added "x5c" to support attestations
Giuseppe asked how long he has to provide feedback
We agreed that one week would be fine
Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1499: Clarify how SIOP/Open4VP can be used to present credentials offline
Kristina said that the needed keys would need to be retrieved in advance
Whereas a DID may need to be verified in real time
did:key might work offline but not most DID methods
Nat said that this might not be a totally offline case
For instance, the wallet might be offline whereas the verifier is online
Other permutations of offline and online are possible as well
Torsten agreed with Nat that we need to be clear what "offline" means and what use cases we want to support
Torsten gave the example of entering a football stadium
Kristina gave the examples of being stopped in a tunnel with no Internet connectivity
and having just arrived in an international airport with no SIM card or Wi-Fi connection
Kristina said that AAMVA wants a comprehensive package
Kristina said that key management and revocation also come into play
Next Call
The next call will be on Monday, May 23, 2022 at 4pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220519/f583905c/attachment.html>
More information about the Openid-specs-ab
mailing list