RE: [security-services] On allowing multiple value types for an attribute

[Mohammad Jafari <mjafari@edmondsci.com>]

Thanks Hal. I was referring to Section 2.7.3. line 1168: which requires Assertions containing <AttributeStatement> elements to contain a <Subject> element as well.

I think regardless of the optionality of the ID my questions about interoperability with XACML still remain:
- Should the XACML subject-id be encoded as the ID under saml:Subject or as a SAML Attribute?
- If saml:Subject includes an ID, should it be mapped into an XACML attribute?
- If there is a subject-id in the SAML Attributes and there is also an ID under saml:Subject, should they match?

The XACML Attribute profile of SAML is currently silent about the above questions but we need to make decisions about these in XSPA.

Regards,
Mohammad


> -----Original Message-----
> From: Cantor, Scott [mailto:cantor.2@osu.edu]
> Sent: Wednesday, November 26, 2014 10:50 AM
> To: Hal Lockhart; Mohammad Jafari; security-services@lists.oasis-open.org
> Subject: Re: [security-services] On allowing multiple value types for an
> attribute
> 
> On 11/26/14, 5:38 PM, "Hal Lockhart" <hal.lockhart@oracle.com> wrote:
> 
> >I think he is referring to section 3.3.4 which says the response to any
> >of the Query requests must contain a subject which matches the subject
> >in the query. I don't see any practical way to do an attribute query
> >without specifying an identifier element. Otherwise whose attributes
> >should be returned?
> 
> You could pass a SC element with a key in it, to use one example, or it could
> be front-channel with a bearer SC in it.
> 
> But in any case, the rule for a Response to a query isn't necessarily something
> that has to apply to any assertion created with an attribute statement in it.
> Though it seems that we did in fact required Subject (but not an ID) for that.
> 
> -- Scott