RE: [security-services] NameIDPolicy Format use clarification

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Note that section 8.3 of core does not list the
urn:...:nameid-format:encrypted since it is never actually carried in
the format attribute of an actual NameID.  It is described in the
NameIDPolicy element discussion (section 3.4.1.1).  

We should probably list it in the section with a clear explanation of
where it is used (and not used).

So is the assumption that if the NameIDPolicy does request an encrypted
NameID, that the returned NameID should be a persistent identifier?
IMO, SOMETHING should be stated to be assumed, since otherwise, the
"...:encrypted" format is not useful.

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, December 16, 2004 11:55 AM
> To: 'Thomas Wisniewski'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] NameIDPolicy Format use clarification
> 
> > Hi, just wanted to get a clarification on the format
> > attribute (when it's valued with ...encrypted) inside of
> > NameIDPolicy. It seems to imply that the requester cannot
> > specify a particular format it wants (where the NameID coming
> > back is in encrypted form). For example, what if I want an
> > encrypted  ....emailAddress NameID.  Was that the intent?
> 
> Yes, the use case for anything more advanced wasn't obvious, and the
> complexity vs. just leaving it out of band seemed like a bad trade
off. It
> used to be impossible to ask for anything, and use of encrypted IDs
> themselves tend to be fairly specialized, since you can just encrypt
the
> whole thing anyway.
> 
> -- Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
security-services-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: security-services-help@lists.oasis-
> open.org