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)

ext Scott Cantor wrote:

>>And... SubjectLocality, in the AuthenticationStatement, kinda relates to 
>>a Subject - which would no longer be present in the statement itself. 
>>Again, that seems a bit strange.
> Well, SubjectLocality is nominally data about the authentication event. It's
> definitely at least a cousin of SubjectConfirmation in terms of actual use
> (checking client addresses during SSO), but I don't know that it doesn't
> still belong in AuthenticationStatement independent of that use.

So, perhaps it should be called AuthenticationLocality? And it does seem 
like that would be most useful with SubjectConfirmation anyway. Is there 
another use for SubjectLocality BTW? Does it matter whether it's in the 
authentication statement or at the assertion level? Could it not relate 
to other (Subject)Statements?

> If we start arguing everything related to a Subject shouldn't be in the
> statements, it's really arguing to eliminate statements and collapse the
> data model. I didn't originally push hard for this wholesale optimization
> for exactly that reason, I saw a slippery slope.

I don't think it needs to be a slippery slope. Other SubjectStatements 
contain things other than the Subject that are still relevant statements 
to make ( Attributes, or Decisions for example). And one should be able 
to make multiple statements in the same assertion - as we discussed on 
the last call (I think) it's a good optimization.

- JohnK

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