[OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

[Denis]

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

[Brian Campbell]

In this document the information is very much intended for the
authorization server so that it can make appropriate policy choices about
the token to be issued.

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Vivek Biswas]

+1 to It MAY be an absolute URI, as specified by Section 4.3 of [RFC3986]".

Since the Audience Restriction can be a logical name to be interpreted by the Resource Server, if it really wants to enforce the audience check for a set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.

Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.



 

From: Denis [mailto:***@free.fr]
Sent: Tuesday, November 15, 2016 3:50 AM
To: ***@ietf.org
Subject: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

 

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

[Jim Willeke]

I liked the usage in https://tools.ietf.org/html/rfc7515

Collision-Resistant Name
A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>]. When
using an administratively delegated
namespace, the definer of a name needs to take reasonable
precautions to ensure they are in control of the portion of the
namespace they use to define the name.



--
-jim
Jim Willeke

+1 to *It MAY be an absolute URI*, as specified by Section 4.3 of
[RFC3986]".
Since the Audience Restriction can be a logical name to be interpreted by
the Resource Server, if it really wants to enforce the audience check for a
set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.
Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.
*Sent:* Tuesday, November 15, 2016 3:50 AM
*Subject:* [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-
indicators-00
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Steinegger, Roland Heinz (TM)]

On the new parameter.
I agree. The description of a "Collision-Resistant Name" sounds great to me
and would give developers good guidance.

Perhaps the parameter may be called "resource-type". "resource" is ambiguous
to me. It may refer to the kind of resource or to a concrete resource. (But
I don't know how this is typically handled in RFCs.)


On the topic privacy.
In my opinion, it depends on how you implement the authorization server
(AS). In many cases, the AS already knows what the user wants to access. The
scope often contains this information, e.g. "calendar_read" - we are
carrying out a study on how the scope is used currently.
If you use OAuth just for delegation, it may be a privacy problem. But, if
your AS authorizes based on authorization rules, where it has to know the
protected resource as well as who wants to access it, privacy may not be a
problem from my point of view.

Date: Thu, 17 Nov 2016 11:25:15 -0800
Subject: Re: [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-indicators-00
I liked the usage in https://tools.ietf.org/html/rfc7515
Collision-Resistant Name
A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>]. When using

an

administratively delegated
namespace, the definer of a name needs to take reasonable
precautions to ensure they are in control of the portion of the
namespace they use to define the name.
--
-jim
Jim Willeke

+1 to *It MAY be an absolute URI*, as specified by Section 4.3 of
[RFC3986]".
Since the Audience Restriction can be a logical name to be interpreted
by the Resource Server, if it really wants to enforce the audience
check for a set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.
Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.
*Sent:* Tuesday, November 15, 2016 3:50 AM
*Subject:* [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-
indicators-00
Hello everybody,
Since I am not present at the meeting, I read the minutes from the
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

The resource parameter should simply be blindly copied into the access
token by the AS, whether it bears a meaning or not.

A privacy considerations section should be added to attract the
attention of the reader/implementer to say that if it bears a meaning,
there may be privacy concerns with Big Brother.

Since the current draft has expired, if a new draft is being proposed,
it would then be greatly simplified.

Denis

Post by Steinegger, Roland Heinz (TM)
On the new parameter.
I agree. The description of a "Collision-Resistant Name" sounds great to me
and would give developers good guidance.
Perhaps the parameter may be called "resource-type". "resource" is ambiguous
to me. It may refer to the kind of resource or to a concrete resource. (But
I don't know how this is typically handled in RFCs.)
On the topic privacy.
In my opinion, it depends on how you implement the authorization server
(AS). In many cases, the AS already knows what the user wants to access. The
scope often contains this information, e.g. "calendar_read" - we are
carrying out a study on how the scope is used currently.
If you use OAuth just for delegation, it may be a privacy problem. But, if
your AS authorizes based on authorization rules, where it has to know the
protected resource as well as who wants to access it, privacy may not be a
problem from my point of view.

Date: Thu, 17 Nov 2016 11:25:15 -0800
Subject: Re: [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-indicators-00
I liked the usage in https://tools.ietf.org/html/rfc7515
Collision-Resistant Name
A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>]. When using

an

administratively delegated
namespace, the definer of a name needs to take reasonable
precautions to ensure they are in control of the portion of the
namespace they use to define the name.
--
-jim
Jim Willeke

+1 to *It MAY be an absolute URI*, as specified by Section 4.3 of
[RFC3986]".
Since the Audience Restriction can be a logical name to be interpreted
by the Resource Server, if it really wants to enforce the audience
check for a set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.
Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.
*Sent:* Tuesday, November 15, 2016 3:50 AM
*Subject:* [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-
indicators-00
Hello everybody,
Since I am not present at the meeting, I read the minutes from the
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

I believe that the parameter name should remain "resource". It's identifying a concrete protected resource and so is already correctly named. Besides, that name is already in production use for this purpose.

-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Steinegger, Roland Heinz (TM)
Sent: Friday, November 18, 2016 12:49 AM
To: ***@ietf.org
Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

On the new parameter.
I agree. The description of a "Collision-Resistant Name" sounds great to me and would give developers good guidance.

Perhaps the parameter may be called "resource-type". "resource" is ambiguous to me. It may refer to the kind of resource or to a concrete resource. (But I don't know how this is typically handled in RFCs.)


On the topic privacy.
In my opinion, it depends on how you implement the authorization server (AS). In many cases, the AS already knows what the user wants to access. The scope often contains this information, e.g. "calendar_read" - we are carrying out a study on how the scope is used currently.
If you use OAuth just for delegation, it may be a privacy problem. But, if your AS authorizes based on authorization rules, where it has to know the protected resource as well as who wants to access it, privacy may not be a problem from my point of view.

Date: Thu, 17 Nov 2016 11:25:15 -0800
Subject: Re: [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-indicators-00
I liked the usage in https://tools.ietf.org/html/rfc7515
Collision-Resistant Name
A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>]. When using

an

administratively delegated
namespace, the definer of a name needs to take reasonable
precautions to ensure they are in control of the portion of the
namespace they use to define the name.
--
-jim
Jim Willeke
On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas

+1 to *It MAY be an absolute URI*, as specified by Section 4.3 of
[RFC3986]".
Since the Audience Restriction can be a logical name to be
interpreted by the Resource Server, if it really wants to enforce
the audience check for a set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.
Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.
*Sent:* Tuesday, November 15, 2016 3:50 AM
*Subject:* [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-
indicators-00
Hello everybody,
Since I am not present at the meeting, I read the minutes from the
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Hannes Tschofenig]

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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

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

Post by Hannes Tschofenig
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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

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.

The only way to deal with that is the alternative of POP AT that the WG is documenting separately.

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.

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.

John B.

Post by Denis
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

Post by Hannes Tschofenig
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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

Hi John,

Post by John Bradley
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.

Post by John Bradley
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.

Post by John Bradley
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.

Post by John Bradley
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

Post by John Bradley
John B.

Post by Denis
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

Post by Hannes Tschofenig
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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

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

Post by Denis
Hi John,

Post by John Bradley
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.

Post by John Bradley
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
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.
* 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.

Post by John Bradley
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.

Post by John Bradley
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

Post by John Bradley
John B.

Post by Denis
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

Post by Hannes Tschofenig
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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

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

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

[Denis]

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

Post by George Fletcher
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

Post by Denis
Hi John,

Post by John Bradley
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.

Post by John Bradley
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,
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.
* 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.

Post by John Bradley
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.

Post by John Bradley
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

Post by John Bradley
John B.

Post by Denis
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

Post by Hannes Tschofenig
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

Post by Denis
Hello everybody,
Since I am not present at the meeting, I read the minutes from the first
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
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.
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
https://www.ietf.org/mailman/listinfo/oauth

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

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