LWS Authentication #43
Conversation
| </p> | ||
|
|
||
| <p> | ||
| The claims <code>sub</code>, <code>iss</code>, and <code>client_id</code> MUST all use the same URI value. |
There was a problem hiding this comment.
It's not clear to me why this requirement needs to be so strict? What does this constraint accomplish?
Minimal sufficiency would be ideal here. It's possible this constraint is necessary, but it would be helpful to have some elaboration on how why removing or relaxing this requirement would be insufficient for interop and protocol goals.
(noting also that this requirement is in lws10-authn-ssi-did-key as well)
There was a problem hiding this comment.
The rationale is this: on the verifier side, we want consistency by requiring validation via RFC 9068 (JWT profile for OAuth), and that spec requires the fields: sub, iss, and client_id.
Given that this is a self-issued token, sub and iss need to be the same; otherwise it wouldn't be self-issued. And given that the client_id claim is validated by the issuing party, there are really only these options:
- Trust whatever the issuer puts in that claim. This allows unfettered spoofing, so it's really a non-starter.
- Have the verifier ignore the value. This is a viable option but seems a bit weird to ignore this claim. Presumably the effective
client_idwould use thesubclaim anyway. - Ensure that the claim is the same as
sub, since there is no other way to verify the accuracy of the claim
elf-pavlik
left a comment
elf-pavlik
left a comment
There was a problem hiding this comment.
OpenID part looks pretty close to Soild-OIDC, I asked about proof-of-possesion (sender constrainted token) inline.
Recently I made PR to CSS that support client credential flow with ClientID URL for single tenant clients:
I also created rough draft PR that uses grant-type:jwt-bearer and offers smilar use of ClientID URLs but also supports multi tenant clients
So far no one else expressed interest in exploring grant-type:jwt-bearer, I'm mentioning it in case someone in the WG finds this exploration useful. Integration test in the PR might serve as an example.
lws10-authn-openid/index.html
Outdated
| Any audience restriction in the ID Token MUST use the <code>aud</code> (audience) claim. | ||
| The <code>aud</code> claim SHOULD include the client identifier and any additional target | ||
| audience such as an authorization server. |
There was a problem hiding this comment.
If audience is optional and no proof of possesion, like DPoP in Solid-OIDC is used (sender constrained token), what stops AS that receives the token from using it elsewhere in malicious way?
There was a problem hiding this comment.
The rationale for SHOULD is that in certain highly trusted environments, one can rely on that trust to ensure that the AS doesn't replay the credential.
Please also note this statement in the Authorization Security Considerations:
End-user credentials with unrestricted audiences MUST NOT be provided to untrusted authorization servers.
An implementation or spec that builds on LWS in the future might require a mechanism such as DPoP; the intention here is not to prohibit the use of DPoP. It is also worth mentioning that DPoP was designed for access tokens; applying it to ID tokens was always a bit awkward.
There was a problem hiding this comment.
It is also worth mentioning that DPoP was designed for access tokens; applying it to ID tokens was always a bit awkward.
👍 That's one of the reasons I try to talk about sender constrainted tokens and proof-of-possesion in general. If there's nothing acceptable available at this moment I think it's fair to rely on mentioned Security Consideration and leaeve it to specs building on top of LWS, for example Solid, to add that piece and make it work in an open ecosystem.
There was a problem hiding this comment.
End-user credentials with unrestricted audiences MUST NOT be provided to untrusted authorization servers.
I may be splitting hairs about the semantics of untrusted here, but maybe there's still a useful nuance in it.
Even if AS is considered trusted as not acting in a malicious way, any system can be potentially compromised. Using neither the aud restriction nor sender-constrained tokens doesn't seem like something that should be supported.
I don't expect this PR to address it, just wanted to put it on record.
EDIT: Maybe it is something that could be brought up in the Threat Modeling CG ?
| The issuer of an end-user credential is responsible for validating the client identifier. | ||
| The issuer may use mechanisms such as OAuth Client Metadata Document, OAuth 2.0 Client Id Prefix, or OpenID Federation. |
There was a problem hiding this comment.
Is there a plan to further specify this part? Does the current text mean that issuers have to implement all three mentioned mechanisms? I think there may need to be a MUST somewhere, otherwise client identifiers can't be relied on, at least in the open ecosystem. I don't suggest it being fully addressed in this PR, if desired I could create a dedicated issue to track it.
There was a problem hiding this comment.
There is not currently a plan to further specify this part. This section only states that an issuer is responsible for verifying the client identifier. This list here is simply a non-exhaustive collection of examples. An issuer is under no obligation to implement any of these, certainly not all three. I do not believe there needs to be a MUST here: the details of the validation mechanism is out of scope of the LWS protocol.
| An OpenID provider should support a mechanism to restrict the audience of an end-user credential to a limited set of entities, including an authorization server. | ||
| One mechanism for achieving this is to use Resource Indicators for OAuth 2.0 [[RFC8707]]. | ||
| A client in possession of an end-user credential with no audience restrictions should exchange this token for an equivalent audience-restricted token by using, for example, OAuth 2.0 Token Exchange [[RFC8693]]. | ||
| </p> |
There was a problem hiding this comment.
I'm not sure if I understand the intended flow here, I'm happy to work on a sequence diagram that could be used as non-normative reference at least for the conversation. Is the idea here that OP also implements Token Exchange and cilent can exchange token without audience restriction obtained via authorization code grant (for example with FedCM to improve UX) and later exchanges that token for audience restricted tokens without user interation needed? In that case wouldn't make sense that the OP is both iss and aud of the initial token obtained via authorization code flow? If I understand the direction correctly, this could possibly be an alternative to sender constrained tokens, with the trade-off that it requires more http requests to do all the token exchange with the OP.
There was a problem hiding this comment.
The intention is not that the OP also implements token exchange.
In the case that an OP does not issue audience constrained ID tokens, the idea is that there could be a token exchange mechanism in the user's trust domain (not at the same server). A similar mechanism is described at https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-01.html
There was a problem hiding this comment.
https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-01.html#name-overview
It seems like IdP AS issues the Id Token and later exchanges it for ID-JAG, I guess the main point is that it is the same security domain as you said.
I like simple naming of the distinct
- IdP Authorization Server
- Resource Authorization Server
the second one I understand to be the one in #45
This draft seems very close to what I was asking for on GNAP mailing list back in 2021
https://mailarchive.ietf.org/arch/msg/txauth/nhV4f59Xf5EaZ8c-YjkWWN6oCr0/
I wasn't aware of this work, thanks for the pointer 🙏
|
This was discussed during the #lws meeting on 01 December 2025. View the transcriptLWS Authentication ( PR #43 )acoburn: this is a collaborative effort with jeswr pchampin: elf-pavlik asks on IRC how this pluralism will be handled by the test suite acoburn: fair question acoburn: another point: Solid currently makes heavy use of WebID. https://www.w3.org/TR/cid/ ryey: I'm not familiar with CID; I assume that it is similar to OIDC @@. Is it a JSON document? <laurens> https://www.w3.org/TR/cid-1.0/ acoburn: it is a JSON-LD document, with media-type application/cid ryey: good to know. Are there any compulsory field that we would be force to use? acoburn: nothing beyond the id field, which we need anyway. ryey: I assume we can use our own vocabulary, as it is JSON-LD. acoburn: there is a notion of "service endpoint", for which we would need to define a type. <gibsonf1> +1 on CID pchampin: (more context on the genealogy of CID documents, and the minimization of information to avoid linkability of different identities) <gb> Pull Request 43 LWS Authentication (by acoburn) <gibsonf1> agent credential? acoburn: about terminology, we used "end-user credential" <gibsonf1> +1 agent credential acoburn: another goal that we had (in this PR and the AuthZ one) was to minimize the amount of things we invent <pchampin> +1 to minimize what we invent |
|
This was discussed during the #lws meeting on 08 December 2025. View the transcriptAuthentication questions from last week<acoburn> w3c/lws-protocol#43 <gb> Pull Request 43 LWS Authentication (by acoburn) acoburn: I wanted to raise this agendum as we talked last week mostly on authn dmitriz: what is the outcome of last week's call? acoburn: this PR describes an abstract framework for having an authentication suite elf-pavlik: I noticed on FED-ID slack, they're discussing that jeswr: Dmitri: is this specification in any way aligned with Social Web WG? dmitriz: good question <Zakim> ericP, you wanted to say that i'd probably require a toy authN for the test suite dmitriz: we could present it, some implementations might find it useful elf-pavlik: the main difference with activitypub, is that the client connects to more servers than only the user's server ericP: regarding testing, we can have a toy authn/authz scheme |
| <h2>Token Type Identifier</h2> | ||
|
|
||
| <p> | ||
| A self-issued JSON Web Token used as an end-user credential MUST use the <code>urn:ietf:params:oauth:token-type:jwt</code> URI when interacting with an authorization server. |
There was a problem hiding this comment.
Have you considered using urn:ietf:params:oauth:client-assertion-type:jwt-bearer
As in https://www.rfc-editor.org/rfc/rfc7523#section-2.2
There was a problem hiding this comment.
Authenticaiton --> Authentication
There was a problem hiding this comment.
Perhaps some guidance references to supplement "Tokens should have a reasonably short lifetime, such as 3600 seconds (1 hour)." like https://datatracker.ietf.org/doc/html/rfc6749#section-4.2.2 and https://datatracker.ietf.org/doc/html/rfc9700#section-4.14.1
ebremer
left a comment
ebremer
left a comment
There was a problem hiding this comment.
I don't see anything that should block the merge of this either.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
acoburn
force-pushed
the
lws-authentication
branch
from
2547f63 to
7120d43
Compare
This is a class 4 change to the protocol. It will need discussion and a WG vote before merging.
This PR follows from discussion on 2025-10-09 to define an authentication mechanism for LWS.
This text is split into, first, a set of core requirements, which are part of the authentication section of the main protocol specification. And second, a set of technology-specific authentication suites. The core requirements will be seen in the first commit.
The OpenID Connect suite builds on, while also simplifying considerably, Solid-OIDC.
The SSI-CID suite builds on Controlled Identifier authentication in the context of Solid, while also using the WebID-TLS mechanism as inspiration, using signing key pairs rather than certificates.
The SAML 2.0 suite shows that this mechanism can work with a technology stack that is significantly different than OAuth 2.0 and JSON Web Tokens.
Preview | Diff