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
