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)



On 4 March, Eve L. Maler writes: Re: [security-services] Moving subjects up to assertions (disregard first reply)
 > 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.

XACML has two strong use cases.

1. XACML's Query and XACMLAuthorizationDecisionStatement are NOT
   tied to a Subject.  An XACML request may contain no Subject
   whatsoever!  The only requirement is that it contain a
   resource.  Any Subject information is weighted equally with
   any Resource or Action information.

2. XACML's XACMLPolicyStatement does not contain a Subject at all
   (it MAY refer to one or more Subject Attributes, but those may
   refer to many different subjects that might come in from
   different requests).

   This Statement has an issuer (the policy creator), but no
   Subject.  Yet I think it is squarely in the scope of SAML as a
   Security Assertion.

Anne

 > 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
 > 
 > 
 > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
 > 

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



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