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] Moving subjects up to assertions (disregardfirst reply)


> > 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...

Agreed. This is a dramatic change to SAML, and it make take XACML (and, for that matter, Liberty) some time to catch up. That's why we need to ask them before we try and design a solution for their problem...

> > 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.

I'm pretty sure Subject is extensible enough.

> > 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.

I started to write down a way of hacking it into the above outline without the mutually exclusive fork, but then erased it. I really don't think we should accommodate this usage.

> > 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? ;-)

I never joke about schema.

> -- Scott

 - irving (i am a language lawyer. language lawyers always lie) -


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