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
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
From: Jim Willeke <j...@willeke.com>
To: oauth@ietf.org
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 <vivek.bis...@oracle.com>
wrote:
+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:denis.i...@free.fr]
*Sent:* Tuesday, November 15, 2016 3:50 AM
*To:* oauth@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
_______________________________________________
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
