[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
Scott, 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]