2018-10-16#OpenID Connect Provider could not use an Architecture built on Decentralized Identifiers?
As said in Sovrin Use Cases: Authentication: "there’s no such thing as “an identity” in Sovrin. Instead, Sovrin creates a unique identifier for each relationship that Alice has. Alice controls her identifiers and can correlate them, but no one else can without her permission. So, enrollment consists of Alice generating a key pair for a new relationship and the Bob’s Bait Shop associating that with an account."
Well, "there’s no such thing as an identity in Sovrin"; What?
"There are three orthogonal dimensions to Alice's digital identity: (1) her relationships, (2) her attributes, and (3) her agents."
So there is a Digital Identity and that is just as with all Authentication systems that we could possibly use on the Internet. Am I missing something?
How does Alice create this Key pair? they go on to explain; "let’s explore just one that involves a Sovrin app called a connector. The connector runs on the person’s device and helps them manage their keys. In some ways, it would feel like a password management app such as 1Password. The connector is secured by the operating-system security services on Alice's device as well as app-specific mechanisms."
So this Sovrin Connector is an app written by a Third-party that then has access to my credentials (i.e. Key pair) just as any other OpenID Connect Provider would. And Just as mostOpenID Connect Providers, they probably use this in some Cloud computing method. ...
"Bob’s Bait Shop doesn’t store or manage passwords. They didn’t have to validate email addresses or phone numbers (provided they received claims they trust). And yet, they have a secure method of authenticating Alice and account information they can trust."
Well, so far, I see no reason that this is different form OpenID Connect. There is no requirement that an OpenID Connect Provider use passwords and many, now, allow WebAuthN to be used.
Likewise, there is no requirement that a OpenID Connect Provider to not allow the End-User to manage all of their Attributes.
And the Relying Party never sees the password within OpenID Connect any how.