[Openid-specs-ab] Issue #1354: Relationship Management (openid/connect)

[tomcjones]

New issue 1354: Relationship Management
https://bitbucket.org/openid/connect/issues/1354/relationship-management

Tom Jones:

The major point of the user name is the establish a name that is used to lookup the user object that is maintained by the relying party. While the user typically gets to establish this name, it must be a name that is unique in the RP. If that RP has a large number of users, the chance that a simple name will not be available. The result is that the RealWorld user will have ~100 user names after a few years. That is not manageable by the user’s memory. Historically the user also has a password as a access credential. Eliminating the password is the current goal. the user name does not appear to have an alternate solution at this time.  While the password manager was developed to recover passwords. it appears that even without passwords the user name will continue to be a value that is not possible for user’s to recall for more than a small number of web sites.  \(Here we are using the term web site to imply an origin name as defined by the browser.\)

Since the user name will be with us for the short term, the password manager will be as well. It is thus presumed that the password manager will continue to be required for any enduring relationship. The question now is what data must be stored in the RP to allow the reconnection of the RP to an OpenID provider. Hitherto that just been a url to a web endpoint. Often that could be inferred from the user name itself \(eg foo at bar.com\) But if the OP is hosted by the user such a url may not be possible. It is those cases where a new method must be defined for reconnection to be possible.

Here is one proposal. We define a “universal link” that is owned by the user and known to the browser. We require that the browsers and/or the compute platform help the user create that link and prevent requests to change that link from being requested by any accept the holder of the platform. We require that neither the browser nor the compute platform try to take ownership of this link. We acknowledge that no crypto method can be bound to this link for the totality of the duration of the link. We acknowledge the problem that if a link is established on one platform, some attacker may try to register that same link on some other platform and the resolution of that attack must be defined.

As a side note, it is possible for a did method to meet these requirements, but none are known to me at this time that require this permanence over any extended period. The methods that come close use IPFS AFAIK. My own thought is that a GUID registered on a did method are most likely to fit the bill. This will always that a period of minuets to be assured of uniqueness.