RE: [security-services] Proposed clean up on subject text

From
Philpott, Robert <>
Date
2004-11-12T12:56:27+00:00
ID
Thread
RE: [security-services] Proposed clean up on subject text
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.

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc. 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:

> -----Original Message-----
> From: Scott Cantor [mailto:]
> 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.