RE: ISSUE:[UC-12-03:EncryptionMethod]

[Irving Reid <Irving.Reid@baltimore.com>]

I agree that we could make much finer distinctions about how and when we
require encryption. I was hoping we wouldn't need to, because I thought we
had some clear guidance from the conference call and also from Strawman 3.

In Strawman 3, Requirements, Non-Goals, the first non-goal is that SAML will
not propose any new cryptographic technologies. It's not clear whether that
means cryptographic authentication technologies, or ways of encrypting SAML
messages.

That said, I firmly believe that we should _not_ define our own format for
encrypting SAML messages, and I admit that the choices in my ballot were
biased toward that alternative.

If people prefer the level of detail David proposed in his message, I don't
have a problem with changing the issue text and ballot.

 - irving -

> From: Orchard, David [mailto:dorchard@jamcracker.com]
> Subject: ISSUE:[UC-12-03:EncryptionMethod]
> 
> This doesn't seem quite right to me.  Aren't there really 2 sets of
> questions that are asked at different points in time?
> 
> My abbreviated suggestions:
> 
> 1) Use of Encryption now in the spec:
> a) SAML will define it's own format for encryption
> b) SAML shall use XML DSIG
> c) SAML shall define nothing for encryption
> d) SAML shall use some other option for encryption
> e) SAML shall use XMLE, and it will wait until XMLE is ready 
> before SAML
> ships
> 
> 2) Use of Encryption in the future (assuming cases a-d 
> chosen), where future
> is defined as XMLE at Recommendation phase
> a) SAML shall continue it's current encryption
> b) SAML shall use XMLE.  
> 
> Vote #2 seems to happen when XMLE ships.  Vote #1 really says 
> we either do
> something non XMLE for now or we wait for XMLE.