[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