[Openid-specs-ab] SIOP Special Topic Call Notes 28-Jul-22
Mike Jones
Michael.Jones at microsoft.com
Thu Jul 28 16:47:40 UTC 2022
SIOP Special Topic Call Notes 28-Jul-22
Nat Sakimura
Mike Jones
Kristina Yasuda
David Chadwick
Mark Haine
Jeremie Miller
David Waite (DW)
Bjorn Hjelm
Sunesh Shetty
Torsten Lodderstedt
Rolson Quadras
Jo Vercammen
Tobias Looker
IETF 114 is under way
A call for adoption of SD-JWT will go out to the OAuth WG
The JWP BoF went well, but didn't finish
It will be continued in a virtual interim BoF
Pull Requests
https://bitbucket.org/openid/connect/pull-requests/
PR #127: Added support for JWK URI
There are three requests for changes
Declined due to lack of consensus
PR #221: Update Issuer Initiated Credential Issuance
There are three requests for changes
David Chadwick asked us to reference a PR replacing it - PR #232 when declining
Declined due to lack of consensus
PR #222: Added Credential Refresh Use Case
Kristina said that there's consensus that this is out of scope
David Chadwick said that refresh is important
Jeremie said this kind of refresh isn't supported by OAuth
Kristina said that there are three requests for changes
Jeremie described this being a policy decision by the issuer, rather than part of the protocol
Mike said that just wanting to do refresh without defining protocol messages to do this is incomplete
Jeremie and Kristina and Mark said these are policy decisions
Mark said that we should be focusing on what the protocol does - not on policy decisions
Declined due to lack of consensus, referencing related issue #1552
PR #140: How is User Consent provided (Issue #1459)
Kristina advocating for declining the PR
Mike agreed
We made the meta point that it's better to agree in issues first before speculatively creating PRs
Declined
PR #259: (ed) Fixing mis-spelling etc. openid-4-verifiable-credential-issuance-1_0.md edited online with Bitbucket
Approved and merged
PR #252: clarified iat parameter of a proof (Issue #1568)
Mike to review and make suggestions
PR #226: change to openid://initiate-issuance:
This makes the proposed custom URL scheme legal
There are two requests for changes
Jeremie suggested that we discuss this in an issue
This solves #1500 - agreed to update based on #1570, #1560
PR #260: (ed) Fixing spelling and grammar errors in 3.5. of openid-4-verifiable-credential-issuance-1_0.md
Approved and merged
PR #247: folded deferred credential issuance into credential endpoint
Torsten recently updated the PR based on feedback
There was a discussion between Torsten, Kristina, and Jeremie on restrucuring the PR
Jeremie found it confusing that a handle or session identifier was called a token
Torsten suggested transaction_id
Mike suggested handle rather than transaction
Jeremie suggested issuance_code
People agreed
Torsten will update
Will merge then after ~3 approvals
PR #239: OpenID4VPs Scopes
Apparently the content of this PR had something odd happen to it and it no longer does the intended job
Torsten suggests closing this in favor of PR #258
PR #258: add scope support to OpenID4VPs
This facilitates using agreements between parties on presentations
Jeremie is in favor of the PR
Mike agreed to review
Kristina and Torsten agreed to clarifying changes to make the PR more parallel to other related text
PR #251: adding an example of presenting an LDP_VC signed using bbs
Torsten wants to review it
Kristina asked those with LD Proof experience to also review it
Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1577: Cryptographic proof of possession nonce management
Torsten described efforts to keep clients simpler
He discussed lifetimes of nonces
He asked how we want to provide nonces to the wallet, and whether to do so
Mike said that we want to understand what threats we're mitigating before deciding what mechanisms to use
Tobias said that there also usability considerations
We discussed whether to call the nonce "nonce" or "c_nonce"
If collisions with ID Token nonces are possible, we should use a different name
#1563: Managing Credentials with changing claim values
The proposal is to add an opaque identifier that uniquely identifies the set of credential claims
It would be up to the provider to decide what constitutes an update
David Chadwick said this is related to our earlier refresh discussion
Torsten said this identifier would be a shortcut
Or you could send the whole credential to an endpoint and if no changes have occurred, it could return with a 202
Or an ID could be included in a request
Using the ID would be optional
Tobias gave the example of wanting to get 10 instances of credentials with consistent claims
Mike asked if we need to facilitate getting multiple consistent instances
Torsten said that batch issuance might not support unlinkability
Mike realized that we're talking about this, because with a holder, things can get stale
Unlike Connect, where things are always fresh because you always go to the issuer
Torsten said there are two issues, which we should distinguish:
(1) Updating a credential in a wallet is one topic
(2) Having multiple consistent instances of a credential in a wallet is a different topic
Kristina asked Tobias if he could update the issue to make this distinction clear
Torsten said that this might be a version identifier or a credential instance identifier
The question is whether credentials are equivalent - not that it's an ID
We agreed to continue discussion of the issue
Next Call
The next call will be Monday, August 1, 2022 at 4pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220728/eb3b407a/attachment.html>
More information about the Openid-specs-ab
mailing list