[Openid-specs-ab] Spec Call/SIOP Call Notes 11-Mar-22

[Kristina Yasuda]

David Chadwick

John Bradley

Joseph Heenan

Nat Sakimura

Torsten Lodderstedt

Brian Campbell

Filip Skokan

David Waite

Jeremie Miller

Jo Vercammen

Kenichi Nakamura

Kristina Yasuda



(Connect call notes followed by subsequent SIOP call notes)



  *   openid / connect / issues / #1456 - scopes metadata parameter needs to be defined - Bitbucket<https://bitbucket.org/openid/connect/issues/1456/scopes-metadata-parameter-needs-to-be>
     *   Two options to address undefined `scopes` parameter underneath `openid_relying_party`
     *   Roland and John agrees to define a new `scopes` parameter
o   Nat pointed out that `scope` (existing) and `scopes`(new) might be confusing and better name for scopes should be considered.



  *   openid / connect / issues / #1433 - [oidc4vci] role of the ID Token - Bitbucket<https://bitbucket.org/openid/connect/issues/1433/oidc4vci-role-of-the-id-token>
     *   Torsten pointed out that OIDC4VCI is different from JWT assertion spec because in OIDC4VCI Access token is opaque to the client
     *   David C. made three suggestions how to improve OIDC4VCI specification. Issues have been filed for each item.

        *   Clarify how user interacts with the wallet in the swimlane
        *   Add text on the trust model
        *   Clarify how authorization works
     *   No objections to moving oIDC4VCI to an Oauth based flow. PR would be useful


  *   Transferring PoP across devices (discussion continued from Pacific Connect Call on Monday)

     *   Use-case being user logged into an app on device A (laptop), but wants to receive credential into an app on device B (smartphone)
     *   John said caBLE is becoming increasingly promising - being deployed across major browser OS and mobile OS
     *   David C. described how in their implementation user sets up a WebAuthn connection with the issuer using the wallet. Ie user uses WebAuthn to log in on device A using device B, so that the Issuer can recognize device B later in the issuance flow
     *   John pointed out that that usage of WebAuthn can be looked at in both ways at a higher level:
        *   Using FIDO as a proof for VP or other tokens (issue to someone who controls private keys to this public key)
        *   Purely having a stronger authentication using FIDO
     *   It was pointed out this is close to how we use sender-constraint tokens

<<transition to the SIOP call>>


  *   openid / connect / Pull Request #128: Adds an option to make a credential request via scopes - Bitbucket<https://bitbucket.org/openid/connect/pull-requests/128>
     *   Merged
  *   openid / connect / Pull Request #134: Removing an option to submit a VC in the Authorization Request (#1443) - Bitbucket<https://bitbucket.org/openid/connect/pull-requests/134>
     *   Waiting for Mike to come back from vacation, since he has requested changes
     *   There might be concerns around clarifying why nonce endpoint is not effective in preventing replay
  *   openid / connect / Pull Request #101: Fetching presentation definitions from a remote repository - Bitbucket<https://bitbucket.org/openid/connect/pull-requests/101>
     *   https://bitbucket.org/openid/connect/issues/1440/choosing-how-to-transfer-presentation
     *   We agreed that passing presentation_definition by value should be mandatory to implement, while passing it by reference can be turned on via a new Registration/Discovery metadata
     *   We agreed that passing it by reference has a lot of value. Right now, most implementation pass by value and with request object already being passed by reference in many implementations, size of a presentation_definition is not a problem. We might revisit this set up if majority of implementations switch to passing by reference.
     *   Will merge once David C. updates a PR
  *   https://bitbucket.org/openid/connect/issues/1451/oidc4vci-mandatory-vs-optional-credential
     *   We agreed that it is Issuer's responsibility to ensure that all mandatory claims are included in a VC
     *   Kenichi pointed out that in mDL, user would not have much choice over optional claims, probably only over organ donation claim
     *   Selective release of optional claims might still be useful in other credential types
     *   David C. made a distinction between user providing consent in the wallet, and user providing consent directly to the Issuer
     *   John asked what if the Issuer issues more or less credentials then
  *   https://bitbucket.org/openid/connect/issues/1453/oidc4vci-holder-binding-material-without
     *   Kristina described how there is a use-case for this in SMART Health Cards
     *   David C. described another use-case where credentials for multiple users are stored in one wallet (airplane ticket for example)
     *   WG agreed to document such use cases and extend specification to support them
  *   https://bitbucket.org/openid/connect/issues/1454/oidc4vci-defining-a-credential-type
     *   David C. pointed out that type in vc-data-model is defined as URI, so URIs need to be supported
     *   We ran out of time while discussing this issue, will resume with this issue at the next call

Thank you!
Kristina

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