[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] SAML core editors: an item to put into do c
> I understand the intent of this extension but I would > like to point out that this has not actually been > voted on for inclusion in the document. In the interest of getting a final answer, I support Simon's attempt to trigger a vote by asking for its inclusion. ;-) > Here are some questions: what does it mean to have > a URI included in an assertion? Does it mean that > the URI implements a generic SAML responder? > Or is it the case that the URI implements a SAML > query-response service as embodied in a specified > SAML binding? I can't speak for Simon, but my working schema for Shibboleth right now includes a data triple of attributes to fully specify an authority: Name: the named identity of the authority (for authentication) Protocol: a URI identifying the protocol (eg. SAML-SOAP-HTTPS) Binding: a protocol-specific string addressing the authority Personally, I think that's both necessary and sufficient (with the exception that if you did want to identify the authority "type", you'd need that as well). In Simon's proposal, the name is implied by the binding string (eg. the hostname) and the protocol is presumably the only one currently defined (SAML over SOAP over HTTP(s)). Assuming this were adopted as is, a subsequent schema revision could add more attributes (either optional or defaulted) without breaking assertions. > If we are basically dealing with URIs that act as > a SAML responder, why do we need to differentiate > between three types of "AuthorityKind" ? This might be relevant or useful if conformance is defined in terms of the type of assertions returned by a conforming implementation, maybe? -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC