Deriving WebID URI from ID Token

[namedgraph]

Of the 3 methods listed in Deriving WebID URI from ID Token, only the UserInfo-based one is realistic, the other ones are wishful thinking.

But if this WebID URI will not be used for the TLS-based authentication protocol, and most likely only relevant for ACL, why even bother?
Why not construct a URI from iss and sub fields of the ID-token? For example https://server.example.com#24400320.

Since iss is "a locally unique and never reassigned identifier within the Issuer for the End-User", I don't think this can lead to any collisions.

[csarven]

I don't understand why "wishful thinking". The RP at some point needs to have some awareness of WebID, so why would one method be realistic and the others not?

If method 1 and 2 are wishful thinking, I don't understand "Why not construct..."

[namedgraph]

Because in the general case you cannot rely on ID-token containing webid claim or iss being a URI -- that is not specified in OpenID Connect Core.

[csarven]

WebID-OIDC is an extension of core. It isn't advertised as something else. So, the webid key is a clear signal from the server. Besides, string concat'ing key values to derive the WebID URI generally feels more like a hack to me, but that's the environment we are working with.

[namedgraph]

What is the benefit of that extension though? Does it justify excluding all software that supports OpenID Connect Core but not WebID-OIDC? Which is like, the absolute majority.

Where is the WebID URI from WebID-OIDC being used? Isn't only for ACL?

Can't the WebID be formulated as Core-compliant convention instead? I think I've shown that it can.

[Sparika]

To summarize

• Method 1: the webid claim replaces the sub claim.
• Method 2: the sub claim contains the WebID.
• Method 3: the WebID was not found, and a user info request is made with the website claim.

Regarding method 1, it seems impractical to have the sub claim still present, but deprecated in favor of another claim. I agree though that the set of claim is extensible. But I think that the sentence [webid] value should be used as the WebID URI by the Relying Party, instead of the traditional sub (subject identifier) claim is at least unclear and at worst non-compliant with OIDC.

Regarding method 2, I do not see why the OIDC server would not be able to add claims. It is the entity forging the JWT in the first place. Besides, how to know that the sub is intended to be a WebID?

Regarding method 3, it is similar in requirements to method 1. i.e. identity claims can either be retrieved within the ID token or from a user-info request. However, why use the website claim? Similarly to the issue in method 2, the website claim contains a URI that may not be the WebID. For instance a blog, which would be different that my WebID.

It seems to me that the WebID-OIDC specification should be clarified by specifying a webid scope. Requesting this scope would see the webid claim added to the ID token or the user-info response.

Implementors of the WebID-OIDC specification MUST support the webid scope.
This allows to explicitely request the webid and I believe it would result in a request_not_supported authentication error response if the scope is not supported. This would clearly indicates that the provider does not support WebID-OIDC.

Like I was saying in solid/solid-spec#106, it is possible to forge an identifier with the pair iss#sub but the sub claim is not a primary identifier for the user within the provider. i.e. different audiences may get different sub claim for the same user. This is at least how it is implemented by Orange.

[namedgraph]

@Sparika the point of my proposal was that WebID-OIDC does not need new scopes or anything outside the OIDC spec that would drastically hamper adoption, just the iss#sub convention.

Re. the sub uniqueness - the OIDC spec says the following:

REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.

How do you understand "locally unique and never reassigned identifier"? To me it sounds like a primary identifier.
It's also possible the Orange implementation is wrong.

[Sparika]

It was not obvious to me before one of the architect at Orange explained it to me. Consider the following example: id is your primary identifier. You authenticate to two different audience aud1 and aud2. Then, secure_hash(id+aud1) and secure_hash(id+aud2) are two locally unique, never reassigned identifiers for user id. Privacy consideration: the sub claim cannot be used as a cross-audience identifier.

See also Nat Sakimura's implementation of OIDC, and especially the function wrap_userid which is used to generate the sub claim. Nat Sakimura is the first cited editor of the OIDC spec.
https://bitbucket.org/PEOFIAMP/phpoidc/src/c7a759a75afaf86806fbea3c36a4aa4a6b4ab073/phpOp/index.php?at=default&fileviewer=file-view-default#index.php-1826