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

> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> ...
> I would then add language to the spec for the existing three 
> statement types
> plus any future subject-based statement extensions that basically says
> something like:
> "An assertion containing such a statement MUST contain a 
> <Subject> element
> as defined by sec. XX. If a <Subject> is not provided, then any such
> statements are invalid and MUST be ignored. This <Subject> 
> element applies
> to all such statements in the assertion. Any other statements 
> MUST define
> their relationship to the <Subject> element, if any."
> Wordsmithed as need be, but that's the gist.

I'm not sure we need to be quite this strong. Based on previous discussions, I suspect XACML would like to have AttributeStatement elements without subjects.

One could also build a sort of "hard anonymity" by profiling AuthenticationStatements that have no Subject (perhaps Shib could use this, rather than short-lived pseudonyms).

> I would even be fine with adding <SubjectStatement> back in 
> and having it
> merely hold SessionIndex, and then derive our statements off 
> it. Then all
> the language goes in there, which makes things easier. Not sure if the
> notion of session makes sense without a <Subject>, but I doubt it.

I think the session ends up being a pseudo-subject, roughly equivalent to a short-lived pseudonym. As usual, I prefer fewer types and derivations wherever feasible.

> -- Scott

 - irving -

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