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] | [Elist Home]


Subject: RE: Minutes of 8 May 2001 Focus subcommittee telecon



>>
>>1. Do we need to care about privacy in SAML (in particular for names)?
>>[Yes.]
>>

There has been a fair amount of discussion on privacy in the use-case
group.


>>2. Do we assume that SAML will specify a general method for applying 
>>integrity and encryption (XMLDSIG & XMLENC, when its done) to SAML 
>>assertions and messages?
>>[Yes, but maybe not "complete" for v1.0 though, esp. 
>>encryption likely to 
>>be v1.next due to W3C/OASIS timing, meanwhile use ssl for SAML pipes.]
>>
>>3. Should we split out Name/Realm as above?
>>[Yes.]
>>

  The S2ML Specification included an (optional) element <domain> 
  for exactly this reason.

	<login>
         <name>XXXX</name>
         <password>ZZZZ</name>
         <domain>PPPPPP</domain>
     <login>

  
  We avoided the name <Realm> as it is an extremely overloaded name. I have
to say
our final choice wasn't a whole lot better.

>>
>>btw: who's doing the general integrity/encryption thing for 
>>assertions, 
>>since I assume we will need at least (partial) assertion signing for 
>>v1.0?
>>

Most of this material will end up in the bindings section which
is now picking up momentum. I think the general approach will be 
to distinguish between "secret" artifacts (indx refs, passwords, ...) vs.
others. Pieces of SAML that contain secret artfs MUST be exchanged over
encrypted
channels, or use some other forms of data encryption for privacy 
protection. 

Signing will be addressed in a parallel fashion; I have yet to call this
out.


- prateek



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


Powered by eList eXpress LLC