[Openid-specs-ab] SIOP Special Call Notes 02-Feb-21

Kristina Yasuda Kristina.Yasuda at microsoft.com
Thu Feb 4 05:54:02 UTC 2021


SIOP Special Call Notes 02-Feb-21

John Bradley
Albert Solana
Justin Richer
Mike Varley
Anthony Nadalin
Torsten Lodderstedt
Brian Campbell
Tom Jones
David Moeller
Nader Helmy
Oliver Terbu
David Bantz
Jeremie Miller
Adam Lemmon
Dion Bramley
Kim Duffy
Matt Randall
Bjorn Hjelm
Tobias Looker
Edmund Jay
Kristina Yasuda

Regrets: Mike Jones


  *   Introductions

  *   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...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210204/e03b0c10/attachment.html>


More information about the Openid-specs-ab mailing list