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


Subject: RE: [security-services] SAML core editors: an item to put into do c


On Tue, 25 Dec 2001, Scott Cantor wrote:

> > 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

For a comment, this approach seems quite adequate. For the CORBA
Authorization Token Layer Acquisition Service, we basically have the same
thing: a URI that leads to an IOR (corba object reference), which is a URI
in itself, to an ATLAS interface. The IOR specifies the protocol and
binding. We also include a name that is primarily used for caching tokens.

For a question in this approach: What is the "Name" used for? What format
is it in? If you say that the name is used for authentication, say for
SSL, does that mean the serviced behind the URI should only respond with
that identity?

Who is the authority that vouches for that authority identity?

Cheers,
-Polar

> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC