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

From: Alfred Hönes <[email-masked]>
Date: Thu, 12 Feb 2009 01:02:03 +0100 (MEZ)

At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson  wrote:

>                                                       ...  And as
> programmer and developer, I will probably have some non-patented
> alternatives to present.
>
>               --Dean

Dean,
that's really laudable progress, leading back to technical discussion
of possible alternative solutions.
Please indeed prepare such I-D as soon as feasible.

I heartly invite other interested parties as well to submit their
proposals to the TLS WG, and I hereby explicitely would like to
address those many folks that newly started being interested in
IETF work in general and further development and application of
TLS in particular.

In order to make life easier for all participants,
I suggest to start with streamlined draft names like
draft-<author>-tlz-authz-<xxx>-00 .

The WG should be able to perform an unprejudized discussion
of alternative proposals before it comes to determine consensus
whether there is enough interest and support to warrant adopting
'TLS Authorization' as a new work item, and if so, which
draft(s) to base the WG project on.

I personally promise to review sound draft proposals in time
before such WG decision (perhaps not initial -00 versions,
only enough elaborate refined versions).

One immediate question to the group and the respective author:

Draft-housley-tls-authz-extns only defines a framework, and
according to the past exegesis of the imprecise IPR statements
under discussion, only the application of that framework to
specific use cases might be encumbered by these claims.
However, the recent I-D, draft-keromytis-tls-authz-keynote-01,
together with a supporting sibling document,
draft-keromytis-keynote-x509-01 (both still rough and lacking
important details), defines a concrete instantiation of that
framework.
In how far is that instantiation encumbered by these IPR claims?
Is it burdened with other patent claims?

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Thu, 12 Feb 2009 04:20:53 -0500

Alfred,
neither of the cited KeyNote drafts (nor the KeyNote system itself) is  
patent-encumbered. However, I admit to not (yet) having paid close  
attention to the details of the IPR issues around tls-authz-extns  
itself and their potential impact to tls-authz-keynote.

I have started draft-keromytis-keynote-x509-01 through the RFC- 
fication process (currently discussing with a reviewer), since it does  
not depend on authz (or any other pending work in any WG). I have been  
waiting for tls-authz-extns to go through the process before I start  
with draft-keromytis-tls-authz-keynote-01. I invite every interested  
party to send me comments. You may find it useful to first read RFCs  
2704 (at least the first few sections) and 2792.
Best,
-Angelos

On Feb 11, 2009, at 7:02 PM, Alfred HÎnes wrote:

>  Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 20:16:43 +0200

The main issue I have been struggeling with these authorization extensions
inside TLS is that they happen at the wrong layer. 

Today, we see similar functionality being deployed at higher layers. I doubt
that a standardized authorization mechanism inside TLS will have a lot of
impact. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Angelos D. Keromytis
>Sent: 12 February, 2009 11:21
>To: Alfred HÎnes
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 
>
>Alfred,
>neither of the cited KeyNote drafts (nor the KeyNote system 
>itself) is patent-encumbered. However, I admit to not (yet) 
>having paid close attention to the details of the IPR issues 
>around tls-authz-extns itself and their potential impact to 
>tls-authz-keynote.
>
>I have started draft-keromytis-keynote-x509-01 through the 
>RFC- fication process (currently discussing with a reviewer), 
>since it does not depend on authz (or any other pending work 
>in any WG). I have been waiting for tls-authz-extns to go 
>through the process before I start with 
>draft-keromytis-tls-authz-keynote-01. I invite every 
>interested party to send me comments. You may find it useful 
>to first read RFCs
>> address those many folks that newly started being interested in IETF 
>> work in general and further development and application of TLS in 
>> particular.
>>
>> In order to make life easier for all participants, I suggest 
>to start 
>> with streamlined draft names like draft-<author>-tlz-authz-<xxx>-00 .
>>
>> The WG should be able to perform an unprejudized discussion of 
>> alternative proposals before it comes to determine consensus whether 
>> there is enough interest and support to warrant adopting 'TLS 
>> Authorization' as a new work item, and if so, which
>> I personally promise to review sound draft proposals in time before 
>> such WG decision (perhaps not initial -00 versions, only enough 
>> elaborate refined versions).
>>
>>
>according 
>> to the past exegesis of the imprecise IPR statements under 
>discussion, 
>> only the application of that framework to specific use cases 
>might be 
>> encumbered by these claims.
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Feb 2009 14:07:03 -0500

> inside TLS is that they happen at the wrong layer.

I don't know about that - I think it really depends on
how the TLS session is being used, etc.  I think that
the more ability traffic has to describe itself the better,
and that there are some non-trivial advantages to carrying
authorizations in-band.

Melinda

---

From: Dean Anderson <[email-masked]>
Date: Thu, 12 Feb 2009 14:15:29 -0500 (EST)

Hi, 

I don't think it is true that these TLS-Authz-dependent drafts are not
encumbered. They are merely not specifically mentioned, and I didn't
even know about them until just now.  The patent covers broad categories
of authorizations, and it would seem that any framework for
authorization using TLS-authz, as these documents are, must necessarilly
fall into one of those categories for which a patent license is required
in order to use the TLS-authz drafts.

I think these drafts should wait until TLS-authz succeeds in being
accepted, particularly since it is very unlikely that TLS-authz will
ever be accepted or approved by any process involving community
consensus.  I think the significant opposition that has been 
demonstrated in the third and forth last calls demonstrates that this 
draft will not be approved.  I note that there were even more 
opposition in the forth last call than in the third last call. 

I think the combination of misconduct and patent encumbrance ensures
that a large part of the community will continue to oppose this
standard. Opposition is growing, not fading. The misconduct continues
with the recent destruction (spoliation) of evidence in removing IPR
765. IPR 765 was the first disclosure by Redphone of the patent and
license terms offered by Redphone.  While Alvestrand and the IESG
previously assured the community that IPR disclosures would never be
removed except for 'spam' and 'fiddling with the database', they reneged
on their promises and removed IPR 765 anyway. IPR 765 reflected poorly
on Redphone, and has been used to show their malfeasance. Destroying
such evidence as IPR 765 is legal misconduct.  A complaint was made to
the IESG and the IETF Lawyer Jorge Contreras, but was ignored. Contreras
also hasn't responded to email. The IESG has also recently stated to me
that it not asked for legal advice in complaints involving their
compliance with the law. This is all rather odd, and suggests that they
know that their actions violate the law and violate their duties and are
trying to avoid involving Contreras in unlawful acts.

But, anyway, these dependent documents should also have IPR disclosures
that reference the disclosures in TLS-authz, particularly IPR 765 and
IPR 1026.

			--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 12 Feb 2009 11:58:40 -0800

> in order to use the TLS-authz drafts.

While it's probably too early to make decisions based on it, the courts
have basically rendered software unpatentable.  The new test for patent-
ability requires either 1) a physical transformation of some sort, or
2) restriction to a specific machine (and a general purpose computer does
not apply).  This would imply that any pure software algorithm running on
a general purpose computer can not be patented.

Note that I am not a lawyer and am not attempting to provide legal advice.

Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Feb 2009 17:39:48 -0500

>>>>> "Josh" == Josh Howlett <[email-masked]> 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.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Feb 2009 21:19:36 +0200

Hi Melinda, 

>> The main issue I have been struggeling with these authorization 
>> extensions inside TLS is that they happen at the wrong layer.
>
>I don't know about that - I think it really depends on how the 
>TLS session is being used, etc.

Sure. A good example of SAML usage is WebSSO. Using SAML in that usage
scenario requires a bit more than just carrying around the SAML assertion. 

>  I think that the more ability 
>traffic has to describe itself the better,

Not sure I understand that. 

> and that there are 
>some non-trivial advantages to carrying authorizations in-band.
Namely... 

Ciao
Hannes

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 12 Feb 2009 21:47:32 -0000

Hannes wrote:
> Melinda wrote:

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

(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.)

Binding authorisation to TLS, as suggested by this document, is one
approach that would satisfy the 'common mechanism' requirement indicated
previously.

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

---

From: Dean Anderson <[email-masked]>
Date: Thu, 12 Feb 2009 18:19:47 -0500 (EST)

Hi Michael,

You're referring to In Re Bilski, decided in October. This decision was
certainly in our favor, and it shows we are winning in a significant
theatre of the war on software patents, but it doesn't make all software
unpatentable. Not yet.  Redphone's patent is still being examined,
hasn't been rejected, and appears to be going forward.  We have to base
our actions and decisions on the expectation that the patent will be
granted, as we have no guarentee that it won't beg granted.

		--Dean

On Thu, 12 Feb 2009, Michael D'Errico wrote:

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Feb 2009 00:28:28 +0100

>> some non-trivial advantages to carrying authorizations in-band.
Independance between payload and security measures.
Piggybagging information on lower layers is a very old concept.

https was successful over shttp.

I think the patent is made by trolls. There seems to be
lots of evidence of prior art. sending an OSCP
response as part of the TLS session setup
is a standard, where is the difference?

The current hacks to carry SAML assertion using additional
http connection is inefficient, mildly speaking. 

The authz has technical problems.
I encourage the TLS working group members to
seriously treat the issue.

Peter Sylvester

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Feb 2009 00:50:34 +0200

Hi Josh, 

>I don't wish to speak for Melinda, but this is a view shared 
>by many within my own community.
>

Interesting. Any interest to share it with us?

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

Furthermore, working on SIP SAML I noticed the problems when you go down to
specific solutions scenarios.

>(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. 
The reason for the success of these IdM solutions, particularly OpenID.

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

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
>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 13 Feb 2009 09:07:19 -0500

Sam,

Is your suggestion that there is a better existing working group, or to
establish one through the BOF process?  We are interested both in
leveraging at the application layer an authentication context
established by TLS between A and B (as opposed to relying on an SSO
assertion from C to B that C has authenticated A), and in carrying A's
authorization-related attributes (pre-signed by C) within that context.

I was aware of this discussion only because it came to TLS, and would
welcome a pointer to the right forum.

-----Original Message-----
From: Sam Hartman
Sent: Thursday, February 12, 2009 5:40 PM
To: Josh Howlett
Cc: Hannes Tschofenig; [email-masked]; [email-masked]
Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

[...]

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.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Feb 2009 09:38:29 -0500

> even avoid the need to make application-specific authorisation

Right, and to be more specific about it, the kinds of
things that we're talking about include reducing retained
state on devices during the authorization process by
eliminating queries, reducing the problems around service
discovery and topology, and I tend to think that there
are some cross-domain advantages, as well.  There are
fate-sharing considerations, where the authorizations
aren't held by devices that don't need them, they're not
delivered if the traffic isn't delivered, and if the
traffic is delivered the authorizations are delivered.
So, I think that in addition to some issues specific
to authorization problems there are some advantages
around traditional networking considerations.

Melinda

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 13 Feb 2009 09:40:46 -0000

Hi Hans,

> 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, ...).

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

> ... a reasonable transition plan, in my view.

Sure.

> The reason for the success of these IdM solutions, 

(Well - OpenID has been a flop in my opinion. It has its uses, but not
very interesting ones. But I digress...)

> >approach that would satisfy the 'common mechanism'

I have no answers; I'm still trying to figure out what the questions are
:-/

josh.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 13 Feb 2009 10:52:03 -0500

I too would like to figure out what the questions are.  The draft is not
about carrying "authorizations" in TLS, or that "The main issue with
these authorization extensions inside TLS is that they happen at the
wrong layer" as stated by Hannes Tschofenig.

Authorization happens at the application layer.  Data is transported at
the transport layer.  The draft is about carrying data (SAML assertions,
attribute certificates, or pointers thereto) that can be used or ignored
by applications when those applications make authorization decisions.

What application domain is involved when I hand someone a certificate
(driver's license) stating that I was born on MMDDYYYY?  It only becomes
part of an application domain when the "someone" is instantiated as a
store clerk who needs to decide whether I am authorized to buy
cigarettes or liquor.  The clerk is doing the authorization, not the
certificate.

Since Mr. Anderson is so exercised about the word "authorization" in the
name of the I-D, perhaps it should be renamed
"draft-ietf-tls-attributes-07".  That would avoid the IPR issues
entirely, since one can transport an attribute certificate without ever
using it to authorize anything.

-----Original Message-----
From: Josh Howlett

[...]

[...]

---

From: Dean Anderson <[email-masked]>
Date: Fri, 13 Feb 2009 12:56:19 -0500 (EST)

Hi David,

There is nothing in the word "authorization" that bothers me. What
bothers me is the patent itself, the patent non-disclosure, the conflict
of interest in having the IETF chair selling his position, the conflict
of interest in Housley's business partner Polk advance Housley's draft
after repeated massive rejections of last calls, and the destruction of
evidence removing IPR disclosures.  Working in the government, you must
have some appreciation of the propriety of such acts.

But otherwise than that, I'm totally fine with authorization as a
notion and a name.

It is a done deal that the TLS WG will take on this work?  Or will it
pass on it?  Rescorla and Salowey weren't exactly clear that the WG
would take it.  I'll start working on a draft that doesn't violate the
patent, if the WG is going to work on it.

		--Dean

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 13 Feb 2009 13:57:00 -0500

What bothers me is the assertion that a specification for using TLS to
carry information (attributes) about entities could possibly infringe on
any patent related to authorization.  Sending an X.509 attribute
certificate containing my date of birth over TLS says precisely nothing
about what any application might authorize me to do.  And even without
the client_authz and server_authz extensions, the TLS protocol itself
would carry the same information about me if the DOB attribute were
included in my X.509 public key certificate.  Does that mean TLS should
be abandoned?

The assertion of encumbrance is as ridiculous as saying:
1) http can be (and has been) used to transport copyrighted music
2) therefore RFC 2616 should never have been worked on, or approved by,
the IETF

I reject that assertion.

-----Original Message-----
From: Dean Anderson [mailto:[email-masked]] 
Sent: Friday, February 13, 2009 12:56 PM
To: Kemp, David P.
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Hi David,

		--Dean

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Feb 2009 07:06:04 -0800

At Thu, 12 Feb 2009 11:58:40 -0800,
> Note that I am not a lawyer and am not attempting to provide legal advice.

Folks,

It's fine to discuss the Redphone patents specifically in the
context of whether TLS should adopt work in this area 
(though note that no such work has been proposed in TLS 
at this time). However, the general question of the
patentability of software is not relevant to the TLS WG
and should be discussed elsewhere.

-Ekr

[As WG Chair]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 14 Feb 2009 22:59:17 +0200

Hi Josh, 

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

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

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

>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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 14 Feb 2009 22:59:12 +0200

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

>Behalf Of Sam Hartman
>Sent: 13 February, 2009 00:40
>To: Josh Howlett
>Cc: Melinda Shore; Hannes Tschofenig; [email-masked]; [email-masked]
>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.
>
>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.
>
>
>
>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
>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.
>