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 (disregard first reply)

> From: Greg Whitehead [mailto:grw@trustgenix.com] 
> Don't know if this helps, but it just struck me from following this  
> thread that part of the problem with the terminology here is that  
> Subject really seems to mean Security Principal (human or system  
> entity), and while most Assertions are about Principals, some 
> are about  
> other things (subjects which are not Principals, such as 
> Resources or  
> Policies).

There was considerable debate, a clear motion, and a positive vote during one of the early SAML face-to-face meetings (F2F2 or F2F3, I think, well before SAML 1.0 was published) that SAML assertions would *ONLY* be about Principals, and nothing else.

Not to say we can't change that, but SAML 1.1 is *explicitly* not supposed to support such use cases.

> So, I would contend that there are no "subject-less" 
> Assertions (lower  
> case intentional here to refer to the part of speech not the SAML  
> schema element), but there *are* Assertions about subjects 
> other than  
> Principals. I wonder if it's possible to resolve this issue 
> using a URI  
> attribute on Subject to indicate what sort of subject we're talking  
> about? Every subject will still need to be named somehow, so I think  
> NameIdentifier applies universally. SubjectConfirmation 
> probably only  
> applies to subjects that are Principals, but I'm not sure.

My (admittedly vague) memory of those early F2F meetings is that we couldn't really figure out the semantics of assertions about things other than Principals, so instead we banned them. I don't see any reason why we couldn't open that up, perhaps with specific normative language that SAML does not define the semantics thereof and that the semantics SHOULD be defined in a profile (not the clearest language - basically, if you're going to do it, write down what you intend it to mean).

> -Greg

 - irving -

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