Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

I was hoping to get to a rough consensus in support of the idea before
coming up with a name that everyone will hate :)

In the meantime, however, name suggestions are of course welcome.


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov 
wrote:

> I'm all for that.
>
> I suppose you have already thought of a suitable name? :)
>
> Vladimir
> On 14/04/2020 23:08, Brian Campbell wrote:
>
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request..
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Brian Campbell]

Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:

> I've wondered about the decision to use a new scheme before
>  
> but
> this time i'd like to challenge the immediate usability of the future spec
> for one specific case - sender constraining public client Refresh Tokens.
>

I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?


>
> If at all, it is going to take time for RS implementations to recognize
> the new `DPoP` authorization scheme, let alone process it properly. In the
> meantime, i'd still like to have the option to bind issued public client
> refresh tokens using DPoP without affecting the access tokens. In doing so
> i get an immediate win in sender constraining the refresh tokens but not
> introducing a breaking change for the RS.
>
>
>- Do you see this as something an AS implementation is just free to do
>since it's both the issuer and recipient of a refresh token?
>
> That's my first thought, yes.


>
>- Should this be somehow baked in the draft?
>
> I'm not sure. Do you think it needs to be? I'm not sure what it would say
though.

In such a case the AS could bind the RT to the given dpop proof and either
not bind the AT while returning token_type=Bearer or bind the AT while
returning token_type value DPoP. In the latter case the AT would almost
certainly still work as a bearer token at the RS and the client that knew
the RS's needs could send it as such with an `Authorization: Bearer `.
Or if it didn't know the RS's needs, it could start with `Authorization:
DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
point it could send `Authorization: Bearer `.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.



>
>- Do you think client registration metadata could be used to signal
>such intent?
>
> I think it certainly could. But it seems maybe too specific to warrant
metadata.


>
>- Do you think the protocol should have signals in the messages
>themselves to say what the client wants to apply DPoP to?
>
> My initial thought here is no. Take the case of a client working with an
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.


>
>- What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
>we disqualify such cases or allow for sending two proofs, one for the AS to
>bind refresh tokens to, one for the RS to bind access tokens to?
>
> The AS is the one that does the binding (which includes checking the
proof) so I don't see how sending two proofs would really work or help the
situation?

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[Vladimir Dzhuvinov]

I'm all for that.

I suppose you have already thought of a suitable name? :)

Vladimir

On 14/04/2020 23:08, Brian Campbell wrote:
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity
> protected, and (for confidential clients anyway) authenticated
> authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a
> regular old parameterized authorization request. One variation of the
> Mix-Up Attack does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other
> ways a user might be tricked into following a maliciously crafted link. 
>
> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular
> parameterized authorization request and instead require use of the PAR
> endpoint to initiate an authorization request. Something like this
> could, of course, be implemented as custom policy or configuration in
> any AS. But I'm thinking it might be common enough to warrant adding a
> client metadata parameter to the PAR draft specifically for it. The
> metadata (and registered extensions) defined by Dynamic Client
> Registration [RFC7591] has come to imply a general data model and
> expected associated behaviors for clients that is useful for
> authorization server implementations, even when the Dynamic Client
> Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only
> use a request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited..  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] PAR and client metadata

[Brian Campbell]

Using PAR can facilitate improved security by giving clients a (relatively)
simple means for sending a confidential, integrity protected, and (for
confidential clients anyway) authenticated authorization request.

It seems like some of that improved security could be undermined by a
malicious actor somehow getting a user to navigate to a URL of a regular
old parameterized authorization request. One variation of the Mix-Up Attack
does this
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4..1
for example and email, social media, online forums, etc., are other ways a
user might be tricked into following a maliciously crafted link.

Following from that it seems logical that an authorization server might
want to restrict some clients from sending a regular parameterized
authorization request and instead require use of the PAR endpoint to
initiate an authorization request. Something like this could, of course, be
implemented as custom policy or configuration in any AS. But I'm thinking
it might be common enough to warrant adding a client metadata parameter to
the PAR draft specifically for it. The metadata (and registered extensions)
defined by Dynamic Client Registration [RFC7591] has come to imply a
general data model and expected associated behaviors for clients that is
useful for authorization server implementations, even when the Dynamic
Client Registration Protocol isn't directly in play. This particular
situation seems like a good potential candidate for a new such client
metadata parameter that would indicate that the given client can only use a
request_uri value obtained from the PAR endpoint to initiate an
authorization request. And that a regular old fashioned authorization
request from the given client would result in an error.

Do the folks of this fine WG think something like this would be a
worthwhile addition to the PAR draft?

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Vittorio Bertocci]

Thanks George, you described exactly what I was thinking.
I agree with your conclusions throughout the thread. Now that we have JTI 
mandatory, preventing tracking intra-API could be achieved only by issuing a 
new token for every transaction regardless of the presence of a sub, and a sub 
whose values change at every issuance would achieve the same.
One subtlety that perhaps is worth spelling out is that “unique” in this 
context shouldn’t be interpreted as “singleton”. An identifier is unique if it 
cannot be used to indicate any entity other than the intended one, but that 
doesn’t prevent the same entity from having multiple unique identifiers as long 
as they all satisfy that uniqueness criterion. And again, I maintain that 
preventing intra-API tracking is a non-goal in most scenarios.

That said, this was a great discussion. I am going to add explicit language in 
the privacy considerations warning readers about the possibility of 
correlation, and hinting at some of the measures described here as possible 
mitigations.
Thanks everyone!
V.

From: OAuth  on behalf of George Fletcher 

Date: Tuesday, April 14, 2020 at 08:35
To: Denis , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 
2020-04-13

Hi Denis,

If the same token is used (within a session) for multiple API calls then all 
those API calls can be correlated together even if the token does not have a 
'sub' claim because the token itself is the correlating identifier (same is 
true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after re-reading the 
spec (rfc 7519) I believe the AS could issue the 'sub' value as 
"urn:anonymous:" and create a new value with every token 
that is issued. This is similar to how Shibboleth supports attribute based 
access control with SAML assertions. Given it appears we disagree in our 
interpretations of the spec, I'm fine agreeing to disagree :)

Thanks,
George
On 4/14/20 11:23 AM, Denis wrote:
George,

I disagree with you:

   The 'sub' claim must be unique (local to the issuer or globally)
   with every issued token.

In addition, inter-API correlation prevention does not necessarily require a 
unique token for every API call,
since in many cases a session can be opened and one JWT can be used during the 
whole session (during successive calls).

Denis




On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

The subject value MUST either be scoped to be *locally unique in the 
context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the 
solution Vittorio suggested. While for any token issued the 'sub' claim must be 
unique (local to the issuer or globally); that doesn't mean it can't be 
different with every issued token. This would require the client to request a 
new token before every API invocation but it would suffice to protect against 
the suggested privacy correlation issues.

Note that inter-API correlation prevention is VERY difficult and really 
requires a unique token for every API call as the token itself can be a 
correlation handle (e.g. hash the token and it becomes the correlation 
identifier if the token is being reused for multiple API calls).

Thanks,
George


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[George Fletcher]

Hi Denis,

If the same token is used (within a session) for multiple API calls then 
all those API calls can be correlated together even if the token does 
not have a 'sub' claim because the token itself is the correlating 
identifier (same is true for the session identifier).


In regards to the AS issuing a token with a 'sub' claim, after 
re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' 
value as "urn:anonymous:" and create a new value 
with every token that is issued. This is similar to how Shibboleth 
supports attribute based access control with SAML assertions. Given it 
appears we disagree in our interpretations of the spec, I'm fine 
agreeing to disagree :)


Thanks,
George

On 4/14/20 11:23 AM, Denis wrote:

George,

I disagree with you:

   The 'sub' claim must be unique (local to the issuer or globally)
   with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).


Denis




On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally 
unique in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents 
the solution Vittorio suggested. While for any token issued the 'sub' 
claim must be unique (local to the issuer or globally); that doesn't 
mean it can't be different with every issued token. This would 
require the client to request a new token before every API invocation 
but it would suffice to protect against the suggested privacy 
correlation issues.


Note that inter-API correlation prevention is VERY difficult and 
really requires a unique token for every API call as the token itself 
can be a correlation handle (e.g. hash the token and it becomes the 
correlation identifier if the token is being reused for multiple API 
calls).


Thanks,
George



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Denis]

George,

I disagree with you:

   The 'sub' claim must be unique (local to the issuer or globally)
   with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).


Denis




On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents 
the solution Vittorio suggested. While for any token issued the 'sub' 
claim must be unique (local to the issuer or globally); that doesn't 
mean it can't be different with every issued token. This would require 
the client to request a new token before every API invocation but it 
would suffice to protect against the suggested privacy correlation 
issues.


Note that inter-API correlation prevention is VERY difficult and 
really requires a unique token for every API call as the token itself 
can be a correlation handle (e.g. hash the token and it becomes the 
correlation identifier if the token is being reused for multiple API 
calls).


Thanks,
George



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[George Fletcher]

On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the 
solution Vittorio suggested. While for any token issued the 'sub' claim 
must be unique (local to the issuer or globally); that doesn't mean it 
can't be different with every issued token. This would require the 
client to request a new token before every API invocation but it would 
suffice to protect against the suggested privacy correlation issues.


Note that inter-API correlation prevention is VERY difficult and really 
requires a unique token for every API call as the token itself can be a 
correlation handle (e.g. hash the token and it becomes the correlation 
identifier if the token is being reused for multiple API calls).


Thanks,
George

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Denis]

Vittorio, one comment in line.
It’s certainly possible to conceive ATs without subs, but I think the 
profile would be way less useful for SDK developers.

On the objections:
The sub doesn’t have to be a user, if you look at the earlier 
discussions the case in which the token has been issued for an 
application via client creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able to 
collide and track users, given that the sub can be a PPID that is 
different for every resource even if the authenticated subject was the 
same.


The sub is mandatory here because it was present in nearly every token 
among the ones observed, and although one should not overindex on 
those scenarios, I took that as strong indication that it is a 
frequently used field and guaranteeing its presence facilitates 
embedding in SDKs lots of downstream features, such as correlating 
with locally stored attributes, which would otherwise left as exercise 
to the reader. Per the points above, there are no obvious downsides in 
requiring the presence of the sub and significant upsides. Again, the 
AS is in full control of the sub content hence none of the privacy 
concerns mentioned here are mandated by the sheer presence of the sub 
claim.


If you feel the privacy section should be stronger in warning an AS 
against the possibility of collusion if global ide rockers 
[identifiers] are used, I am happy to reword accordingly.


Text needs to added into the Privacy consideration section stating more 
than that.


Since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally unique* in 
the context of the issuer *or* be *globally unique*.


the presence of the sub claim in a JWT allows (1) different resource 
servers to perform correlations of actions performed by the same subject
on these different resource servers and (2) a single resource server to 
perform inter-API correlations of actions performed by the same subject.
Since a single claim parameter is being used, it is not possible to have 
only one of the two previous cases.


Denis



On Mon, Apr 13, 2020 at 10:16 Aaron Parecki > wrote:


This is a good point, I often use the hotel key analogy as well.
The room door is the RS, the key is the access token, the door
does not need to know who the user is in order to know if it’s
okay to unlock given a particular key.

If sub is required, then this profile is limited in use to cases
where user identifiers are part of the system, and there will be
situations in which it’s not appropriate to use this profile for
access tokens. If that’s okay, this should be clarified in the
overview section to describe when this profile should be used.

Aaron



On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt mailto:dick.ha...@gmail.com>> wrote:

Why does the "sub" need to be required?

An access token is to prove authorization. The RS may not need
"sub" to constrain fulfilling the client request.

For example, it the access token has the same properties as a
movie ticket, the RS does not need to have any identifier for
who purchased the movie ticket.

The privacy implication is the RS can correlate across API
calls to know it is the same subject.




On Mon, Apr 13, 2020 at 8:16 AM Denis mailto:denis.i...@free.fr>> wrote:

Hello,

More on privacy about "JWT Profile for Access Tokens".

The current document REQUIRES the claim names *sub* and
*client_id*.

  * sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
  * client_id  REQUIRED - as defined in section 4.3 of
[RFC8693]

*1) **sub  REQUIRED*

RFC 7519 states:

4.1.2.  "sub" (Subject) Claim
   The "sub" (subject) claim identifies the principal
that is the
   subject of the JWT.  The claims in a JWT are
normally statements
   about the subject.  The subject value MUST either
be scoped to**
*be locally unique in the context of the issuer or be
globally unique*.
   The processing of this claim is generally
application specific.  The
   "sub" value is a case-sensitive string containing a
StringOrURI
   value. *Use of this claim is OPTIONAL.*

If *sub *is *REQUIRED *for this profile, then this allows
all resource servers to link accesses made by the same
client on different servers.

*2) client_id  REQUIRED*

RFC 8693 states:

4.3. "client_id" (Client Identifier) Claim
The client_id claim carries the client identifier of
the OAuth 2.0 [RFC 

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Denis]

Vittorio, some comments in line:

> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking 
about just parsing the sub value if it’s present or not surfacing it 
in an object model if it’s not- i think about reliably offering the 
higher level jobs to be done that are made possible by the sub 
presence (such as the correlation with the calling subject and local 
information, exactly as in your example all the movies a user watched 
thru that particular API).


> the resource is learning that the same user is doing different 
transactions
Thanks for the clarification, I didn’t realize that you were not just 
considering correlation across resources, but across calls to the same 
API. And you are right that in that case, an API would be able to 
correlate the user across subsequent API calls.
Per the above, I think that the ability of performing that correlation 
inter-API is a goal on most systems. More below.


> But NOT every token. So there were use cases where it was not required.
Not that it proves anything conclusively given that I only sampled 7 
system, but sub was actually used by all of them- with one of them 
omitting it only in a particular circumstance, for tokens issued via 
client credentials grant, and leveraging its absence as a way of 
deducing the nature of the token (user or app identity). During 
earlier drafts we debated at length the issue of providing mechanics 
to perform that distinction and the outcome was that there was no 
interest in providing it; and in the same debate it was established 
that sub applies to the authenticated entity, hence it can describe 
the app principal as well.
Again, the fact that the main analyzed systems don’t make a strong 
case for the absence of sub doesn’t imply that no such case exist; but 
I believe it is a strong indicator of sub usefulness in real world 
scenarios. In fact, together with iss and aud, sub is the only claim 
appearing in every provider JWT AT examined (Tho both sub and aud have 
each one exception due to special circumstances).


I am fine with explicitly calling out that the presence of a mandatory 
sub makes it possible for an API to correlate subsequent calls on the 
same entity.


I agree with you that the ability of performing correlation inter-API is 
a goal on most systems. However, this correlation *alone *CANNOT be 
achieved
using the sub claim using the definition of sub as defined in RFC 7519 
(4.1.2):


    The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.


Using the sub claim for inter-API correlation purposes would necessarily 
allow correlation across different resources.


In the "Privacy considerations" section, whether sub is REQUIRED or 
OPTIONAL, the reader should be warned that the presence of the "sub" 
(subject) claim
in a JWT makes it possible for different resources to correlate 
different calls, as well as for the same resource to correlate between 
inter-API calls.


I am ready to bet it won’t be a surprise for people using proprietary 
JWT ATs, also thanks to the widespread practice of using slightly 
modified ID token validation SDKs
(when ID token themselves aren’t directly used in lieu of ATs for API 
calls, as done by the likes of Kubernetes and other mainstream 
products, which hopefully will

eventually consider this profile instead).

As a last resort, nothing forces the AS to stop at varying sub values 
only per resource; it could go farther and supply a different sub 
value at every token issuance
for the same authenticating principal if it so chooses, and still 
adhere to the letter of this profile while preventing cross operation 
correlation.


Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.


That would adhere to the letter of this interop spec if not the the 
spirit, given that layout would be respected and one can creatively 
define principals in its own system.
If Apple can assign anti correlation emails, nothing prevents an AS 
doing the same with sub at different granularity.
That would break the job to be done that sub is meant to enable, but 
would prevent correlation in practice AND it would allow for us to 
include a piece of info
that proved to be useful for a large portion of known cases. But to 
reiterate, even if this workaround would not be possible,
I would still be OK with admitting cross operation correlation within 
the same resource as by design.


  and I hope you are also OK for admitting cross correlation of 
subjects between different resources. The question whether this was also 
done "by design" (or not) is left open.


Similar considerations apply for the client_id (client identifier) since 
RFC 6749 (2.2) states:


  The client identifier [i.e. a unique string 

[OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[Filip Skokan]

I've wondered about the decision to use a new scheme before
 but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.

If at all, it is going to take time for RS implementations to recognize the
new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to do
   since it's both the issuer and recipient of a refresh token? Should this be
   somehow baked in the draft?
   - Do you think client registration metadata could be used to signal such
   intent?
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?
   - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
   we disqualify such cases or allow for sending two proofs, one for the AS to
   bind refresh tokens to, one for the RS to bind access tokens to?


Best,
*Filip Skokan*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Vittorio Bertocci]

> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking about
just parsing the sub value if it’s present or not surfacing it in an object
model if it’s not- i think about reliably offering the higher level jobs to
be done that are made possible by the sub presence (such as the correlation
with the calling subject and local information, exactly as in your example
all the movies a user watched thru that particular API).

> the resource is learning that the same user is doing different
transactions
Thanks for the clarification, I didn’t realize that you were not just
considering correlation across resources, but across calls to the same API.
And you are right that in that case, an API would be able to correlate the
user across subsequent API calls.
Per the above, I think that the ability of performing that correlation
inter-API is a goal on most systems. More below.

> But NOT every token. So there were use cases where it was not required.
Not that it proves anything conclusively given that I only sampled 7
system, but sub was actually used by all of them- with one of them omitting
it only in a particular circumstance, for tokens issued via client
credentials grant, and leveraging its absence as a way of deducing the
nature of the token (user or app identity). During earlier drafts we
debated at length the issue of providing mechanics to perform that
distinction and the outcome was that there was no interest in providing it;
and in the same debate it was established that sub applies to the
authenticated entity, hence it can describe the app principal as well.
Again, the fact that the main analyzed systems don’t make a strong case for
the absence of sub doesn’t imply that no such case exist; but I believe it
is a strong indicator of sub usefulness in real world scenarios. In fact,
together with iss and aud, sub is the only claim appearing in every
provider JWT AT examined (Tho both sub and aud have each one exception due
to special circumstances).

I am fine with explicitly calling out that the presence of a mandatory sub
makes it possible for an API to correlate subsequent calls on the same
entity. I am ready to bet it won’t be a surprise for people using
proprietary JWT ATs, also thanks to the widespread practice of using
slightly modified ID token validation SDKs (when ID token themselves aren’t
directly used in lieu of ATs for API calls, as done by the likes of
Kubernetes and other mainstream products, which hopefully will eventually
consider this profile instead).

As a last resort, nothing forces the AS to stop at varying sub values only
per resource; it could go farther and supply a different sub value at every
token issuance for the same authenticating principal if it so chooses, and
still adhere to the letter of this profile while preventing cross operation
correlation. That would adhere to the letter of this interop spec if not
the the spirit, given that layout would be respected and one can creatively
define principals in its own system. If Apple can assign anti correlation
emails, nothing prevents an AS doing the same with sub at different
granularity.
That would break the job to be done that sub is meant to enable, but would
prevent correlation in practice AND it would allow for us to include a
piece of info that proved to be useful for a large portion of known cases.
But to reiterate, even if this workaround would not be possible, I would
still be OK with admitting cross operation correlation within the same
resource as by design.


On Mon, Apr 13, 2020 at 18:05 Dick Hardt  wrote:

>
>
>
> An SDK is going to support "sub" wether it is required or optional.
>
>
>
> On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci 
> wrote:
>
>> “Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P
>>
>> On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci 
>> wrote:
>>
>>> It’s certainly possible to conceive ATs without subs, but I think the
>>> profile would be way less useful for SDK developers.
>>> On the objections:
>>> The sub doesn’t have to be a user, if you look at the earlier
>>> discussions the case in which the token has been issued for an application
>>> via client creds (hence non user) has been debated at length.
>>> Knowing the subject does not necessarily lead to API being able to
>>> collide and track users, given that the sub can be a PPID that is different
>>> for every resource even if the authenticated subject was the same.
>>>
>>
> The privacy correlation I described is not solved by a per resource
> directed identifier as the resource is learning that the same user is doing
> different transactions -- or per my example, the resource is learning all
> the movies the user is seeing.
>
>
>>
>>> The sub is mandatory here because it was present in nearly every token
>>> among the ones observed,
>>>
>>
> But NOT every token. So there were use cases where it was not required.
>
>
>> and although one