RE: [xacml] Inputs to rfc822Name-match

[Tim Moses <tim.moses@entrust.com>]

Seth - I am picturing a situation like this ...

A policy is written to apply to the resource "email addresses".  In this
case, the target would contain a resource match with the attribute
designator "resource-id", of type "string" and value "*".

A context request is received containing the resource attribute
"resource-id", of type "RFC 822 name" and the value "anderson@sun.com".

How can the PDP tell that the policy is applicable?  The resource-ids match,
the data types don't match and "*" isn't obviously an email address.

So, always making the general form the same type as the specific form would
assist matching.  This happens naturally for X.500 names and (I hope) the
other name forms.

All the best.  Tim.

-----Original Message-----
From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM] 
Sent: Thursday, May 13, 2004 1:11 AM
To: Tim Moses
Cc: 'XACML'
Subject: Re: [xacml] Inputs to rfc822Name-match



Tim Moses wrote:
> Anne - I know you are right.  But, WE define 
> urn:oasis:names:tc:xacml:2.0:data-type:rfc822Name.  So, if we want "*" 
> to be a valid instance of this type, then it can be.  Can't it?

It could be, but why would we want this? I can't think of any reason why 
we'd want someone able to specify * or .com or something similar as a 
valid email address (since that breaks with rfc822, which is what we 
reference for the datatype). Technically, we specify the datatype's 
identifier, but not the format of the datatype, so we don't actually 
have the freedom to re-define the type unless we define it from scratch.

Tim, do you have a specific use case that requires this? I'm trying 
hard, but I can't come up with a scenario where you need to pass two 
rfc822Names to the match function and can't instead provide a string as 
one parameter. Unless there's a real problem this solves, I wouldn't 
want us to confuse the rfc822Name datatype.


seth