OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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


Subject: JeffH's vote for 12


FWIW: I share Maryann Hondo's concerns about how these items are stated. I also
think we're yet again getting a ways into design. But here are my votes
anyways, fwiw. 


> ISSUE:[UC-12-01:Confidentiality]
> 
> Choose one of the following:
> 
> a) Confidentiality and integrity (C&I) protection of SAML messages is
> required.
> 
> b) C&I protection is optional (but encouraged).
> 
> c) C&I protection is unsupported.



I vote for "a".



> ----------------------------------------------------------------------------
> 
> ISSUE: [UC-12-02:ConfidentialMessages]
> 
> Choose one of the following:
> 
> a) C&I protection shall be specified as part of the SAML message format.
> 
> b) C&I protection shall be specified as part of each protocol binding.
> Each binding must include a description of how the confidentiality and
> integrity of SAML messages can be protected within that binding. Examples:
> S/MIME for MIME, HTTP/S for HTTP.
> 
> c) C&I protection shall be specified both within the SAML message format and
> within protocol bindings. Deployments can choose the appropriate solution.
> For example, SAML messages within S/MIME documents do not need message-level
> C&I protection, while SAML messages passed as HTTP cookies do.



I vote for "c".



> ----------------------------------------------------------------------------
> 
> ISSUE:[UC-12-03:EncryptionNow]
> 
> If C&I protection is included in the SAML message format, how should the
> protection be provided now (that is, before XML Encryption is available)?
> Choose one:
> 
> a) Integrity protection shall use XML DSIG, and confidentiality
> protection shall not be available.
> 
> b) SAML shall define its own format for message encryption or use
> some existing encryption method other than XML Encryption.
> 
> c) SAML shall not be published until XML Encryption is a published
> standard.



I vote for "c". 

rationale: actually, I think all three options tend to be unworkable/untenable
in their own ways. 

I think "a" is a non-starter, especially as-stated.

I strongly believe we don't have the time nor the will to undertake "b", fwiw. 



> ----------------------------------------------------------------------------
> 
> ISSUE:[UC-12-04:EncryptionLater]
> 
> When the XML Encryption standard is published:
> 
> a) SAML shall continue to use the C&I method specified in
> ISSUE:[UC-12-03:EncryptionNow].
> 
> b) SAML shall be revised to use XML Encryption.
> 

Abstain. 

We can't really make either statement. With "a", is it restricted to SAML 1.0,
or does it mean SAML X.X? I agree with DaveO about "b". 


JeffH


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


Powered by eList eXpress LLC