[Openid-specs-ab] Notes SIOP call agenda (2021-09-30)

[Kristina Yasuda]

Anthony Nadalin
Giuseppe De Marco
Justin Richer
Adam Lemmon
Joseph Heenan
Stephane Durand
Axel Nennker
David Chadwick
Mike Jones
Torsten Lodderstedt
Giuseppe De Marco
Bjorn Hjelm
David Waite
Dmitri Zagidulin
Kristina Yasuda

Regrets: Jeremie Miller, Daniel Fett


- Agenda adopted

- Events/External orgs

  *   ISO 18013-5 mDL spec published: https://www.iso.org/standard/69084.html
     *   Kristina asked comments on the option discussed in ISO 18013-7 (an updated version of part 5 that focuses on online use-cases) to do a direct HTTP POST of a VP from the app to the RP
     *   Torsten asked about the request syntax in such case. Kristina to report back
  *
  *   DCMS UK Trust Framework comment period: https://github.com/Alastairtreharne1/Digital_Identity/blob/main/DRAFT_Technical%20Guidance%20-%20W3C_Verifiable%20Credentials__20210730%20(2).pdf
     *   Includes Digital high level guidance for use of Verifiable Credentials
  *   DIF special calls discussing how to integrate PE in OIDC4VP were merged with "Credential Manifest + Presentation Exchange Weekly calls in C&C WG" @10-11AM PST on Thursdays
     *   you can add a google calendar by decentralized.identity at gmail.com OR outlook calendar invite is attached

- PRs

  *   https://bitbucket.org/openid/connect/pull-requests/
     *   PR #50 response-as-push has been updated
        *   Mike asked how SIOP would do a direct POST to the RP when majority of the RPs are behind the firewall and agreed to file an issue on this topic
        *   Torsten said that direct POST only works if SIOP and RP are in the same Network direct POST works, if on separate networks, an architecture such as cloud agents relaying or modifying the response so that RP can poll it, might be needed
        *   Justin agreed with Mike that direct POST will not work with RPs that are not Web servers, such as applications, SPAs, etc. He also said that IdP initiated login where RP is sitting and waiting for the connection from IdP is dangerous as Golden SAML attack proved last year.
        *   DW pointed out that in SIOP, form_post has the same firewall problem as direct POST and PARM (Pushed Authorization Response Mode) since it will be coming from SIOP in the user agent, and not a separate hosted infra to be able to do send in the web context, and you can only send data in URLs
        *   Can send cross-ups with Universal links, but not custom URL schemes or open redirects, but than will hit Platform URI size limitation, seems to handle up to 1MB these days
           *   https://bitbucket.org/openid/connect/issues/1342/reevaluate-uri-length-restriction
        *   Torsten suggested to spend some time to think about it/design solutions and discuss in future calls again
        *   RP without any hosted infrastructure, even in DPoP, trust in the keys is solved by having a higher authority
           *
           *
     *   new PR #51 Resolvable entity identifiers ie resolvable client_id
        *   DW filed an issue based on the discussion: https://bitbucket.org/openid/connect/issues/1345/relying-party-instances-and-metadata-in
           *   Two big topis were 1/ implications of trusting the keys you have never seen before; and 2/ when RP cannot have a hosted infrastructure
        *   DW said his PR has consequences to the registration/registration_uri parameter inside the request, allowing it to be included only when RP has a preexisting relationship with SIOP, because they are problematic - for example when RP signign keys are communicated in the request that is signed itself
        *   Dmitri said he believes you need both capabilies - resolvable entity identifiers and registration parameter for mobile apps or SPAs, that cannot have a hosted infrastructure with ephemeral keys per instance
           *   We discussed that domain validated certificate from the RP cannot be used because many RPs do not have that certificate.
        *   Justin said you can trust the keys you have never seen before by associating them with any subsequent requests, sessions, releases, etc.
           *   This might work in SIOP only if client_id was unique per RP instance, which is currently not realistic because there is no affordances to authenticate the client by anything other than the redirect_uri. Dmitri said this is why the RP cannot "change" registration metadats since every registration is "one-time".
        *   Justin pointed out that RP trusts SIOP's signing keys that it has never seen before. David C pointed out that for SIOP, it is possible to add trusted third party signed claims, and suggested we use VCs to add trust to RPs.
           *   "Self-Issued RP" term has been mentioned several times
           *   Justin agreed with the notion of application attestation set to the server, and pointed out that the issue becomes where to include such attestaiton information in the request
        *   We did not agree if usage of registration parameter in SIOP is functionally similar to Dynamic Client Registration (DCR)'s trust model
        *   We agreed that the goal is to have a mechanism that allows for the equivalent of DCR without hosted infra for persistent clients, as opposed to have ephemeral clients/requests without persistence, and discussed an mechanism close to a DCR with a SW statement for RPs without hosted infra while being able to maintain relationship with different parties

     *   PR #45 additional OIDC4VP security considerations waiting for few more approvals to be merged
        *   Adam agreed to review. Torsten said he also asked Daniel Fett

- Issues (https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation)

  *   https://bitbucket.org/openid/connect/issues/1273/mitigating-security-risk-by-using-webauthn
     *   we discussed that caBLE is very promising to mitigate cross-device security, but is few years away from being ready
     *   and considered adding a general non-normative language on using proximity between RP and SIOP as a cross-device security enhancement
  *
  *

Thank you everyone for a great discussion!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211001/626e6b89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 3430 bytes
Desc: invite.ics
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211001/626e6b89/attachment.bin>