Closed acoburn closed 3 years ago
Current Solid-OIDC draft, besides WebID used as sub
, also adds DPoP to sender constrain tokens as well as specific JWT format for access token etc. Do you see case where OP would implement those Solid-OIDC aspect but wouldn't be able to use WebID as sub
?
In case we find this a real world requirement. I would propose to only rely and custom webid
claim and don't even make anything dependent on sub
.
Also to be clear, Deriving WebID URI from ID Token, only refers to ID Token. If we look at Bearer token example it had neither sub
or webid
claims, only id_token
embedding the ID Token.
I don't see how the use of the sub claim buys anything and I think it only complicates things. I think we should require a webid claim which make it clear that the AT is a Solid AT. The sub claim could be set to the webid or something else, the spec doesn't need to address that at all if the webid is the one and only place where a webid is claimed.
I think we should require a webid claim which make it clear that the AT is a Solid AT.
AT already has claim aud
with constant value solid
The sub claim could be set to the webid or something else, the spec doesn't need to address that at all if the webid is the one and only place where a webid is claimed.
:+1: if we decide to go with custom webid
claim than we should not rely on sub
any more.
During the call with @EndlessTrax and @amigus we decided to go with webid
claim.
According to JSON Web Token (JWT): 4.2. Public Claim Names I understand that we should either register webid
claim with IANA or use collision resistant clam name, eg. IRI in solidproject.org
namespace.
I added this when in the last commit (with the Bikeshed conversion). https://github.com/solid/authentication-panel/commit/b2a948dc8be8f89d5993120e485202a65b3efa77
Resolved in latest version by @EndlessTrax in https://github.com/solid/authentication-panel/commit/b2a948dc8be8f89d5993120e485202a65b3efa77
The existing WebID-OIDC protocol includes a provision for a
webid
claim in an access token such that, if that claim exists, a resource server should use that value as the agent's WebID.The background on this is that some Identity Providers may be unable or unwilling to use full URLs for
sub
claims but would like to participate in the solid ecosystem. This would allow those IdPs to continue to support non-Solid applications with a more traditionalsub
claim while also supporting Solid apps.From the perspective of a resource server, the algorithm would be as follows:
webid
claim, use that.sub
claim as a WebIDThe same logic would apply to an ID token: use a
webid
claim if the IdP is unable or unwilling to set thesub
claim to be an agent's WebID.