Directed Identifiers - Remarks

[achimschloss]

@kenrb - thanks for consolidating this topic and picking up the challenges I raised in https://github.com/WICG/WebID/issues/24

A few remarks on OpenID:

Subject IDs in OpenID:

OpenID contains an explicit definition of directed identifier in terms of the sub value - SubjectIDTypes.

sub values are either pairwise (i.e. directed) or public (i.e. global). In case an IDP declares its sub values to be pairwise it is also mandatory within the spec that they are not reversible by anyone but the IDP.

IDPs publicly declare their config for sub values within the OpenID discovery - for example"subject_types_supported":["pairwise"]

Please note that

• IDPs must be aware of the sub value and its relation to the user account because they use it to persist user choices w.r.t. to the respective RP based on that (is the user already registered with an RP, which claims were approved by the user, ...) - I assume this is what is meant by verifiably directed identifiers not being compatible with the protocols
• IDPs typically have a notion of the legally responsible entity (which they manage via out-of-band RP registrations) that is related but not identical to a specific URL (Brand) - see also the discussion around first party sets, about the relation between URLs and legal entities. IDPs have mechanisms defined to manage this (same for Android / iOS for example)

[kenrb]

Thanks for the feedback. I've incorporated some mentions of pairwise subject identifiers into the document (along with some unrelated text cleanup), since that is useful context. https://github.com/WICG/WebID/commit/34b511334ed380764f014e4b993bcd5ca39c5922

• IDPs must be aware of the sub value and its relation to the user account because they use it to persist user choices w.r.t. to the respective RP based on that (is the user already registered with an RP, which claims were approved by the user, ...) - I assume this is what is meant by verifiably directed identifiers not being compatible with the protocols

This sounds consistent with the current description of directed identifiers. There has to be some kind of mapping from the original identifier to the directed one, but not vice versa. The issue with verifiably directed identifiers is that OpenID doesn't require that the token be passed to the RP through the client, so inspection and directedness verification by a browser would be impossible.

• IDPs typically have a notion of the legally responsible entity (which they manage via out-of-band RP registrations) that is related but not identical to a specific URL (Brand) - see also the discussion around first party sets, about the relation between URLs and legal entities. IDPs have mechanisms defined to manage this (same for Android / iOS for example)

There is a subtle distinction that we have been trying to make around this, because the browser sees the world in terms of origins (or sometimes the looser concept of sites, and yes first party sets would be a further expansion), but as you say IDPs have a separate notion of client, corresponding to OAuth client ID (IIUC). My understanding is that it is not true that URLs/origins/hostnames have a 1-to-1 relationship with client IDs in all cases. Directed identifier hashing would have to be a function of client ID, even though any browser privacy warnings or consent prompts we want to add would have to be based on the RP's hostname. This does create some use case permutations that we have to ensure are covered.

[samuelgoto]

This has been open for 4 years and I believe the layering choices we made makes this issue now obsolete: the browser is unopinionated about the protocol layer, which includes the considerations around directing identifiers or not.

Will close this, feel free to reopen this if there is anything actionable on the browser layer (or more features: e.g. letting the user know whether the identifier is directed or not).