Need for a persistence user identifier - a PUID

[Tom Jones]

A request came up in FAPI that reflects a problem I found in implementing section 7 of oidc with a DID from the W3C CCG. Not sure if anyone has another field that could be used for a persistent user id (a uid or a puid), but the sub of section 7 (or of the UK OBIE) does not seem to apply. (The sub of the UK OBIE appears to be a consent ID, that is interesting all by itself; although consent in banking seems to have a different meaning than that used in oidc.)

On rereading the spec the Subject Identifier is Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.

I guess i assumed it had some persistence. Apparently not. So NAT, the sub (particularly the sub in section 7) is not a did and i need that to get section 7 to work with the W3C CCG some way or the other.

[Michael Jones]

There isn’t key roll-over for self-issued. A change of keys is a change of identity.

‌

With respect to DIDs, Microsoft’s prototype implementation of DID authentication using the self-issued flow uses a “did” claim in the ID Token to represent the DID associated with the self-issued identity.

[Michael Jones]

The “iss”, “sub” pair for an identity at an RP is the persistent identifier, which does survive key rotation. Changing the “sub” at key rotation time would break the relationships between the OP and the RP for the identity.

[gffletch]

For OpenID Providers, the “sub” value needs to be persistent across the lifetime of the user’s identity at the OP. It can be pairwise in regards to the relying party but must not change within the context of the relationship (OP<->RP) over the lifetime of the identity.

[Tom Jones]

Both Mike and george are wrong about the sub. There is no such assertion and it is flatly contradicted by section 7. (Altho i must admit i do not understand what george means by “life time of the identity” I don’t believe we define identity. By my definition of identity it is wrong.) Also it is not the way that UK OBIE seems to work, at least according to Annop. It Mikes assertion about the “identity” expiring with the key, then i can’t think of any use for section 7 at all. He contradicts himself in the following assertion about the sub pair surviving key rotation.

Nat - this is (in part) are response to your blog post about section 7 being compatible with the did. That also seems to be untrue unless we allow something like PUID. If these assertions by Mike and George are true i would suggest that section 7 be removed completely.

At the Dec meeting of the CCG in Redmond, John Bradley asserted that authentication should happen before any (substantive) attributes (claims) were exchanged. I agree with John, but i don’t see how to do that without some more structure than we have in oidc. I was thinking that the puid would be the binding to external claims. BTW, i consider that the did is only one of many proposals that we should expect for the structure of a puid and so would lobby for a field name that was more generic than did.

[Tom Jones]

I realized after thinking about this that we do not seem to have a common vocabulary for terms like identity and persistence. That lack makes any conversation difficult. Not sure how to make sense of the missing pieces without a common vocabulary.

[Tom Jones]

reference this to FAPI issue 223 https://bitbucket.org/openid/fapi/issues/223/need-of-a-customer-unique-immutable

and the tendency for new groups to add new identity elements, even when the element is a url or urn, as is the case with guids.

reference this issue 1096 for a sub type - and the references to ephemeral subs. I do not want to see each new source of identifier create yet another ID element so this issues should be accepted so that they don’t have to.

[Tom Jones]

this has been absorbed in the siop doc