RE: [security-services] Moving subjects up to assertions(disregardfirst reply)

[Scott Cantor <cantor.2@osu.edu>]

> Eve started this thread with the (dangerous, in my opinion 
> :-) speculation that XACML might still need assertions with 
> no SAML-style subject, because their subjects look so different.

It's not really speculation, assuming the end-game is embedding an
unmodified XACML element in an assertion. Unmodified being the key word in
that sentence. Clearly when we originally told them "hey, just extend
statement" it never occurred to me we'd be separately toying with this
degree of change to SAML...
 
> 1) make the SAML subject extensible enough to handle XACML subjects

I'm not so sure it isn't (Subject contains at least two anyType's at this
point!), but the issue is the decomposition of the XACML object, I suppose.

> What I want is:
> 
> <sequence>
>   <subject>
>   <choice maxOccurs="unbounded">
>     <statement types, none of which contain any traces of our 
> old subject-related elements>
>   </choice>
> </sequence>

Right. My suggestion was that whatever we do, we try and preserve that by
not mixing it with something else, and not creating a second kind of
assertion. Having a mutually exclusive fork within <Assertion> seemed the
best "bad" solution.
 
> Hey - I just had another thought: SubjectLocality is really a 
> *subject confirmation method*, and should be schemad as such.

Hmm, sometimes maybe. I could see defining a bearer method that includes it.
Maybe you were just joking? ;-)

-- Scott