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

["Reid, Irving" <irving.reid@hp.com>]

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.

In my not-nearly-humble-enough opinion, there are two right ways to fix this:

1) make the SAML subject extensible enough to handle XACML subjects
2) If their assertions really need to be that different, what they're doing isn't really SAML, is it? Let them define their own base schema.

Now that I've stirred that hornet's nest...

> From: John Kemp [mailto:john.kemp@nokia.com] 
> 
> ... In addition, the pseudo-schema you have below seems to 
> restrict your assertion to non-Subject related statements OR 
> Subject-related statements in one assertion but not both. 
> That is not as 
> flexible as what we have now.

That's what this is all about. As far as we can tell, nobody actually needs the flexibility we currently have, and pretty well everybody agrees that the added complexity is a problem.

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>

If it doesn't have a subject, it's something else, not a SAML assertion.

> So, I guess I would suggest:
> 
> 1) We define an container for Subject+SubjectStatements (where 
> SubjectStatement and its ilk are now descended from 
> StatementAbstractType, with additional other Subject related info 
> (SubjectLocality for example).

Hey - I just had another thought: SubjectLocality is really a *subject confirmation method*, and should be schemad as such.

 - irving (schemad? sheesh) -