[Openid-specs-ab] SIOP call notes (2021-10-05)
Kristina Yasuda
Kristina.Yasuda at microsoft.com
Thu Oct 14 06:07:22 UTC 2021
Andrew Hughes
Dmitri Zagidulin
Anthony Nadalin
Michael Barrett
Tom Jones
Juan Caballero
David Waite
Jeremie Miller
Pamela Dingle
Kristina Yasuda
Edmund Jay
Dima Postnikov
Regrets: Mike Jones
- IPR reminder/recording
- Introductions/re-introductions
* Juan Cabarello from Spruce Systems
* Andrew Hughes, Ping Identity
- Agenda adopted
- Events/External orgs
* An OSS library for SIOP v2/OIDC4V by Sphereon/Gimly: https://github.com/Sphereon-Opensource/did-auth-siop
* How Sphereon's SIOP experiments support the "ESSIF-LAB stack": https://github.com/Sphereon-Opensource/essifi-deliverables/blob/da429b54ed03f1e4834dc53f62e04e4fb0b2c90c/interoperability/envisioned_interoperability_with_others.md
* DIF is trying to figure out how to frame and support ongoing work on the interop profile for said stack; the straw man for it is here: https://essif-lab.eu/verifier-universal-interface-by-gataca-espana-s-l/
* Recording of the implementation demo: https://www.loom.com/share/d49e005bb32349d7950022e83d55b944
- 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%7Ce1171353e47a4e1a1a0c08d983d93ebf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685792432549677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=tpkG2lX0kKgtbijFnsnQiqyioAiZ4N%2FE%2FoZzZPjof5k%3D&reserved=0>
* PR #50 response-as-push has been updated (firewall issue to be discussed)
* we agreed to add a clarifying text that for cross-device SIOP, RP needs to expose a public endpoint. This is not an issue for the same device SIOP where redirect works.
* Jeremie also pointed out that PARM is not relevant for the RPs who don't have infrastructure at all, so PARM is optional in SIOP.
* We also confirmed that with PARM, user will start the flow on a separate device but end on the same device.
* PR #51 Resolvable entity identifiers covers resolvable client_id
* The discussion was around whether to be "authoritative", entire registration metadata needs to be included in the object obtainable by resolving a client_id, or not.
* There are use-cases that do not sign the SIOP request, and require preservation of the registration parameter.
* To address security concerns we discussed adding a text that "additional redirect_uris should not be accepted even if they are passed inside the registration parameter in the request."
* DW proposed to explicitly define which registration parameters can be included directly in the request.
* We discussed that using public keys as the Client identifiers is not recommended
* We discussed that when DID is used as RP's client_id and binding of that DID to the domain is proved, key material can be obtained from the DID Document, but to obtain the rest of the registration metadata, rather than making another NW call (to a .well-known/openid-config for example), it would make sense to keep registration metadata except for the key material inside the request.
* There is no way to include registration metadata except for the key material in the DID Document, which has strictly defined properties
* Tom Jones pointed out that metadata does change frequently (like terms of use)
* Jeremie proposed opening an issue on "Self-Issued RPs"
- Issues
* https://bitbucket.org/openid/connect/issues/1342/reevaluate-uri-length-restriction
* DW clarified that the issue is about the length of the redirect of POST URI, HTTP POST method does not use URIs.
Best,
Kristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211014/2ee1ba09/attachment.html>
More information about the Openid-specs-ab
mailing list