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