[Openid-specs-ab] SIOP Special Call Notes 30-March-21
Kristina.Yasuda at microsoft.com
Fri Apr 2 18:59:53 UTC 2021
Below are the notes from SIOP Special Call on 30-March-21. They are also in the wiki: openid / connect / wiki / 2021-03-30 — Bitbucket<https://bitbucket.org/openid/connect/wiki/2021-03-30>.
As promised, I created a SIOP Use-case document Wiki here: openid / connect / wiki / SIOP Use-cases — Bitbucket<https://bitbucket.org/openid/connect/wiki/SIOP%20Use-cases>. Please contribute your use-case and the problem that is being solved! You should be able to directly edit the wiki page. I started working on three sample use-cases as a starting point.
Regrets: Oliver Terbu
- Kristina asked if a formal document with use-cases that require SIOP will be useful. It could be used as a guidance when making architectural decisions related to SIOP V2 draft.
- Mike agreed that this would be valuable. it is helpful to know in what kind of situations people are willing to use Self-Issued OP. Will be helpful with making choices with Verifiable/Verified Credentials for example.
- Vittorio also agreed with the need of such document. For example, the concept of an End-user controlling an identifier is not automatic in the spec reader's head.
- Tobias said that it may appear orthogonal, but the use-case document will also be helpful when clarifying the definition of Self-Issued OP and what changes and benefits it affords
- Tom said that he has a negative view on the use-cases when use-cases are created to justify what peole are building
- Mike stated that the fact that people are doing something means that they have a concrete reason to do it.
- Justin stated that We should focus on problems that people are interested in solving, not on solutions. That way use-case document is helpful in guiding technological discussions and directing towards consensus.
Following the discussion, Kristina started a SIOP Use-case document Wiki here: [https://bitbucket.org/openid/connect/wiki/SIOP%20Use-cases](https://bitbucket.org/openid/connect/wiki/SIOP%20Use-cases) Please contribute your use-case.
- [Issue #1212 Universal URL Based Discovery for SIOP](https://bitbucket.org/openid/connect/issues/1212/universal-url-based-discovery-for-siop)
- Mike: Terminology matters. What is talked in this issue is not discovery and should be called choosing or selection.
- The group agreed to call this functionality **Self-Issued OP Chooser**.
- Tobias: To be more crisp, we are talking about three way negotiation btw RP, OpenID provider and end-user. What are we changing about the end user choice?
- Tom: there is nothing about standard in Self-Issued OP chooser. RP website can be made to be the link to the chooser
- Mike: We can do that now, but it is not happening. there is guidance for implementing user experience for choosing in OpenID Connect Discovery spec.
- Justin: There are two stages of IdP discovery, 1/ Figure out the issuer you have to go to; and 2/ How to deal with the issuer
- Jeremie (chat): the list in this issue is managed by a trust framework, not the user or relying party
- Tobias encouraged the group to look for a generalized solution so that the account chooser would work for both Self-issued and conventional providers.
- Justin: the problem has always been to get RPs to trust any providers, does not matter if it is distributed or centralized. Either getting RP to do a general discovery like in this issue, or asking RP to put your button on their NASCAR screen.
- Mike: in the Academic Research and Federation world this is done all the time. In the Open ID Connect Federation spec, that's done via a hierarchy of trust statements by participants chaining up the roots of Trust. Such entity statements provide natural ways of establishing trust with providers that were unknown.
- Vittorio: We are possibly stretching trust analogy too far. Usually RP chooses whom to trust. In this particular case, we implement user identity. Is trust still a right term? Does it make sense to talk about discovery?
- Tobias: Self-Issued OP's trust model becomes difficult to reconcile to OIDC, since conventionally provider identity is often important to RPs, and SIOP uses self-issued.me as `iss` and signed with the a key of an identifier that represents the user.
- Vittorio: There is a difference btw RP saying I will accept token from this provider vs I will accept self-issued tokens and acceptance such as validation of the token and user comes later. **In SIOP, decision is made based on the particular content of the token, rather than the provenance of that token.** (on the NASCAR screen) Does it make sense to put SIOP button next to the other IdP buttons from the traditional trust model?
- Pam (chat): are we talking about SIOPs and NLOPs, as two sub-classes of OP? (Where NLOP is "network-located" OP)
- David (chat): the ideas of claims aggregation and portable identifiers is to reduce the importance of the OP to that of a chosen and replaceable intermediary (to provide higher value authentication).
- David: traditionally, as a RP, you did not necessarily have an idea how to evaluate trustworthiness of either side - subject and OP. With SIOP, RP can evaluate the provenance of the data directly, and even if a business went under, you will be able to authenticate the user again, or do other means to recover their account access. In terms of reliability does not really matter as long as the user has access to the underlying Verifiable Credentials.
- Vittorio: many differences: we just established it is not matter of trust - OP does not prove its identity what is important is the user. In SIOP, OPs are acting more as Attribute providers, not really as authentication providers. Does it have to be OpenID? Do we have to do SIOP or something else to manage VCs?
- Mike: there is no OIDC trust model. Whether to use a provider and which actions to take upon the claims received from the provider is entirely up to the RP. We can't change that
- Tobias: does not know if the current signing mechanism in SIOP is correct. keys used by the end-user are controlled by the provider.
- Justin: lost in philosophy of distributed identity, but ultimately it is about SW talking to SW
- Vittorio: key point - there is a difference btw SW that has its own identity and an identity on which we can base decisions. Provider that I trust and which user is not important vs when SW is just a tool and does not have its own identity. As a RP, there is a difference btw dealing with only one key and potentially tens of millions of keys
- ...this is not just about practicality like cost, but it is a matter of how these tools are used to model relationships. In theory should technically work because just signatures, but in practice there is a big difference in how people think about factoring their systems and the way system will perform in practice.
- ...in practice, if I have tools that works, and if they stop working, the concept of trust is not useful to solve the problem anymore.
- Justin: We are modeling a different kind of trust. trying to trust a fundamentally different kind of thing. Now cannot yet imagine seeing log in with SIOP under log in with Facebook, Google, etc.
- Jeremie agreed in chat that the conversation has been helpful to take next steps for another draft
- Tom introduced [Issue # 1215 SIOP requires user consent](https://bitbucket.org/openid/connect/issues/1215/siop-requires-user-consent)
- Issue [#1205 Indicating support for VCs (SIOP)](https://bitbucket.org/openid/connect/issues/1205/indicating-support-for-vcs-siop)
- DW gave update on the work to provide a means of supporting BBS+ and similar privacy-tooling signature types consistent with the JOSE stack. Draft coming.
- Related good discussion happening in W3C CCG Mailing list
From the chat:
- Tom: start of a trust model for us health care right now it only address trust in the app (aka wallet) https://trustregistry.org/
Trust Registry Home - RegistryDemo<https://trustregistry.org/>
The website is a demonstration of a registry of credentials for mobile phone applications and developers conforming to the evolving draft specification for a Mobile Authentication Assurance Statement.These credentials can be used to allow relying parties in healthcare (and other) communities to determine if the user's application can be trusted.
差出人: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
送信日時: 2021年3月18日 0:41
宛先: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
件名: SIOP Special Call Notes 16-March-21
Balazs Nemeti (DIF)
Erik Zvaigzne (Convergence tech)
- regrets: Mike, John, Nat
- Introductions: Balazs, works at DIF
- In PDT, the time of the calls are at 3pm from this week.
Agenda: Issue Discussion #1212 Universal URL based discovery for SIOP https://bitbucket.org/openid/connect/issues/1212/universal-url-based-discovery-for-siop
Overview of the proposal/initial Q&A
* - Jeremie gave overview of a proposal. A practical approach that tackles user experience issue with openid:// with what is available today.
* - Two aspects to the proposal: 1/letting the user choose the application; 2/handling multiple apps.
* - 1st aspect: RP wants to provide a user a choice of which app they might use SIOP with: can be mobile app or PWA. To prevent a NASCAR screen, it can be a discovery endpoint that provides linking into an app/PWA a user chose to install (universal links)
* - RP links to a URL of the shared site that contains metadata of the identifiers for all of the applications that can satisfy that request. If the user have chosen one, it will be automatically launched. If not, the user will be displayed with the option of available apps/PWAs
* - Tom: This can potentially be a very long list (on the shared site)?
* - Jeremie: Kristina and Pam suggested that this solution is best applied within a trust framework that RP belongs to.
* - Tom volunteered to provide such trust framework for the healthcare.
* - Alen: Two questions: 1. this can be a single point of failure. 2. Who would be responsible for paying and managing all the traffic.
* - Jeremie: this site will handle only the request. and if the user has an app installed natively, the site does not even get a request and. very little traffic unless user does not have an app and needs to discover.
Demo by DW
* - [Demo 1] David showed a screen with Apple app metadata cashed by Apple that indicates which apps are able to take control of the authorize path on this particular server.
* - David showed a not very helpful error screen that using openid:// option gives if user does not have a wallet installed. potential attack surface for fishing if a malicious app gets invoked first.
* - With universal links, if no app installed, user gets a list of potential applications and how to use them (including PWAs)
* - David installed an app real time. Now when user clicks a log-in link at the RP website, user is taken directly into a native application, authentication is performed and user is taken back to the RP.
* - (going between web-based flow and Native app flow using universal links instead of custom URL schemes)
* - openid:// does not let you choose which app to open. In this proposal, there is a predictable behavior, but it is a prioritized list.
* - [Demo 2] brewery app asking for the proof of age. User is presented with a screen with an option to install an app or use already installed State Identity Card. Uses Share Sheet functionality, based on the metadata that applications have at publication time about what kind of files they can deal with.
* - proof of age got shared right away because user has consented through the OS mechanism
* - for proof of age, passport and state id apps were options, but for shipping address, only state id app depending on the claims supported.
* - presentation exchange not used.
* - the app does not know which RP requested the address.
* - Kristina is looking for a way to share the recording of the demo publicly.
* Share Sheets
* - Oliver: How do you find the sharesheet provider? on iOS, Android, Windows, native versions of sharesheet capability exists. On Mac could be limiting, but can use.
* - David: Have talked to Apple and this proposal uses more features than usual apps, but is not against any rules. Share Sheet functionality is important because app store (and probably users) will reject any app that require another particular app (App A using only App B for authenticaiton for example). Have been working on app-to-app scenario for a while.
* [Comments in chat how this would work reliably today, but OS vendors, Browsers could change things anytime without prior notice]
* - Tim: Apple and Google's participation is required. We need a broker mechanism at the OS level. OIDF level engagement is needed.
* - Jeremie: yes, the motivation of this work is to build something demonstrable, show that this is workable using the native capability, but not ideal, and ncourage OS vendor's participation to improve.
* - DW: privacy centric browsers, not very keen to rely on several large social networks should be interested in this new scenarios and enabling users to bring their own identity. Apple and Google would want to be on the broker list if they want to broker identity.
* - Tim: Apple and Google do not want you to bring your identity. (responding to a comment in chat that Apple and Google are working on vaccination credentials) there is a fundamental difference between gaining access to an app and passing information securely attested information.
* - Kristina: identifying use-cases would be very important
* - Justin: the most important thing is to get RPs to accept this. It was the case with OpenID Connect too. This has to be part of the conversation here.
* - Jeremie: opportunity is that discussion is shifting toward credentials which is different from authenticating and identifying yourself. and Google and Apple are not sources of those credentials.
* - DW: Does not see VC used for strong authentication, but looks at them as strongly attested attributes used for account recovery, or the link secret used to generate stable pseudonyms. how do I know DIDAuth is string enough? WebAuthn is strong enough, but it falls flat in recovery. Using strongly attested credentials tied not to the HW, but to the account for example could be used for the recovery.
* - Alen: Two questions. 1/ interop btw issuers and RPs. How does RP know how to validate credential from the issuer? 2/ what if RP accepts credentials only from the certified wallets and user has a needed credential in a non-certified wallet. Can I move a credential from one wallet to another?
* - DW: req can be richer, list of wallets can be filtered, to leave only those that can handle credentials requested by RP. (schema would have to be pre-agreed btw the RP and issuer) You will web-based fallback option - if a user does not have a credential RP wants, it can download a suitable wallet and get the credential.
* - Both the domain has to say they want the app and hte app has to say they want to support universal links from the domain
* - Balazs encouraged participants to review the charter of Wallet security WG in DIF that
* - Information for Wallet Security WG in DIF. Members are encouraged to comment on the charter.
* WG Charter<https://docs.google.com/document/d/18H2hVjHZEBjbnzod8tLogJIEzySdecbk9d-QBJaqHP0/edit> (Draft) - planned to be finalized in the next call on22nd of March.
* Mailing list<https://lists.identity.foundation/g/wallet-security>
* Register for drafting sessions<https://docs.google.com/forms/d/e/1FAIpQLSffkKj7nqndevSXvPNg_Q3a9MVqBhJvqatl88TnlX1L-WLUDA/viewform>(Calendar invite)
* Would need to find a way to prevent overlaps in scope and deliverables
* - Jeremie said he would update the issue with today's feedback.
Notes are also in the Bitbucket Wiki: openid / connect / wiki / 2021-03-16 — Bitbucket<https://bitbucket.org/openid/connect/wiki/2021-03-16>
Big thank you to Jeremie and DW for the demo!
差出人: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
送信日時: 2021年3月8日 14:51
宛先: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
件名: SIOP Special Call Notes 02-March-21
Notes are also here<https://bitbucket.org/openid/connect/wiki/2021-03-02> (Connect WG Bitbucket Wiki).
* IPR Agreement
* As the SIOP special calls are part the AB/Connect Working Group, anyone wishing to participate and contribute need to submit a contribution agreement: https://openid.net/intellectual-property/. The agreement signed between DIF and OIDF doesn't extend to their member's IPR. I again apologize for the confusion this question may have caused during the call.
* New WG in DIF "Wallet Security<https://lists.identity.foundation/g/wallet-security>" is starting (charter is being drafted) which discusses trust into the wallet is in-scope. Tom said we should monitor the progress in that group to have synergy and avoid overlapping scope with this group.
* Action items
* Write up a more concrete proposal on the discovery and present a prototype at the next call (Jeremie and DW)
* Define success criteria for the discovery - number of SIOP SW installed, etc. (Tom and Tim)
* New issues
* Value of iss = self-issued.me (#1208<https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required>)
* Questions: how to communicate the information about the SIOP SW provider and what is the rationale to use self-issued.me
* What is the rationale behind using self-issued.me as `iss` value?
* Oliver: it was used as a source of static OIDC configuration because SIOP does not have a service endpoint. Questions why self-issued.me is needed.
* DW: selfissued.me was not meant to be hit. Original limitations of SIOP when it was created was that only way to invoke a native app from a website was a custom url scheme. No good IPC channel between them, so redirect was chose.
* Justin: goal of using this discovery launch point for SIOP was that all device driven things are started the same way, without knowing what kind of device you are trying to get to. Another hard issue is that issuer identifier used throughout the protocol is based on the initial discovery. In SIOP it pretends to be HTTP when it actually isn't.
* Oliver: any other requirement that RP needs to know discovery endpoint upfront before the authorization request is sent?
* DW: You can't control what is kicked off using custom URL scheme. Having individual URL for PWA that is universal link allows to use specific wallet. That means users have to select which particular wallet they want to use. No control over what OS vendors would reserve for authentication flows, and this is not a solvable problem, rather tradeoffs.
* Tom: we could make a unified statement to the browsers what we need - solving the NASCAR problem
* Discovery proposal alternative to openid://
* Jeremie: Best effort, not a perfect solution, leans heavily on the platforms. Using the set of APIs that iOS, Android and Windows provide to present the user with the selection from that is already installed
* Three parts. First, some common website to publish app IDs as authorized apps to open links for a given path that all RPs will target with a new Discovery request.
* Second, when user clicks that link, the platform will query that website to discover if there is a local app that will handle the request to that path, it will open app.
* Third, using the platforms' built-in share sheets capability - OS will present a list of applications that can handle that data. Any supporting app registered to receive that path would ask the OS to present the list of application that can support handling that request.
* DW: analogy is a native app version of CHAPI. What we can do now is self-issued.me can have metadata file for platforms that says which issuer people can redirect to rather than openid://, native app on the list will get triggered. Applications from third party app stores would also be able to opt in to receive those requests. Share sheets also work with app-to-app.
* Following discussion
* Tim: we need to define the success criteria. One or several wallets.
* DW: agree. Is the user responsible for maintaining several wallets that may conflict? Need to take into the reality of dependency on the platforms.
* Oliver: Can return change the requirement `iss`=self-issued.me if this new discovery mechanism is adapted? To include DIDs in `iss` for example.
* Justin: Restrictions on the issuer identifier matching come from the discovery specification in OIDC. if a new discovery mechanisms is used, you're not bound to those same rules. It is fundamental to OIDC and very deliberate that there are two different fields in OIDC - who is the user and who says so.
* The two are tightly bound only in so much as a user account is tightly bound to the IdP that asserts that user account. You do not want to constrain self-issued identifiers by requiring somebody be identified by their device because that is potentially very bad privacy risk, allowing colluding RPs to share information about an individual user.
* DW: issuer and user identities today would have a parallel to user and wallet iidentity attestations in the secure wallet space.
* Tom: wallet identifier and wallet instance identifier should be distinguished.
* Supporting LD-proof signed claims
* Question addressed: how to send back VP signed by LD-proofs
* Oliver: proposal of introducing a new artifact vp_token that would represent VCs signed using JWTs/LD-proofs. It would be wise to support LD-proofs to embrace SSI community and allow new ZKP schemes (BBS+) and other privacy preserving technology that DHS SVIP program actively supports. Vp_token is a cleaner approach that is better from extensibility (additional claims?). Question to the implementers if this is viable. https://hackmd.io/PZE3__bjT-e3NnjTGK7PHQ?view
* Kristina: introducing a new scope is a protocol change, which has significant ramifications. There would be lots of questions to answer, like what triggers its addition (possibly use of a "claims" request?), what if there are multiple VPs, etc.
* Tony: I would oppose is vp_token is exactly the same as VP, because it may cause a problem processing. There is an issue of no approved algorithms or canonicalization methods for LD-proofs. ZKP work has been done with JWTs too.
* Tom: success of this spec should not be dependent on the success of DIDs and VPs. You can canonicalize the whole VC/VP by putting it into JOSE structure, expand the header section.
* Discussion on how much work RPs would have to do to accept LD-proofs - add support for the existing relevant libraries or getting this inside HSM to use for fundamental features.
* Call Schedule
* The next SIOP special topic call is in two weeks at the same time
差出人: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
送信日時: 2021年2月4日 14:54
宛先: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
件名: SIOP Special Call Notes 02-Feb-21
SIOP Special Call Notes 02-Feb-21
Regrets: Mike Jones
* Agenda Bashing
* Kristina: Today's agenda is to introduce "Portable Identifiers work" and discuss scope and direction: driving use-cases, adoption challenges, workstream name is a misnomer?, and relation to a MODERNA account porting spec
* Overview of the Portable Identifiers draft https://mattrglobal.github.io/oidc-portable-identities/ (WIP):
* Tobias: The problem addressed is how users can outlive the Provider and be able to transfer identity from one provider to another and what mechanisms are available to make this possible. Related work is an account porting spec in OIDF MODERNA WG that defines mechanisms to hand-over from one provider to another.
* Mechanism we are exploring is using cryptography to establish proof of control over the subject identifier to allow transferring ownership and consent of the user. DIDs establish a way to achieve this.
* SIOP, Chapter 7 in OIDC, allows for portability for co-located model, this work tries to expand that to other deployment models
* Use-cases motivating the work
* Torsten: SSI is about portability, but no one emphasizes it. Portable identifiers would provide a way for server cloud hosted wallets to assert DIDs, which is impossible with the scope of SIOP V2 draft which revises OIDC chapter 7 and is optimized for a deployment model where OP and RP are co-located.
* Torsten: Example of real life use-case would be British Columbia's prototype where a server-hosted OP uses DIDs and VCs. Would als o like to enable banks in Yes.com ecosystem to assert
* Question from Kim regarding details of Section 6 "Subject Identifiers"
* Tobias: in OIDC, identifiers are domain bound to the IdP's namespace, but there could be other types of identifiers: jwk thumbprint is one kind of identifier used in original SIOP section of OIDC and DIDs are another kind.
* Kristina: rough consensus in the WG since the beginning of SIOP revision has been to introduce a layer of indirection to `sub` to allow it to be a URI. With this, DIDs can be used as subject identifiers.
* Clarification from Tony - "wallets" are not limited to mobile wallets, any server hosted OPs would be able to assert DIDs.
* Tobias: "wallet" is an overarching term, used in particular deployment models, but the function that it serves is OPs
* Why another attempt at portable identifiers will have a different outcome (than i-names), whether for adoption by people, adoption by RPs, or adoption by OPs?
* Tobias: Agrees with Mike's sentiment that normal people don’t care about portable login identifiers. This is more about identity bound to the provider - trust relationship - does not want to offer
* John: with former i-names, problem was with a business model. Given that larger providers give identifiers for free, paid IdP did not fly. No one is against having portability, but no body was willing to pay extra for it.
* Torsten: No one is willing to pay for identity - the discussion on business model is related to the entire SSI-based model and should be separate from a technical discussion here.
* John: all comes down to the key management and asserting identifiers, other things come along to be used. Currently, IdPs use keys bound to their DNS which means using single key for all identifiers. There is a good reason to abstract that into being able to use individual keys for individual accounts, separate from a business model discussion.
* Kim: we are focusing on a wrong use case. In educational occupational credentials, users care about things remaining usable over life time, and they don't care if it's phrased portability. We just need to expand out to the use cases that benefit from portability.
* Is "Portable Identifiers" is a misnomer?
* John: we are not talking about porting identifier themselves, rather that the cryptographic keys used to prove control over identifiers are portable and can potentially be used to migrate from one identifier to another.
* John: the naming can be "Portability of cryptographyc proofs to assert control over identifiers" spec
* Kim: this is not about portable identifiers but portable credentials associated with an identifier
* Tony: How do you define portable credentials?
* John: identifier is part of a credential, every credential is essentially portable; need to define the language
* General consensus is yes. Alternative naming suggestions in a chat: Portability between Identifiers rather than Portable Identifiers; Inter-Identifier Portability (IIP)
* What changes would be required from OpenID Connect RPs to support 'portable identifiers'?
* As explored in the Portable Identifiers draft, RPs would have to expand client metadata elements indicating support for supported subject identifier types and did methods. ID token would be fundamentally signed by the provider who is performing the authentication, but there would be a separate claim in the ID token that proves user's control over the subject identifier. Worst scenario - RP would assume identifier is tied to the provider (instead of a user)
* What changes would be required from OpenID Connect OPs to support 'portable identifiers'?
* OP would need to support cryptographically verifiable subject identifiers - including DIDs. And advertising support for those features through OIDC discovery mechanisms
* No comments regarding the usage of VCs/VPs in OIDC
* Can this be a profile to MODERNA Account Porting spec?
* General consensus is no, this should be a separate work due to a differences in concept and approach.
* John: In MODERNA complete cryptographic proof is not used though it was considered because you have an Old OP to provide look up services. We should not be constrained by the choices MODERNA made.
* Bjorn: MODERNA porting is based on migration mechanism from OpenID 2.0 to OpenID Connect. account porting spec is written in a very flexible way
* Torsten: co-author of account porting spec - the spec assumes that old OP is still operational even after account porting has happened. Another big difference with Portable identifiers spec is the fact that in account porting spec, identifier is always scoped in the name space of IdP - not the case with DIDs.
Minutes can also be found in Connect WG Bitbucket Wiki: https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20Call%20Notes%2002-Feb-21
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab