Hi George,

As you say "It's unclear from the spec, how the RS should do audience 
restriction".

There are two cases where I can see a benefit:

a) if the user is younger than 18, the IdP knows it and can filter the 
URIs using a black list of sites that are not allowed to minors.
b) if the user is using an IdP server from his employer, the employer 
can filter the URI using a white list of sites that are allowed.

However, if the user is older than 18 and is using an independent IdP 
(e.g. from his bank), no filtering should be done
and thus a "non-URI value" should/may/can be used.

So I withdraw my previous statement saying that " The use of an absolute 
URI should be deprecated".

Also take note that there is a need to include a target RS in an access 
token *only if* the access token might be forwarded
to another RS,

I believe that, in any case, a "privacy considerations" section should 
be added to inform the reader about the pros and the cons.

Denis

> Hi Denis,
>
> If I understand your arguments correctly, you'd like a way to ask the 
> AS to add an RS supplied nonce to the access_token. This is done in 
> OpenID Connect with the id_token but nothing like this exists within 
> OAuth2. Largely because the entity asking for the token (client) is 
> different from the entity that will consume the token (resource server).
>
> I see this oauth-resource-indicators spec trying to address a 
> different problem. Namely, allowing the AS to not issue a token if the 
> requested "resource" is suspect or does not in some way meet the AS 
> policy.
>
> It's unclear from the spec, how the RS should do audience restriction 
> though I suspect that the RS will introspect the token and then 
> compare the returned audience(s) in some way with itself. 
> [Brian/John/Hannes I'd recommending adding a section on audience 
> restriction processing in the RS.]
>
> The model you suggest in this thread is much closer to UMA (User 
> Managed Access) [1] where the client first tries to access a resource 
> and then is told they need to obtain some additional claims before 
> access will be granted.
>
> Thanks,
> George
>
> [1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html
>
> On 11/22/16 12:22 PM, Denis wrote:
>> Hi John,
>>
>>> The privacy problem is a touch hypothetical the way that OAuth 
>>> currently works. There is not standard access token, a AS producing 
>>> access tokens that could be used across a number of RS in different 
>>> security domains would be a security disaster, unless they are proof 
>>> of possession tokens. If all of the RS trust each other by being in 
>>> the same security domain they can all collude and the AS can know 
>>> where the tokens are used without the resource being indicated to 
>>> the AS directly. If the RS are in different security domains then 
>>> potentially some privacy is disclosed.
>>
>> I am dealing with scenarios where RS may be in the same security 
>> domain or in different security domains.
>> More precisely, none of the RS will necessarily be in the same 
>> security domain as the AS.
>>
>>> The only way to deal with that is the alternative of POP AT that the 
>>> WG is documenting separately.
>>
>> I disagree.  There are some cases, where an access token should be 
>> targeted to a RS and the target RS should be indicated
>> in the access token.
>>
>> draft-campbell-oauth-resource-indicators should say that data that 
>> can be recognized by the RS may be incorporated
>> into the access token.
>>
>> This has nothing to do with POP which is another issue.
>>
>> draft-ietf-oauth-pop-architecture-08 does not, unfortunately, 
>> provides a solution since a major threat has been omitted:
>>
>>     Collusion between users
>>
>>           Users can collude and one user may attempt to use an access
>>     token legitimately obtained from an AS
>>           and then transmit it to another user so that it can be used
>>     on the same RS.
>>
>>
>> This document states on page (clause 3.3):
>>
>>   * the important assumption in this use case is that a resource
>>     server does not have TLS support
>>     and the security solution should work in such a scenario.
>>
>> This means that binding the access token to HTTP (see 
>> draft-ietf-tokbind-https-06) is not a valid solution
>> since it is unable to address the Alice and Bob Collusion (ABC) attack.
>>
>>> I think it is fine to say that if the AS are in separate security 
>>> domains and privacy is a issue, then use PoP rather than resource to 
>>> protect the AT from replay.
>>
>> I do not think this is what should be said.
>>
>> If an access token cannot be replayed on another RS, then it does not 
>> necessarily need to be targeted to a RS (... but it will not heart).
>>
>> If privacy is a concern _and_ if there is a need to include a target 
>> RS in an access token because the access token might be forwarded
>> to another RS, then a pseudo-random number shall be used to identify 
>> the RS rather than an absolute URI.
>>
>>> The reason for using a URI for the resource is that it is something the client knows.
>>> If we use a abstract name the client might be tricked into giving a token to the wrong resource.
>>
>> Please take another look at the example I have provided below. The 
>> problem you mention does not exist.
>>
>> Denis
>>> John B.
>>>
>>>
>>>> On Nov 22, 2016, at 9:34 AM, Denis<denis.ietf@free.fr>  wrote:
>>>>
>>>> Hi Hannes,
>>>>
>>>> I do not deny the fact that it is necessary to provide some information to the authorization server
>>>> to indicate the resource server where the access token shall only be used.
>>>>
>>>> Let us illustrate the concept with a simple scenario.
>>>>
>>>> A user first connects to a resource server and announces some actions he would like to perform.
>>>> In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
>>>> in your access token the random value (some kind of challenge) I have just generated for you only".
>>>>
>>>> The client forwards that random value to the authorization server which is blindly copied and pasted
>>>> into the access token. If the resource server does not recognize this value, the access will be denied.
>>>>
>>>> In this way, the authorization server has no way to know where the access token will be used.
>>>>
>>>> On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
>>>> The use of an absolute URI should be deprecated because of this privacy concern.
>>>>
>>>> Denis
>>>>
>>>>> Hi Denis
>>>>>
>>>>> draft-campbell-oauth-resource-indicators gives the authorization server
>>>>> information about the resource server the access token will be used with.
>>>>>
>>>>> Without this information there is the risk that the access token is
>>>>> replayed at other resource servers and with the proof-of-possession /
>>>>> token binding work there obviously has to be an indication of where the
>>>>> token is used.
>>>>>
>>>>> The reason for using an absolute URI is that the resource server needs
>>>>> to take the information from the incoming access token and to compare it
>>>>> with its own information in order to determine whether the token is
>>>>> indeed intended for itself.
>>>>>
>>>>> If the authorization server does not know to whom it gives rights to
>>>>> access protected information then this is also a privacy risk (namely
>>>>> unauthorized access).
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> On 11/15/2016 12:50 PM, Denis wrote:
>>>>>> Hello everybody,
>>>>>>
>>>>>> Since I am not present at the meeting, I read the minutes from the first
>>>>>> session, in particular:
>>>>>>
>>>>>>      Brian Campbell and John did a draft allowing the client to tell the
>>>>>>      AS where it plans to use the token
>>>>>>      draft-campbell-oauth-resource-indicators
>>>>>>
>>>>>>                    This enables the AS to audience restrict the access
>>>>>>      token to the resource
>>>>>>                    Phil Hunt:  We should keep the audience restriction
>>>>>>      idea on the table
>>>>>>
>>>>>> The introduction contains the following sentences:
>>>>>>
>>>>>>      Several years of deployment and implementation experience with OAuth
>>>>>>      2.0 [RFC6749] has uncovered a need, in some circumstances,
>>>>>>      for the client to explicitly signal to the authorization sever where
>>>>>>      it intends to use the access token it is requesting.
>>>>>>
>>>>>>      A means for the client to signal to the authorization sever where it
>>>>>>      intends to use the access token it's requesting is important and
>>>>>>      useful.
>>>>>>
>>>>>> The document contains a "security considerations" section but
>>>>>> unfortunately no "privacy considerations" section.
>>>>>>
>>>>>> Clause 2 states:
>>>>>>
>>>>>>      The client may indicate the resource server(s) for which it is
>>>>>>      requesting an access token by including the
>>>>>>      following parameter in the request.
>>>>>>
>>>>>>      resource
>>>>>>
>>>>>>      OPTIONAL. The value of the resource parameter indicates a resource
>>>>>>      server where the requested
>>>>>>      access token will be used.*It MUST be an absolute URI*, as specified
>>>>>>      by Section 4.3 of[RFC3986],
>>>>>>
>>>>>> With such an approach, the authorization server would have the ability
>>>>>> to *act as a Big Brother *and hence to know exactly
>>>>>> where the user will be performing activities.
>>>>>>
>>>>>> However, some users might be concerned with their privacy, and would
>>>>>> like to restrict the use of the access token
>>>>>> to some resource servers without the authorization server knowing which
>>>>>> are these resource servers.
>>>>>>
>>>>>> The key point is whether the information is primarily intended to the
>>>>>> authorization server or to the resource server(s).
>>>>>>
>>>>>> I believe that it is primarily intended to the resource server(s) rather
>>>>>> than to the authorization server in order to be included
>>>>>> in an access token. Obviously, the information needs to transit through
>>>>>> the authorization sever, that should simply be copied
>>>>>> and pasted into the access token. Its semantics, if any, does not
>>>>>> necessarily needs to be interpreted by the authorization sever.
>>>>>>
>>>>>> I believe that a "privacy considerations" section should be added.
>>>>>>
>>>>>> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
>>>>>> of [RFC3986]" should be removed or
>>>>>>   replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
>>>>>> of [RFC3986]".
>>>>>>
>>>>>> Obviously, other changes would be necessary too.
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>