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)


(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



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