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
