On Tue, Mar 07, 2006 at 06:28:29PM -0800, Hallam-Baker,
Phillip wrote:
> > This is implicitly conceding that there won't be
a single,
> > global, exclusive federation.
>
> No, it is recognizing that this is what DNS already
does.
You lost me here. I must be missing something.
> I think we could easily build and deploy the scheme
this year.
The DNS SRV thing? Maybe. Where's the proposal? I'd
like to review it.
> > Unnecessary snarking. I don't see you proposing
good
> > abstractions here, and that's what matters here
and now.
>
> My point was that I know how to do abstractions, been
there, done that. SAML
> provides a real pretty solution to the whole scheme and
you can just drop in
> anything you like.
>
> I think that there is something missing here, a piece
of critical glue that
> has been left out.
Well, yes. SAML1.0 specifically did not define credentials,
authentication, key exchange... SAML2.0 doesn't either,
but adds items
needed to build them.
The GSS-API has too simple a notion of naming and
authorization (but
we're fixing this).
Standard ways of doing authentication, SAML-style identity
description
and session protection have weak cryptographic binding.
Mechanism availability for the various frameworks varies,
not due to
applicability issues but to historical ones (mainly that
someone didn't
do the work). So applications and frameworks tend to get
matched up
according to mechanism availability and credentials
infrastructures
available to a subset of an application community rather
than according
to framework applicability to the application. Users
shouldn't have to
deploy authentication infrastructures to satisfy the whims
of
application designers; application designers shouldn't have
to so
constrain their customers' environments due to non-uniform
authentication mechanism availability.
Yes, there's work to do. The issue I have with what
you're saying is
that you're saying we should start from scratch. Well,
looking at
XMLenc, for example, or XML and FastInfoset, for another,
makes me think
that starting from scratch is not necessarily a good idea.
Besides, we
have specifications and running code that would be easier to
extend than
to re-write.
The DNS SRV thing is another story -- I see that as an
out-of-band ID
selection helper, and that seems like a potentially good
thing to me,
provided we get it right. But that still leaves us with the
problems
described above.
Nico
--
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth osafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth
|