RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

["Hannes Tschofenig" <[e-mail]>]

Hi Josh, 

>Hi Hans,
>
>> >Hannes wrote:
>> >> Melinda wrote:
>> >> >
>> >> > and that there are
>> >> > some non-trivial advantages to carrying authorizations in-band.
>> >> Namely... 
>> >
>> >I don't wish to speak for Melinda, but this is a view 
>shared by many 
>> >within my own community.
>> >
>> >I have a long list of applications, collected from within this 
>> >community, with which they would like to use SAML-based
>> authorisation;
>> 
>> Interesting. Any interest to share it with us?
>
>I'm in the process of trying to flesh it out at the moment, in 
>a collaboration with some of the communities concerned, so 
>that we can articulate some concrete use-cases. At the moment 
>the list covers pretty much everything that is presently used 
>in an Inter-Institutional context (AFS, SSH, VNC, RDP, SIP, 
>SMTP, NEA, ...).


Looking forward to see more about it. 

>
>> >and it seems to me that the ability for application
>> protocols to share
>> >a common mechanism for expressing authorisation would mitigate or 
>> >perhaps even avoid the need to make application-specific
>> authorisation
>> >extensions.
>> 
>> My experience: authorization is often related to the specific 
>> application domain.
>
>I agree insofar as 'authorisation' is often an exercise in 
>making statements using semantics that are specific to 
>application domains, but I don't believe it follows that the 
>syntactical and transport elements (that support the semantic 
>expression) also need to be specific to the application domain.
>
>> Furthermore, working on SIP SAML I noticed the problems when you go 
>> down to specific solutions scenarios.
>
>Can you expand?
Look at http://tools.ietf.org/html/draft-ietf-sip-saml-05. 
We started with a specific problem in mind, described in RFC 4484. 
There are obviously different design approaches one can take and SIP is a
complex protocol and hence there are not always point-to-point interactions
making it somewhat difficult to provide similar functionality at a lower
layer. With specific details about the actual authorization statements we
also had a hard time. We published a few specifications (all expired in the
meanwhile) that discussed more or less complex attributes. Examples: 
http://tools.ietf.org/html/draft-schubert-sipping-saml-cpc-02
http://tools.ietf.org/html/draft-schwartz-sipping-spit-saml-01
http://tools.ietf.org/html/draft-jennings-sipping-pay-06

Since you mentioned SIP as one of the usage scenarios in the paragraph above
you might have had other use cases in mind. 

For many of the protocols and usage scenarios it may not even be so obvious
what SAML can actually give you (not even touching the subject of where to
put the SAML assertions).

My fear about SAML in TLS was a history like the following one: 
* Hmmm. SAML becomes popular. We should put it in every protocol. 
* There isn't an extension for TLS defined yet. Let's do it. 
* Now, let's search for the problems it could solve. 


>> >(The fact that SAML-based Web SSO uses SAML that is bound to the 
>> >application-layer is, I believe, only an artifact of a
>> requirement to
>> >avoid modifying contemporary Web browsers and I don't think 
>it is an 
>> >approach that would necessarily be desirable for the general case.)
>> 
>> ... a reasonable transition plan, in my view.
>
>Sure.
>
>> The reason for the success of these IdM solutions, particularly 
>> OpenID.
>
>(Well - OpenID has been a flop in my opinion. It has its uses, 
>but not very interesting ones. But I digress...)

There are different camps, without doubt. Just to point you to one other
opinion -- Jeff Schiller's webblog I recently discovered:
http://qyv.net/jisblog/2007/05/08/identity-on-the-internet/



>
>> >Binding authorisation to TLS, as suggested by this document, is one 
>> >approach that would satisfy the 'common mechanism'
>> >requirement indicated previously.
>> 
>> Looking forward to see your solutions.
>
>I have no answers; I'm still trying to figure out what the 
>questions are :-/

I was referring to the usage scenarios you are working on. 

Btw, I am not suggesting that folks shouldn't spend their time on usage of
authorization in TLS. I am more looking for some of the background of the
work as it often not too obvious from the pure specification. Your pointer
to http://kerberos.org/software/kerbweb.pdf is certainly helpful for a
number of folks -- I have learned it already from Jeff. 

Ciao
Hannes

>
>josh.
>
>JANET(UK) is a trading name of The JNT Association, a company 
>limited by guarantee which is registered in England under No. 
>2881024 and whose Registered Office is at Lumen House, Library 
>Avenue, Harwell Science and Innovation Campus, Didcot, 
>Oxfordshire. OX11 0SG
>