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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: RE: [xacml] request and response context schema

Title: RE: [xacml] request and response context schema

Hi Simon,

I have a slight preference for URI as well, but if it shows up in a SAML assertion as a string, will it be trivial to transform this to valid URI syntax?  It just seems to me that the transformation from the protocol inputs to the XACML context might be easier if we keep the type as string.  If that's not true, then I have no problem whatsoever with URI.

What I recall from our discussion was that people wanted to have the ability to put the actual resource content in the context in some cases, and in other cases to put a pointer to the content (i.e., a URL for the resource).  When I read your schema for ResourceSpecifier, I assumed that "ResourceURI" was the (optional) locator.  Lower down in the schema (in DecisionType), you introduce "ResourceName", which hadn't appeared before.  So, all I was suggesting was that "ResourceURI" change its name to reflect the fact that it is going to be the URL form of the anyURI type, and that a new attribute be added for "ResourceName", which is what would be copied into DecisionType.

OK.  I would suggest adding principal information to DecisionType.

I only suggested changing Action to string in DecisionType so that it would match the definition for Action earlier in the schema (the <Action> element immediately under <ContextActionType> is of type "xs:string").  I'm just suggesting that the input and output contexts should have types that match whenever they're talking about the same elements...


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

Powered by eList eXpress LLC