(First, a plea not to cc: people extraneously -- I got *two* copies of
this whole thread! Second, please note that Anne Anderson has gotten
added to the SSTC list, so you don't need to copy her anymore either.
Third -- Anne, I hope you will respond regarding XACML's requirements in
this area!)
I'm not crazy about the idea of a complicated content model with lots of
choice branches; usually (though not always) that means we're trying to
add some element-worthy semantics without adding elements. It's false
economy.
That said, if we really wanted to give people a truly subject-free
extension point for statements, it's kind of appealing to have a
separate datatype branch for it even if it looks identical to
subject-ful statements (with no <Subject> information present locally)
because the semantics would be different.
But the best solution of all -- other than the one we agreed to and I've
already implemented in the forthcoming core-07! -- is for us to respond
to XACML's putative need for subject information that's different from
ours. We haven't heard of a use case for true freedom-from-subjects,
only a (guessed) use case for subject information supplied in a form
that's incompatible with ours. I could easily make a
SubjectAbstractType with nothing in it, then derive our familiar
SubjectType from it.
Anne?...
Eve
Scott Cantor wrote:
>>So, perhaps it should be called AuthenticationLocality?
>
>
> IIRC, the name was chosen because people got confused as to whether the
> address/hostname referred to the client, or a server. They still do in fact.
> I think SubjectLocality was a late compromise to try and clarify it. I think
> I suggested PrincipalLocality at one point, but Principal didn't show up in
> the schema anywhere, so people didn't want to add it late.
>
>
>>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?
>
>
> I suppose one could argue it's a special case that maybe belongs solely as
> bearer confirmation data. I don't personally have any other use for it, and
> even that use is pretty minimal since more and more people are stuck behind
> NATs.
>
> -- Scott
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
