[Openid-specs-ab] Replacement to "User-Centric Identity" complete + another terminology topic: alternative to a "credential"?

Wed Apr 20 02:00:22 UTC 2022

I would prefer User Driven but I’m ok with User Centric, need to stay away from decentralized as that is a bag of worms. While I don’t like SSI for the same reasons that decentralized is a broken concept so is SSI. 

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of David Chadwick via Openid-specs-ab
Sent: Tuesday, April 19, 2022 1:21 AM
To: openid-specs-ab at lists.openid.net
Cc: David Chadwick <d.w.chadwick at verifiablecredentials.info>
Subject: Re: [Openid-specs-ab] Replacement to "User-Centric Identity" complete + another terminology topic: alternative to a "credential"?

Kristina, thanks for re-writing the Introduction.

My personal opinion is that "User Controlled" is a better term than "User-Centric". The two letter acronym is still the same (IC), but if you replace user-centric with user controlled in your introduction, I think it reads better,

Kind regards

David

On 19/04/2022 09:05, Kristina Yasuda via Openid-specs-ab wrote:

Also as promised, I did write up an introduction that more clearly positions the thinking of the WG around why “User-Centric” and not another term. The language definitely needs tweaking, but would appreciate the feedback if people agree with the direction (especially, Nat, John, Mike, Vittorio, Tobias, DW, and the small group of editors 😊)

We all know how much the industry is used to the terms “SSI” and “Decentralized Identity” so if we are making a conscious decision to use another term even when meaning something quite similar (especially to the decision-making folks), it has to be crystal clear why, hence quite straightforward language below:

---

Introduction 

OpenID Connect, a protocol that has enabled deployment of federated Identity at scale, was built with User-Centricity in mind. The protocol flow is designed to provide Identity Providers a capability to directly talk to the End-User to obtain consent before releasing claims about that End-User to the Relying Party. The protocol also enables the End-Users to run their own Identity Providers instead of using third party provided ones.

Now, the User-Centricity is evolving to the next level, where the End-Users retain full control over the key decisions when receiving identity information from the Credentials Issuers, and when presenting those credentials to the Verifiers. The End-Users can now directly receive their identity information as credentials from the Issuers and present those credentials to the Verifiers without Verifiers obtaining those user claims from the Issuer. This is an obvious evolution from a federated Identity protocol flow where after receiving the End-User’s consent, the Identity Provider directly provides the Verifier with the identity information about the End-User.

When describing the concept of putting the End-User in control of their identity, the readers might be more familiar with the terminology Self-Sovereign Identity or Decentralized Identity. This whitepaper could have used those terms, too. However, after numerous long discussions, Connect WG in OpenID Foundation has decided to use a term User-Centric Identity to describe both a vision and an architecture of this new, emerging approach to the identity management. 

The Connect WG could not reach consensus to use the term Self-Sovereign Identity because Self-Sovereignty implies the End-User’s autonomy and freedom from the Issuers and the Verifiers, which is not the case in real-life use-cases. Even if the Verifier has obtained the claims directly from the End-User, it is up to the Verifier to decide whether to accept those credentials and provide the service to the End-User. Regardless of where the End-Use is planning to use a credential, it is up to the Issuer to decide whether to issue credential to the End-User in the first place. Even after the issuance, in most cases, the Issuer retains the right to revoke and invalidate the credential.

The Connect WG also could not reach consensus to use the term Decentralized Identity because decentralized implementation techniques have their role to play, but they are neither necessary nor sufficient to achieve user centric identity. For the End-Users to directly receive identity credentials from the Issuers and directly present them to the Verifiers, user identifiers other than Decentralized Identifier (DIDs) can be used, meaning that Distributed Ledger Technology or Blockchain is not required and data models other than W3C Verifiable Credentials can be used.

Therefore, the goal of this whitepaper is to first and foremost to inform the audience about the work on the OpenID for User-Centric Identity (OpenID4UCI) specification family and help position it in the broader landscape of Self-Sovereign Identity and Decentralized Identity. The work is being conducted in the OpenID Foundation, in liaison with the Decentralized Identity Foundation (DIF). .

The whitepaper targets decision-makers, architects and implementers interested in the concepts, use-cases and architecture where the End-User directly receives identity credentials from the Issuer and directly presents them to the Verifier, a concept that will be referred to as “User-Centric Identity” in this whitepaper.

---

Thank you!

Kristina

From: Openid-specs-ab  <mailto:openid-specs-ab-bounces at lists.openid.net> <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Kristina Yasuda via Openid-specs-ab
Sent: Monday, April 18, 2022 6:08 PM
To: Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net> 
Cc: Kristina Yasuda  <mailto:Kristina.Yasuda at microsoft.com> <Kristina.Yasuda at microsoft.com>
Subject: [Openid-specs-ab] Replacement to "User-Centric Identity" complete + another terminology topic: alternative to a "credential"?

Hi, thanks a lot for a productive conversation regarding the terminology in the “OpenID for User-Centric Identity (preliminary naming)” whitepaper <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1H556GIM_xD1yKl7rw1seq4bu83movFCkU8fQ7T8b1dI%2Fedit&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C8fb4bcc61b63463b182b08da21a106ef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637859273185651256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yX9Q7MJ%2B%2FB2PMnYUBNMrXfj5vrYAsrFeNyUCkH2JaaQ%3D&reserved=0>  – the details of the conversation will be in the notes that will be sent out.

As agreed, I replaced all the references to the “Decentralized Identity” to “User-Centric Identity” (Thanks Mike for making the suggestions). As agreed, if you come up with a better term than “User-Centric”, please bring it up. We are looking for “a generic property that transcend the topology we are working with at this point in time (I really like how Vittorio has put it!)” that describes “an approach to the identity management where the End-User retains full control over from which Credential Issuer to obtain what credential, and when to disclose which credential to which Verifier (again, paraphrasing Vittorio)”. (and now I am not a big fan of an acronym OpenID4UCI, so acronym suggestions welcome too..)

Another terminology topic I wanted to bring up is inspired by Pieter’s comment on the definition of “Credential”: “It was interesting to see terminology in the EU Digital Wallet architecture like "Electronic Attribute Attestation" (EAA) that may provide alternatives to the heavily overloaded "credential". Not sure it is the right time to adopt it, but may be a good way to disambiguate terms like credential (and align with frameworks emerging elsewhere).” 

I agree with Pieter both in that EAA might be an alternative, and in that maybe this is whitepaper V2 issue… Some food for thought.

Cheers,

Kristina

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net> 
https://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220419/5b103e57/attachment.html>