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

Subject: RE: [security-services] Editorial Update to Section 3.3 of confor mance


The relationship between Section 8.4 (core) and
Section 3.3 (conformance) requires clarification
because of (example) text of the form:

URI: urn:oasis:names:tc:SAML:2.0:consent:obtained

Indicates that a principalís consent has been obtained
by the issuer of the message.

Your position seems to be that a conformant SAML
generator should be able to include "obtained" in any
message thru a configuration setting. Ultimately, this
would lead to conformance tests in which SAML
generators are required to insert any of the constants
into messages. And at the same time there would be no
requirement to test whether the implementation
provides some means of obtaining consent. 

Is this the position that is broadly acceptable? If
so, we should have some text in Section 3.3 of
conformance that reflects this understanding.

- prateek

--- Scott Cantor <cantor.2@osu.edu> wrote:

> > - I was thinking at Obtained is a super class 
> > (generalization) of Prior, Implicit, and Explicit?
> But this 
> > isn't a conformance question rather a spec
> interpretation.
> Yes, it's a superset.
> > - It is not clear if consent can be obtained
> generally for 
> > Saml 2.0 usage (i.e., is that sufficient), or do
> your 
> > comments apply to every requesting protocol (i.e.,
> you need 
> > to have a way to obtain consent for authn request,
> for 
> > logout, for fed id termination, for name id
> mapping, etc...). 
> > Sounds like consent has to apply to all requesting
> protocols, 
> > therefore, a conformant implementation has to be
> able to ask 
> > for consent each time. 
> It's per message, but I think you're missing the
> point here (both of you).
> The SAML 2.0 implementation's job is not to ask for
> consent, but to reflect
> whether consent was obtained. If your implementation
> wants to directly
> interact with the user to do that, that's up to you,
> but a conforming
> implementation just needs a per-request knob to
> indicate the value to use.
> Which might be set at deploy-time to
> "unspecified"/omit.
> -- Scott

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