Proposal for keyed Access Tokens in a Distributed Network

[jricher]

Public Clients. Instead of dynamic registration as in the current prototype, we should be using static registration or its equivalent to introduce a client to the AS. With the current prototype setup, registration is required to set up a client_id and associate it with the application keys. The downside is that for ephemeral applications, and even native applications that can get deactivated/uninstalled/abandoned, this leaves a lot of dangling registrations at an AS that will never be seen again. The client ID in OAuth2 allows an instance of software to be identified across multiple authorization requests, but it’s rare that a single application instance would ever ask for a second token. I believe that we can use technologies like PKCE and DPoP to fill in the functionality currently provided by DynReg. Coupled with this, we can use a WebID for the client ID, or use it to fetch/validate a client ID, and tie that to a set of display and key information for a client. Client IDs are public information, and any attacker could claim any client ID, but we can use WebID mechanisms to lock down the behavior of a given client ID such that any attacker would need to also have control over the appropriate URLs for an app.

DPoP with ephemeral keys. Instead of the keys being registered in one-time-use client entries, DPoP allows a client to present an ephemeral key at token request time. These keys don’t have to be strongly associated to a client’s identity, but they tie a token request to subsequent token presentations. This prevents a token from being replayed by another party, such as a downstream RS. This key binding lasts as long as the token.

JWT Profile. In addition to the key presentation mechanism of DPoP, we need a way for the RS to figure out who the token’s for and what software is presenting it. We can define JWT claims for the user and client software, and define in the Solid profile that these are WebID’s and how these are to be dereferenced. This would allow the RS to validate the token’s presentation mechanism, which binds to the client, and the token’s own signature, which binds to the AS, and the WebID’s for the user and client, which validate those parties and allow authorization decisions. This JWT access token would replace the use of the ID Token in the current process (and therefore no longer depend on OIDC either), and would need to comply with the various BCP’s for JWTs that are floating around. 1 2 3

Structured Scopes. Proposed work by Torsten Lodderstedt. This allows us to define the kinds of information being requested and authorized by the protocol, and as Dmitry pointed out, the current thinking in the OAuth world aligns with the WAC concepts in Solid.

Alignment with existing infrastructure would take the form of an identity broker (for users on their way in) or an application gateway (for APIs on the way out) to bridge between the Solid ecosystem and traditional OAuth/OIDC/SAML systems.

And finally, much of this approach aligns with ongoing work in the XYZ Project, which is seeking to patch a lot of the problems in the OAuth protocol and its extensions.

[zenomt]

@jricher regarding Dynamic Registration: today, dynamic registration is used only between a client (such as a single-page browser app (SPA)) and the user's OpenID Provider. since the user is likely to be the same from use-to-use of the same SPA in the same browser on the same device, the SPA can (and many do) remember the client ID & secret (and other aspects of the openid-configuration) from run-to-run in that browser on that device. and as we discussed on the call this morning, my proposal doesn't require a dynamic registration with the Resource Server's Authorization Server either.

regarding DPoP: i believe the DPoP construction specifically is intended to solve a different problem. DPoP as of draft -02 is vulnerable to a downgrade attack, though for Solid it could be mandatory. i think the attack model DPoP is trying to address isn't an issue in Solid (or even in my proposal, as the RS and its AS are already in cahoots, and any auth token presented to an RS would only be good in the same protection spaces controlled by its AS anyway). any proof of possession of a private key that comprises a signature over information required to establish whatever identity/authorization/whatever claims would be sufficient and semantically equivalent (like today's POP tokens, DPoP, HTTP signatures, my proposed POP tokens, etc).

