[Openid-specs-ab] SIOP Special Topic Call Notes 05-Jan-23

[Joseph Heenan]

Attendees:

Joseph Heenan
Takahiko Kawasaki
Kristina Yasuda
David Chadwick
Brian Campbell
Torsten Lodderstedt
Niels Klomp
Vittorio Bertocci
Oliver Terbu
Bjorn Hjelm
Jeremie Miller



Kristina/Torsten mentioned the new drafts and covered the rework that has been done in these new drafts, much of which was driven by feedback from the European Union & ISO - as per Torsten’s announcement:

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html

added support for signed and encrypted authorization responses based on JARM
clarified response encoding for authorization responses
moved invocation/just-in-time client metadata exchange/AS Discovery sections from siopv2 to openid4vp

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

introduced differentiation between credential issuer and authorization server
relaxed client identification requirements for pre-authorized code grant type
renamed issuance initiation endpoint to Credential Offer Endpoint
added grants structure to credential offer


Feedback on structure / readability is very welcome.



Brian: Structure & content is hard

Vittorio: Same device seems to be treated as main/default flow, with cross device being a variant. Would expect them to be at the same level. No preamble explaining which device is taking which role in cross device flow. The VCI spec is hard to read without having read VP first. When SIOP spec links to VP, it should include a bit of explanation as well. Should not assume people have already read the other specs, each doc should stand on its own legs.

Kristina: Please do raise PRs for any editorial issues like capitalisation etc. Anything non-editorial

Torsten: We should be able to simplify the SIOP spec by referencing the other specs.

Vittorio: If the specs are separate, they should standalone. The concepts/purpose should be explained when SIOP links to other specs.

Torsten: Worries that this might result if things being explained in two places they might get out of sync

Vittorio: Agrees normative text should not be repeated, and OAuth2 doesn’t need to be explained from first principles. But e.g. Section 7.2 of SIOP says "as defined in section x of blah” - it should have a sentence “There is a mechanism that does <x> that is defined in <spec y>”.

Torsten/Kristina agreed, will look into it, please do raise issues.

Brian provides a specific example of an example in SIOP that says it’s a signed request, but isn’t signed, and that uses DID but doesn’t really explain how DID is being used.

Kristina:  DID use is explained in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#DID



Please review pull requests:

391 Editorial

387 Editorial 4VP cleanup

359 clarify client behaviour with regard to nonces
May need Richard on a call to discuss.
 
360 access token hash - no consensus in WG yet

384 Add CWT proof type
Torsten would really appreciate if someone familiar with CWT could review this.
Brian noted it mentions JWT in a number of places that are C&P errors.

389 passing credential offer by reference


https://bitbucket.org/openid/connect/pull-requests/374

Kristina will help resolve conflicts.


https://bitbucket.org/openid/connect/issues/1412/add-wallet-attestation-to-the-siop

David asked if the wallet or the wallet provider would sign the response. Torsten said it could be either, but that there’s no real world implementation experience of this yet.

Kristina suggested closing if it’s already clear that JARM can be used to sign responses.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230105/e284ac19/attachment.html>