Hi Sam,
I am aware of some of the authorization mechanisms used in Kerberos (e.g.,
those introduced by Microsoft).
The issue here is a bit different, particularly on the Internet (in
comparison to the pure enterprise space).
We see a good deal of SSO solutions being deployed. To provide incremental
deployment the protocol designers have written their specs in such a way
that they do not require end host modifications. It turned out that this is
a fairly good idea to find excitement in the industry. It seems that end
host changes (even if they are only in the browser) aren't so easy. Many
other solutions are theoretically possible to solve the WebSSO problem when
you assume end host modifications are possible.
Now, the question (for me) is why someone should deploy a new technique that
requires end host modifications when they can get a similar result with
already widely deployed mechanisms. (Not speaking about the OpenID being
fairly popular on the Internet due to it's simple deployment model.) To
answer this question, I believe, one has to start with a particular problem
/ usage scenario.
I don't want to prevent anyone from standardizing (or even implementing) new
authorization extensions for TLS but all the discussions we see about the
IPRs are IMHO a bit over the top. I have a hard time seeing the widespread
deployment in front of me. I could be wrong -- we will see in a few years.
Ciao
Hannes
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Sam Hartman
Sent: 13 February, 2009 00:40
To: Josh Howlett
Cc: Melinda Shore; Hannes Tschofenig; tls(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
"Josh" == Josh Howlett <Josh(_dot_)Howlett(_at_)ja(_dot_)net> writes:
Josh> I have a long list of applications, collected from within
Josh> this community, with which they would like to use SAML-based
Josh> authorisation; and it seems to me that the ability for
Josh> application protocols to share a common mechanism for
Josh> expressing authorisation would mitigate or perhaps even
Josh> avoid the need to make application-specific authorisation
Josh> extensions.
The Kerberos community has many years of experience that
within an infrastructure, carrying authorizations in-band has
been useful and has reduced the effort required to fit an
application into a larger infrastructure. Sometimes it
reduces implementation cost in that sometimes libraries can
automatically handle some aspects of authorization. Mor
often, it reduces the cost of specifying a protocol or
adapting a protocol that was not intended to work within a
given infrastructure to working within the infrastructure. In
many cases, authorization handling becomes a matter for client
libraries and the server implementation, requiring little if
any effort from the client application or any changes to the
client->server protocol.
As a result, it becomes significantly easier to expand the
authorization system. To a large extent, it becomes a matter
of updating the infrastructure, and updating only one side of
the application. That is a huge savings in deployment and
software engineering complexity.
I would expect that SAML infrastructures could see similar benefits.
For these reasons I support the publication of a standard in
this space. I don't object to this work going to the TLS
working group provided that
1) it is within their current charter
2) They commit to do the work and have sufficient energy to
move it forward quickly.
I do object to moving the discussion of whether to solve this
problem to the TLS working group. I don't think that is the
right forum: the TLS working group does not collect the people
who would benefit from this work.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf