[Openid-specs-ab] SIOP call notes (2021-Nov-25)

[Kristina Yasuda]

Daniel Fett
Tom Jones
David Chadwick
Joseph Heenan
Stephane Durand
Niels Klomp
John Bradley
Francesco Marino
Giuseppe De Marco
Jo Vercammen
Kristina Yasuda


- IPR reminder/recording

- Introductions/re-introductions

- Agenda bashing/adoption

- Events/External orgs

  *   David Chadwick's proposal for simple PE profile: https://github.com/decentralized-identity/presentation-exchange/discussions/269

- PRs https://bitbucket.org/openid/connect/pull-requests/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fpull-requests%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cc25cb6e6379d4902265408d99fa5aa70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637716356217740950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z5lqVpVObmvm4JvGjplzu2DiT4np%2B1h2M2YCMoXJ1aQ%3D&reserved=0>

Please review PR #68, #75, #70 in particular.

  *   Discuss (max 15min each)
     *   PR#75 [OIDC4VP] adding few sections and clarifications
        *   we discussed that there seems to be two options to pass formats supported by the RP - in the vp_formats​ in the RP registration metadata and in the presentation_definition.formats​ in the claims parameter in the request
        *   John recommended that either way it should be deterministic
        *   Kristina to edit PR to clarify that if both present, ignore presentation_definition.formats​ since OIDC4VP can be used not only with SIOP flow and in non-SIOP OIDC clows, RP registration parameter is the main source of RP metadata.
     *   PR#70 simplifying did_methods_supported metadata
        *   agreed to merge did_methods_supported​ parameter into subject_syntax_type_supported​ parameter and to mention JWK Thumbprint URI defined in a new IETF draft:
        *   https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html
     *   PR#68 SIOP v2 revision
        *   agreed to merge and update the text once we agree how to handlei_am_siop​ claim

- Issues https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dopen%26component%3DSIOP%26component%3DVerifiable%2520Presentation&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cc25cb6e6379d4902265408d99fa5aa70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637716356217760961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BUjd1xBOM5qxPawjodzfkcQu3ercnM9DJSWLmHlsoVQ%3D&reserved=0>

  *    #1336
     *   comment made in favor of `vp_tokens` to clarify it can be ab array
  *   #1361 i_am_siop​ claim
     *   we discussed that RP expecting response from a non-SIOP will not be able to validate the ID Token even without an explicit i-am-siop claim because it will treat sub as a string but will not locally find an identifier matching to it.
     *   the question becomes whether this is enough to prevent confusing existing RP implementations when they unexpectedly receive SIOP ID token. we agreed to think about concrete attack scenarios to answer this question.
     *   We discussed that for new SIOP oriented RPs, i-am-siop claim would be enough, but have not reached consensus.

Best,

Kristina



<https://github.com/decentralized-identity/presentation-exchange/discussions/269>


PS. Below is what Tom Jones posted during the call as part of the discussion


crit

OPTIONAL. The crit (critical) entity statement claim indicates that extensions to entity statement claims defined by this specification are being used that MUST be understood and processed. It is used in the same way that crit is used for extension JWS header parameters that MUST be understood and processed. Its value is an array listing the entity statement claims present in the entity statement that use those extensions. If any of the listed extension entity statement claims are not understood and supported by the recipient, then the entity statement is invalid. Producers MUST NOT include entity statement claim names defined by this specification or names that do not occur as entity statement claim names in the entity statement in the crit list. Producers MUST NOT use the empty list [] as the crit value.
policy_language_crit

OPTIONAL. The policy_language_crit (critical) entity statement claim indicates that extensions to the policy language defined by this specification are being used that MUST be understood and processed. It is used in the same way that crit is used for extension JSON Web Signature (JWS) header parameters that MUST be understood and processed. Its value is an array listing the policy language extensions present in the policy language statements that use those extensions. If any of the listed extension policy language extensions are not understood and supported by the recipient, then the entity statement is invalid. Producers MUST NOT include policy language names defined by this specification or names that do not occur in policy language statements in the entity statement in the policy_language_crit list. Producers MUST NOT use the empty list [] as the policy_language_crit value.

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