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] Proposed clean up on subject text


> Conor P. Cahill wrote:
>
>Scott Cantor wrote on 11/11/2004, 9:34 PM:
>
> > To wrap up that thread on describing the two options for Subject content
> > (the one Rob, Ron, Conor, me, etc. presented text for), here's a small
> > modification to Rob's text that adds Ron's clarification:
> >
> > "A <Subject> element can contain both an identifier and zero or more
> > subject
> > confirmations which a relying party can verify when processing an
> > assertion.
> > Once any subject confirmations are verified, the relying party can
> > treat the
> > entity presenting the assertion as the entity that the SAML authority
> > associates with the name identifier and the claims in the assertion.
>
>
>I still think this too strongly indicates that the claims and the
>name identifier are about the confirming entity.  In many cases this
>will not be the case (the claims and the identity is about a user
>and the confirmation is about an entity that can use the assertion
>in a transaction).  The two entities (user and presenter) are very
>different entities to the Authority.
>
>I also think we should call out what it means if there are no
>confirmations in the <Subject> (e.g. it is considered confirmed
>by presentation).
>
>How about something along the lines of:
>
>    A <Subject> element can contain both an identifier and zero
>    or more subject confirmations which a relying party can verify
>    when processing an assertion.  If there are no subject
>    confirmations, or if any one of the listed subject confirmations
>    are verified, the relying party can treat the entity presenting
>    the assertion as an entity that the SAML authority has
>    associated with the entity identified in the name identifier
>    (which may or may not be the same entity).
>
>I don't think we need to bring in the claims at this point.  The claims
>are always about the name identifier (if present).
>
>Conor
>

Subject confirmation, although its name might suggest otherwise, 
contains the constraints
that the assertion authority has defined for establishing the 
correspondence between
the (subject and statements) of the saml assertion and any entity 
presenting the assertion to a
relying party.

When confirmation constraints are satisfied, any information about the 
confirming entity would be
separately expressed within the subjectconfirmation elements themselves.

I think you are suggesting that SC not be viewed as authorizing the 
binding of claims.
I don't subscribe to that point of view.

Philpott, Robert wrote:

>Looks good, but... 
>
>Should we be more normative with the "can treat"'s in both paragraphs?
>Should they be changed to "MAY treat" (i.e. it is truly optional)?
>"SHOULD treat" (i.e. it is recommended but there may be valid reasons
>not to do so)?
>
>I think we should be normative about it.
>  
>
I agree, and would recommend "MAY treat", as I veiw the assertion authority
as permitting this treatment. I think the RP is ablways able (as in 
"can") to do whatever it
wants.

Ron

>Rob Philpott
>Senior Consulting Engineer 
>RSA Security Inc. 
>Tel: 781-515-7115 
>Mobile: 617-510-0893 
>Fax: 781-515-7020 
>mailto:rphilpott@rsasecurity.com
>
>  
>
>>-----Original Message-----
>>From: Scott Cantor [mailto:cantor.2@osu.edu]
>>Sent: Thursday, November 11, 2004 9:35 PM
>>To: SAML
>>Subject: [security-services] Proposed clean up on subject text
>>
>>To wrap up that thread on describing the two options for Subject
>>    
>>
>content
>  
>
>>(the one Rob, Ron, Conor, me, etc. presented text for), here's a small
>>modification to Rob's text that adds Ron's clarification:
>>
>>"A <Subject> element can contain both an identifier and zero or more
>>subject
>>confirmations which a relying party can verify when processing an
>>assertion.
>>Once any subject confirmations are verified, the relying party can
>>    
>>
>treat
>  
>
>>the
>>entity presenting the assertion as the entity that the SAML authority
>>associates with the name identifier and the claims in the assertion.
>>
>>Alternatively, a <Subject> element can contain one or more subject
>>confirmations without an identifier being present. In this case, once
>>    
>>
>any
>  
>
>>of
>>the subject confirmations are verified, the relying party can treat
>>    
>>
>the
>  
>
>>entity presenting the assertion as the entity that the SAML authority
>>associates with the claims in the assertion."
>>
>>The intent, of course, is that "can treat the entity presenting the
>>assertion as...." is code for "it means whatever you want it to mean".
>>
>>-- Scott
>>
>>
>>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.ph
>p.
>
>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.
>
>  
>



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