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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On >Behalf Of Sam Hartman >Sent: 13 February, 2009 00:40 >To: Josh Howlett >Cc: Melinda Shore; Hannes Tschofenig; tls@xxxxxxxx; ietf@xxxxxxxx >Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 > >>>>>> "Josh" == Josh Howlett <Josh.Howlett@xxxxxx> 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@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf