[Openid-specs-ab] SIOP special topic call notes (2021-08-10)

[Kristina Yasuda]

Nat Sakimura
Tim Cappalli
Michael Barrett
Jeremie Miller
Tom Jones
David Waite
Jace Hensley
Edmund Jay
Brian Richer
Kristina Yasuda

- Introductions/re-introductions

  *   Jace works at Bloom, involved in a WACI spec

- Events/External orgs

      - DIF Interop WG: call on WACI planned this Thursday - interop testing. Note that this call is NOT IPR protected, so anyone can join: https://github.com/decentralized-identity/interoperability/blob/master/agenda.md

      - DIF Presentation Exchange/OIDF WG call on Wed 11th at 1PM PT

      - DIF Wallet Security WG re-starting after 3 weeks of holiday break


- PRs

  *   SIOP V2 introduction and use-cases: https://bitbucket.org/openid/connect/pull-requests/41
     *   we agreed to merge this PR
  *   removing vp_hash in OIDC4VP: https://bitbucket.org/openid/connect/pull-requests/42
     *   we agreed to give a little more time to for the review


- Discussion (great discussion, would encourage to read and take a look at the diagram)

  *   Client_id in SIOP V2 https://bitbucket.org/openid/connect/issues/1272/client-identifier-in-siop-when-the-dids
     *   We discussed the proposal how client_id can be resolved by SIOP to obtain RP registration metadata
     *   DW presented the proposal using a sequence diagram: https://hackmd.io/@dwaite/SJRMV4jyY
        *   Describes how to use Entity Statements defined in OpenID Federation spec with SIOP: https://openid.net/specs/openid-connect-federation-1_0.html<https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5> (Sections 5, 6, 7, 9 are most relevant)
        *   Entity Statement (ES) is 1/ self-signed; 2/ can be about RP (conventionally used to be about OP); 3/ can have a chain of authority (supports trust frameworks and federations of parties who have agreed to certain terms, etc.), so that they allow just-in-time registration when interaction occurs.
        *   signed request objects are mandated for automatic registration (clarification for the OpenID Fed team pending)
        *   The diagram would not change even if DIDs are used instead of ES!
     *   Registration parameter in SIOP right now does not give authoritative metadata like ES would
     *   OpenID Federation does not limit authorities to HTTPS, so it only needs a way to resolve to an ES, and does not need to be hosted - would work for custom URLs or HTTPS universal links
        *   Minimal SIOP implementation does not need to require resolving authority_hint in ES and going up the trust chain
     *   using Automatic Registration section of OpenID Federation and DID Resolution section of DID-CORE would address comments made during the last call to be careful with clarifying expected behaviour with this new usage of client_id
     *   Issues to be filed (DW)
        *   1. Remove registration parameters in SIOP V2, as it opens up a security hole, and since Automatic Registration would be a better defined, more secure mechanism.
           *   Registration parameter allows to declare additional redirect_uris to override legitimate ones in the request object.
        *   2. SIOP metadata discovery (simplified version of OpenID Federation Metadata ES)
           *   no OP jwks
           *   should be only one metadata file per SIOP
        *   3. define a more abstract mechanism for resolving a subject identifier of a SIOP (currently jwk thumbprint or DID) inspired by OpendID Federation ES
           *   with an expectation that JWK set is available after the resolution. define as algorithms that can be used with the existing crypto tools
           *   might include Solid, OpenID Connect Web fingerprint, etc. ?

Issues

  *   SIOP V2
     *   Security Considerations: https://bitbucket.org/openid/connect/issues/1269/add-security-considerations-for-cross<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1269%2Fadd-security-considerations-for-cross&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C0e97c31cf7894a31be4508d950d34339%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629690781019460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=okTAjch1DqHOvE3Su34gY%2FeU1sUryxrvS7FcBXlw%2FOA%3D&reserved=0>
        *   Kristina shared a preliminary list of security attacks and mitigations identified so far
           *   Credential phishing, SIOP phishing (relay of a QR code), Open redirect, POST where the content becomes public, Server-side request forgery
     *   Using WebAuthn to mitigate cross-device SIOP security risk: https://bitbucket.org/openid/connect/issues/1273/mitigating-security-risk-by-using-webauthn
        *   Tim said that a small group has met and they plan to share the outcome of the discussion soon.

     *


Best,

Kristina





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