OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Comments on Attributes in Draft08e-draft-03-diff


> NameFormat doesn't classify the *attribute*, it classifies 
> the *attribute name*. I personally feel that this is serious 
> over-engineering, because none of my use cases involve a 
> *run-time* decision based on whether a specific assertion 
> contains an attribute name that is specifically a URI or an 
> OID or whatever; if the attribute name format is significant, 
> I expect to get that information from a profile rather than 
> at run time. YMMV.

You're responding to me, but I agree with you. I just want the name to be
unique, period. Right now, it's not, but at least the NameFormat+Name should
be, which corrects a problem with AttributeNamespace.

> While I agree with Scott, it's seems clear that others don't, 
> since XACML already has URIs for names and they have 
> determined that they still need the additional metadata.

I don't think so. XACML is not asking for NameFormat. They want us to use
URIs for names, and be done with it. The other metadata they're asking for
has nothing to do with names. The "others" in question here are SSTC, not
XACML. (It's self inflicted pain.)

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]