regarding OIDC id_tokens vs a new JWT-based construction: my gut feeling without seeing more specific information is that any new construction would be semantically equivalent to an ID token issued by the user's/webid's trusted identity provider/issuer (for example, an id_token issued by the user's OpenID Connect Provider), but would also require recreating all the rest of the OpenID Connect infrastructure to let the user log in in the first place. i look forward to additional information that might help me understand better what you're proposing.

[elf-pavlik]

I think for User associated Authorization Server we don't need Dynamic Registration and actually could use static registration step to let the User set app specific permissions. Having JWT access token to include those app specific authorizations (even just by reference) seems to address use cases where User doesn't want to define it for each Resource Server and does not to have them discoverable except for Resource Servers hosting resources app needs to access.
In cases where multiple Users associate with the same Authorization Server, and some of those users use the same app, would it make sense for each user to register the app oneself? Either way app specfic authorizations would need to apply to the user-app combination not just the app.

[jricher]

@zenomt: DynReg is needed in WebID-OIDC because the keying material used by the client is associated with the client's registration, and not with the access token itself. This doesn't make sense for ephemeral keys and in-browser clients. This is in fact where DPoP comes into play: the keys used by DPoP do not need to be pre-registered with the client, removing the need to have each instance of the client dynamically register itself with the target AS.

And again my point on ID Tokens: they are never meant to be sent outside of the client, they are a message TO the client. The name "ID Token" is a bad one as it seems to be put on par with, or parallel to, the access token, which is not the case. Access tokens are made to be sent to the RS, which is what we're doing here. What I'm proposing is a method of being able to recognize an access token with a key proof in a distributed fashion, and for that you need at least some means to communicate the token's origins and validity bounds, which is where the JWT comes in.

I don't understand what you mean about "recreating all of the connect infrastructure", because to have the user log in and get the access token, you just need OAuth. Remember, in OIDC, the user isn't logging in to the RS, they're logging in to the client. For the proposal above to work for accessing APIs, you don't need OIDC at all, just OAuth (and the extensions listed). If you want the user's identity information to also be available to the client in a standard fashion, you can also use OIDC on top of OAuth to do that, just as it's designed to do.

And regarding the downgrade attack and token formats: in my view, these would all be required as part of a Solid profile combining all of these technologies. We would not be inventing new endpoints or protocol flows, but we would be combining them in a consistent fashion that we would then standardize.

[zenomt]

@jricher i think we may be talking past each other. i have a strong feeling that i'm not understanding the access model you're describing and how that fits in with Solid.

... the keys used by DPoP do not need to be pre-registered with the client, removing the need to have each instance of the client dynamically register itself with the target AS.

i'm not sure what you mean by "target AS". in the current Solid POPToken scheme and in my proposal, dynamic registration is only done between the client app and the user's trusted OpenID Provider.

And again my point on ID Tokens: they are never meant to be sent outside of the client, they are a message TO the client.

i understand what you're saying. however, it's not against the rules for a client to show an id_token in its possession to anyone else, particularly if that's what the user wants. while the id_token is audience-bound to the client to which it was sent, having a cnfirmation key in the id_token allows the client to demonstrate to a third party that "the user's trusted OP gave an id_token to somebody, and that somebody is me! so i'm working on behalf of the user, according to the user and her trusted OP".

I don't understand what you mean about "recreating all of the connect infrastructure", because to have the user log in and get the access token, you just need OAuth.

without OIDC, i'm not sure how the user logs in with just OAuth. this and the other things you've described above suggest to me that you're talking about an identity and authorization model very different than WebID-OIDC and Web Access Control, and in particular you're envisioning authorization servers somewhere that issue access tokens that themselves grant access to resources, rather than just conveying the identity of the presenter (and her client app, according to her) where an access control system in the resource server makes a just-in-time access determination based on identity-centric access control rules (for example, WAC). if that's not what you're talking about, then i am very definitely misunderstanding you, for which i apologize (as i don't mean to mischaracterize your proposal).

either way, additional detail to illustrate what all the pieces are and how they fit together would be greatly appreciated.

[dmitrizagidulin]

Before weighing in, one thing I wanted to clarify:

Currently, the WebID-OIDC protocol does not use the Dynamic Registration to register a client app's keys.
An ephemeral key pair for the client app is generated for each session, and is sent over to the IdP during the Authorization Request step (and returned in the ID Token). (These are the keys that are used for the PoP token etc).

So, currently, we're only using DynReg for a (throwaway) client_id, that's about it.

[elf-pavlik]

In DPoP Proof JWTs: Syntax I see:

• "http_method": The HTTP method for the request to which the JWT is
  attached, as defined in [RFC7231] (REQUIRED).
• "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).

and later in DPoP Proof JWTs: Checking DPoP Proofs

7. the "http_uri" claims matches the respective value for the HTTP
   request in which the JWT was received, ignoring any query and
   fragment parts,

Does it mean that if application acting as client and using HTTP/2 wants to fetch contents of LDP Container - let's say containing 1000 LDP Resources - it has to create DPoP Proof JWT for each of those 1000 resources?

I think in current WebID-OIDC application acting as client needs to create just one PoP token per Resource Server. RS would only accept PoP tokens that application created for that RS (@dmitrizagidulin please correct me if I confuse something)

---

The client ID in OAuth2 allows an instance of software to be identified across multiple authorization requests, but it’s rare that a single application instance would ever ask for a second token. I believe that we can use technologies like PKCE and DPoP to fill in the functionality currently provided by DynReg. Coupled with this, we can use a WebID for the client ID, or use it to fetch/validate a client ID, and tie that to a set of display and key information for a client. Client IDs are public information, and any attacker could claim any client ID, but we can use WebID mechanisms to lock down the behavior of a given client ID such that any attacker would need to also have control over the appropriate URLs for an app.

@jricher Could you please expand on this point. In common example also discussed in solid/authorization-panel#30 (comment) We would have Progressive Web App acting as Public Client served from https://demo.saywhat.example Given that Alice registers this PWA with Authorization Server associated with her and Bob registers the same PWA with Authorization Server associated with him. And that WebID acts as globally unique identifier (IRI). Would both Authorization Servers (Alice's and Bob's) use the same WebID to identify that PWA served from https://demo.saywhat.example or each Authorization Server would create during static registration WebID specific to that AS?

Also would any Authorization Server verify identity of the Application acting as client only based on its redirect_uri ? I understand since we discuss Public Clients we don't use client_secret.

Instead of dynamic registration as in the current prototype, we should be using static registration or its equivalent to introduce a client to the AS.

In case where Public Client (eg. PWA) would use the same WebID with any number of user associated Authorization Servers, what would that static registration result creating?

[jricher]

To clarify, the client does not create a token. The client :presents: a token with proof of a key associated with that token. So if the client is presenting that token, with its associated proof, to 1000 different RS's, and those RS's are distinct enough from each other that they'd know they were distinct, then yes it would create 1000 different proofs. It does this as part of the process of making the HTTP request. This proof is going to need to be very short-lived in the time scale anyway, and prevent replay attacks with some randomness in the request, so you actually :want: the client to create a new proof each time and not re-use it. If the client reusing a token at multiple RS's over time without additional effort were the goal, we could get by with bearer tokens. But keep in mind if all those resources are in one logical "group", then the client could potentially get away with replaying the same token proof to them, if it did so quickly enough. But then you'd have to weigh the benefits of letting a client do that, sometimes, with the downside of giving an attacker a place in which to easily hide their replay attack.

As for the client_id, it depends on the nature of the app. A web server with shared users wouldn't need to be a public app, for one. An ephemeral SPA style client would be a new instance of the same public client software on every load, even from the same server, and so would therefore need to be either a public client or a dynamically registered client. Same with multiple copies of an installed native application. The static registration would create the client_id, which could in turn be (or be referenced to) a WebID. When talking to multiple AS's, you'd need a way to either register with each of them, or create an identifier that could be referenced by each AS in a distributed fashion. This is one of the downsides of OAuth's model, which assumes a client talks to one AS in the usual mode of operation.

[elf-pavlik]

Thank you @jricher for quick answer!

In my previous comment I talked about fetching 1000 resources from the same LDP Container so we talk about single Resource Server. If DPoP Proof has REQUIRED http_uri how the same proof could be used to fetch those 1000 resources - let's say all withing 10 seconds? Actually it seems that REQUIRED jti by itself prevents using the same DPoP Proof more than once so even for that 1000 resources in the same LDP Container application would need to create 1000 DPoP Proofs

in DPoP Proof JWTs: Checking DPoP Proofs

9. that, within a reasonable consideration of accuracy and resource
   utilization, a JWT with the same "jti" value has not been
   received previously (see Section 9.1).

Do you know of any benchmarks of creating DPoP Proofs on average low end mobile device?

---

JWT Profile. In addition to the key presentation mechanism of DPoP, we need a way for the RS to figure out who the token’s for and what software is presenting it. We can define JWT claims for the user and client software, and define in the Solid profile that these are WebID’s and how these are to be dereferenced. This would allow the RS to validate the token’s presentation mechanism, which binds to the client, and the token’s own signature, which binds to the AS, and the WebID’s for the user and client, which validate those parties and allow authorization decisions. This JWT access token would replace the use of the ID Token in the current process (and therefore no longer depend on OIDC either), and would need to comply with the various BCP’s for JWTs that are floating around. 1 2 3

I would also like to clarify what goes in DPoP-bound Access Token and what goes into DPoP Proof.

• User's WebID - DPoP-bound Access Token
• Application's WebID ( =? client_id)- DPoP-bound Access Token
• access token audience (the RS) - if we follow WebID-OIDC PoP Tokens it would go into DPoP Proof. otherwise application would need to request from Authorization Server a new DPoP-bound Access Toke for each Resource Server it needs to access.

---

An ephemeral SPA style client would be a new instance of the same public client software on every load, even from the same server, and so would therefore need to be either a public client or a dynamically registered client. Same with multiple copies of an installed native application. The static registration would create the client_id, which could in turn be (or be referenced to) a WebID. When talking to multiple AS's, you'd need a way to either register with each of them, or create an identifier that could be referenced by each AS in a distributed fashion. This is one of the downsides of OAuth's model, which assumes a client talks to one AS in the usual mode of operation.

I think case of SPA/PWA style client comes as very common scenario in Solid ecosystem. If we would require them to have public (global) WebID which includes valid redirect_uri for this application, would that suffice as what you describe in

When talking to multiple AS's, you'd need a way to either register with each of them, or create an identifier that could be referenced by each AS in a distributed fashion. This is one of the downsides of OAuth's model, which assumes a client talks to one AS in the usual mode of operation.

In other words any AS could use that WebID (an IRI) as client_id and not require any AS specific client registration.

@zenomt I recall you mentioning some reason for AS specific client_id, OP specific in case of WebID-OIDC and your implementation which you have mentioned.

[zenomt]

@elf-pavlik when doing dynamic registration, newly issued client_ids must be unique. on the monday phone call, i mentioned that my OP implementation makes new unique client_ids by encoding information about the registered response types and redirect_uris (and a random salt) directly in the client_id, so no per-client state needs to be stored in the OP. see https://github.com/zenomt/python-webid-oidc/blob/master/oidc.py#L202 which results in a client_id that looks something like

EAgA.arMIccpAhob8OV3vMVYi-dU69P5i.KQDZggTH2LHONFx6

these client_ids also come with client_secrets, also with no per-client state in the OP: https://github.com/zenomt/python-webid-oidc/blob/master/oidc.py#L219 .

the above is one way to do Stateless Dynamic Client Registration.

[elf-pavlik]

@zenomt do you see any possible problem with all Authorization Servers using globally unique WebID of the application as its client_id? For Public Clients that WebID would only need to include redirect_uri information. For Secure Clients it could have information of Public Key similar as WebID-TLS or WebID-HttpSig proposed in #20. I think with public and global WebID for Applications (clients) used by any Authorization Server, we would never use client_secret and instead rely on asymetric crypto for Secure Clients.

I think that matches this part of the initial proposal

Coupled with this, we can use a WebID for the client ID, or use it to fetch/validate a client ID, and tie that to a set of display and key information for a client. Client IDs are public information, and any attacker could claim any client ID, but we can use WebID mechanisms to lock down the behavior of a given client ID such that any attacker would need to also have control over the appropriate URLs for an app.

For next Monday I'll try to make Sequence diagrams similar to one in https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md based on my understanding of this proposal.

[jricher]

@elf-pavlik that matches my thinking on the proposal as well. I'm not enough of an expert on WebID, but as long as the AS can recognize the client_id and associate it with the appropriate information, we should be in fine shape.

[zenomt]

@elf-pavlik

do you see any possible problem with all Authorization Servers using globally unique WebID of the application as its client_id?

i don't see a security problem with this (although since the mapping from webid to redirect_uri is only one-way, the webid of the app isn't strongly authenticated to the user by following the redirect_uri, which might be a problem, and the webid need not have the same origin as the redirect_uri, which might also be a problem; more reflection is needed). however, i do have some other problems with this approach:

currently, WebID-OIDC has a very modest incremental add to an ordinary OpenID Provider:

1. (required) the webid URI is the sub (or webid if sub can't be used for this) claim of the id_token;
2. (required for POP tokens) the request parameter for the authorization_endpoint is supported, and the key property of request is inserted into the id_token as the cnf claim;
3. (required for app identification with POP tokens) the redirect_uri is added to the aud claim of the id_token.

to support "app's webid is the client_id" would require more significant changes to an OpenID Provider:

1. today an OP can be just a simple receive-requests-only HTTP server (no outbound connections). to support this it would need to make an outbound fetch for the webid document (including TLS PKI validation), and for performance, cache it;
2. this outbound connection from the OP has security implications, including a potential new attack surface and information leakage;
3. the OP would need to be able to parse at least Turtle and understand Linked Data to find the webid's hash URI in the document, and the redirect URI triple(s) of the webid -- this is a not-insignificant extra code/complexity footprint in an OP;
4. the extra code and complexity from (3) can have security audit implications for software that must necessarily be as secure, understandable, and audit-able as possible.

i'd prefer to take a step back and ask what problems we're really trying to solve with this:

• if it's "dynamic client registration is an extra step", so is fetching the webid document.
• if it's "the OP will collect tons of single-use clients", if this becomes a problem it can be addressed with stateless dynamic client registration as a server implementation detail with no changes needed to clients.
• if it's "an app identifier more granular than Origin would be nice", that can be done by using the redirect_uri as the app id (either with dynamic client registration today or by investigating using the redirect URI directly as the client_id as discussed elsewhere (monday's meeting and this comment in gitter) but considering the points above as to whether it's really needed).
• if it's "it would be super cool if apps were identified by a webid", then i agree, that's pretty cool and could be really useful. however, this would be highly WebID-OIDC specific. WebID-TLS would still be limited to identifying apps by Origin (a least common denominator, and according to TimBL and implied by the Same Origin policy, the only appropriate thing, though i definitely think more granular is useful and appropriate). it's possible future authentication methods might not be able to do better than Origin or redirect URI (especially that it might not be able to establish an app webid). another concern is that the webid might have a different origin than the redirect_uri, which is definitely not in the spirit of the Same Origin Policy.

given the kinds of changes to an OP that would be needed, and the implementation and operational costs associated with them, i'm not in favor of skipping dynamic client registration and using the webid as the client_id. and because i don't believe that DCR is actually a problem, i'm not in favor of skipping DCR and using the redirect_uri as the client_id.

i think there is tremendous value in keeping the required changes to an ordinary OIDC Provider implementation as small and uncontroversial as possible to encourage the adoption and use of WebID-OIDC. all three of today's required additions are backward-compatible and trivial to implement.

[zenomt]

after writing that giant message above, i thought of a simple example that doesn't work for "app has a webid that the OP dereferences". imagine i'm in my corporate (or home) intranet, using an app hosted on an inside-only server https://someapp.intranet.company.example. the app has a redirect URI of https://someapp.intranet.company.example/static/oauth2.html and a WebID of https://someapp.intranet.company.example/static/card#app. if my OP is outside my intranet, say at https://outside.example/oidc/, it's not going to be able to load https://someapp.intranet.company.example/static/card#app to find the redirect URI(s) or anything else about the app. however, for just the redirect_uri, my OP can redirect because it's my web browser (also inside) that actually looks that up and connects to it.

TL;DR: asymmetric connectivity → no joy.

edit: also consider the "inside-only" server http://localhost:8080 hosting the app/redirect_uri and webid document.

[elf-pavlik]

imagine i'm in my corporate (or home) intranet, using an app hosted on an inside-only server https://someapp.intranet.company.example. the app has a redirect URI of https://someapp.intranet.company.example/static/oauth2.html and a WebID of https://someapp.intranet.company.example/static/card#app.

Just like with mobile app on the device, redirect_uri doesn't need to be resolvable outside of the device, the WebID does. One could keep app on the intranet but it could still have public WebID. I think in some cases Authorization Server could just use the redirect_uri to identify the client (thinking especially of public clients), still for proper UX AS also usually will need more information about the client than it's redirect_uri. Touching authorization and access control, User might have preference to verify if app has some specific certification possibly represented as Verifiable Credential.