From eve@xmlgrrl.com Fri Oct 1 06:38:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4563A6F15 for ; Fri, 1 Oct 2010 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URIBL_RHS_DOB=1.083, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEoChg9dYie2 for ; Fri, 1 Oct 2010 06:38:27 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id DEB7A3A6F16 for ; Fri, 1 Oct 2010 06:37:54 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o91DcbDm019773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Oct 2010 06:38:38 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-32-542956409 From: Eve Maler In-Reply-To: Date: Fri, 1 Oct 2010 06:38:37 -0700 Message-Id: <4AE0093F-E427-446B-8BB3-11D57EC89032@xmlgrrl.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Dirk Balfanz X-Mailer: Apple Mail (2.1081) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:38:30 -0000 --Apple-Mail-32-542956409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Glad to see this being worked on here. I wanted to add a few = requirements (and maybe, just maybe, a bit of a solution) into the mix. As you may recall, in the UMA group we've been working on what we called = a "Claims 2.0" spec (all UMA specs -- and some OAuth-related specs too = -- are linked off of = http://kantarainitiative.org/confluence/display/uma/Working+Drafts ). UMA inserts claims into a slightly different place in the proceedings = than core OAuth; the authz server can demand claims from a client before = issuing an access token, so that the resource server doesn't have to = implement sophisticated policy decision-making logic when it interprets = claims (classic PEP/PDP separation). But I think the "claims" we're = talking about are essentially the same. The Claims 2.0 spec contains both a simple JSON-based sub-protocol for = requesting and supplying claims, and an (unfinished) claims format. I = think we'd be happy to simply point to an existing claims format if it = met our needs, and then define our very thin protocol around that. (If = you look at our short spec called Simple Access Authorization Claims, = you'll see some use cases for the protocol piece.) As long as the claims format spec is JSON-based, and allows each claim = to be individually signed for third-party issuer authentication, and = allows the claim type to be a URL, that's a big chunk of our = requirements. Meeting our claims communication protocol needs is = another, but I think it *should* be easy to do. We'll do an analysis on = our end to highlight other requirements/use cases and bring them here. Regarding discovery, the core UMA spec specifies how an authz = server/manager can declare its supported claim formats in XRD for a = resource server/host (and presumably other parties) to discover, and we = might require a short list of such formats for UMA compliance. Our core = spec assumes that the OAuth Dynamic Client Registration I-D we = contributed (linked off our Working Drafts page), or similar, would be = used for discovery of such information. If specific XRD (or JRD) = discovery info were "sedimented" into such a spec at the OAuth table, = particularly if it specified a suitable OAuth core compliance set, we'd = happily point to it. Eve On 28 Sep 2010, at 10:23 AM, Dirk Balfanz wrote: > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones = wrote: > Dirk and I both posted JSON Token drafts on Thursday. They are at = http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html = (which I=92ll refer to as Dirk=92s draft) and = http://self-issued.info/docs/draft-goland-json-web-token-00.html (which = I=92ll refer to as JWT). This note points out some of the differences = (and commonalities) in the interest of building consensus towards a = unified approach. >=20 > =20 > Commonalities: >=20 > =B7 Both have ways of expressing the signature algorithm, = token issuer, token expiration time, and intended audience. >=20 > =B7 Both use a form of base64url encoding of the JSON claim = data. >=20 > =B7 Both require support for the HMAC SHA-256 signature = algorithm, and describe how to sign with RSA SHA-256 as well. >=20 > =20 > Differences: >=20 > =B7 Dirk=92s draft uses a base64url encoding that may include = one or two =91=3D=92 pad characters. The JWT draft uses base64url = encoding without padding. >=20 > =B7 JWT uses shorter claim names in the interest of brevity = (=93iss=94, =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94= , and =93audience=94). >=20 > =B7 JWT also describes how to sign with ECDSA SHA-256, plus = HMAC, RSA, and ECDSA with longer key lengths. >=20 > =B7 Dirk=92s tokens must be signed, whereas signing JWTs is = optional. >=20 > =B7 Dirk=92s draft provides for a key_id parameter and a means = of serializing keys. >=20 > =B7 Dirk=92s draft utilizes a Magic Signatures envelope, = whereas the only =93envelope=94 component of a JWT is the encoded = signature. >=20 > =B7 Dirk=92s draft proposes that a particular discovery = mechanism be used with JSON tokens. >=20 > =20 > Let me tackle the differences one at a time, in hopes of driving = towards a consensus position. >=20 >=20 > Hi there - thanks for writhing this up. Comments below: > =B7 To pad or not to pad: The =91=3D=92 pad characters add = length, are not URL-safe (and therefore must be escaped when used in = URLs, adding more length), and add no information. Therefore, I would = propose that we agree not to use padding (as permitted by RFC 4648, = Section 5), especially since a no-padding implementation is trivial, as = shown in JWT Section 13. >=20 >=20 > I don't feel strongly about this, but remember John Panzer's = cautionary tales here: Apparently, padding-less encoding is not = well-supported in some frameworks, which can lead to confusion. > =20 > =B7 Claim name length: Given that a core goal of both specs is = short tokens, I would propose that we use the shorter reserved claim = names. Having short tokens is especially important when used with = mobile browsers, where URL length restrictions may be severe. (People = are always free to use longer ones in any particular application context = if they have a reason to do so.) >=20 >=20 > I don't feel strongly about this, but I think many people do want to = have more descriptive names here.=20 > =20 > =B7 Elliptic curve crypto and longer key lengths: The JWT = spec defines how to use ECC as well as HMAC and RSA. Given ECC=92s = inclusion in NSA Suite B and that it has engineering advantages over RSA = (shorter key lengths and more efficient computations), it makes sense = that any modern spec incorporating cryptography allow its use as an = option. Likewise, it makes sense for the spec to define how to use = longer key lengths on an optional basis. >=20 > So this one I do feel more strongly about: We should only include = crypto mechanisms that everybody MUST support. Otherwise, we'll have to = invent some sort of negotiation step in the protocol: "do you support = alg XYZ? No I don't, please use ABC". Let's not do that.=20 >=20 > As just one datapoint, Google would have a hard time supporting ECC, = since it's not in the Java core library. We don't use bouncycastle. > =20 > =B7 Unsigned tokens: In some application contexts, it may = make sense to send unsigned tokens if carried in a signed and/or = encrypted container or channel. Allowing for unsigned tokens means that = double signing need not occur. >=20 > That one just confuses me :-) What's the difference between OAuth = without signatures and unsigned tokens? Is the latter not just a more = complicated way of doing the former?=20 >=20 > =B7 Key identification: I agree that having means of = identifying and distributing keys are critical for to end-to-end = security of signed tokens. That=92s a separate point from whether the = key identification and distribution mechanisms should be part of the = token format specification, or treated separately. I would advocate = that it be treated separately (as was done with SWTs as well), but am = open to discussion on this point. >=20 > =B7 Discovery: Like key distribution, I believe that an = agreement on discovery mechanisms is critical to many use cases. But = like key distribution, I=92d like us to take that up in a separate = specification, rather than tightly binding the use of JSON tokens to a = particular discovery mechanism. >=20 >=20 >=20 > Here is where I'm coming from: I find the public-key versions of the = signatures much more intriguing - they allow for easier key management, = key rotation, etc. To actually reap the benefits of key rotation, = though, we need to say how to find out what the currently-used key is. = If we don't, then a lot of the potential advantage of using public keys = evaporates. I'm concerned that, lacking the discovery spec, developers = will start hard-coding keys into their servers, and we'll end up in a = situation where we can't rotate keys when Something Bad happens. >=20 > =B7 Envelope structure: Dirk=92s draft proposes that the = signed content be wrapped in a particular kind of envelope. Among other = things, this envelope can help prevent a token from being repurposed = from one context to another, by having a clear (and cryptographically = verified) declaration that =93This is a JSON token=94. I understand = this motivation and am open to discussions on how to best achieve it, = while still providing as little mechanism as possible (but no less J). >=20 > Well, you've seen my proposal on how to achieve it :-), but I'm also = open to better ways, if someone comes up with one... >=20 > Dirk. > =20 > =20 > Dirk, and others, please jump in! >=20 > =20 > -- = Mike >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail-32-542956409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://kantarainitiative.org/confluence/display/uma/Working+Drafts = ).

UMA inserts claims into a slightly different = place in the proceedings than core OAuth; the authz server can demand = claims from a client before issuing an access token, so that the = resource server doesn't have to implement sophisticated policy = decision-making logic when it interprets claims (classic PEP/PDP = separation). But I think the "claims" we're talking about are = essentially the same.

The Claims 2.0 spec = contains both a simple JSON-based sub-protocol for requesting and = supplying claims, and an (unfinished) claims format.  I think we'd = be happy to simply point to an existing claims format if it met our = needs, and then define our very thin protocol around that.  (If you = look at our short spec called Simple Access Authorization Claims, = you'll see some use cases for the protocol = piece.)

As long as the claims format spec is = JSON-based, and allows each claim to be individually signed for = third-party issuer authentication, and allows the claim type to be a = URL, that's a big chunk of our requirements. Meeting our claims = communication protocol needs is another, but I think it *should* be easy = to do. We'll do an analysis on our end to highlight other = requirements/use cases and bring them = here.

Regarding discovery, the core UMA spec = specifies how an authz server/manager can declare its supported claim = formats in XRD for a resource server/host (and presumably other parties) = to discover, and we might require a short list of such formats for UMA = compliance. Our core spec assumes that the OAuth Dynamic Client = Registration I-D we contributed (linked off our Working Drafts page), or = similar, would be used for discovery of such information. If specific = XRD (or JRD) discovery info were "sedimented" into such a spec at the = OAuth table, particularly if it specified a suitable OAuth core = compliance set, we'd happily point to it.

= Eve

On 28 Sep 2010, at 10:23 AM, Dirk Balfanz = wrote:

On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Dirk and I both posted JSON Token drafts on = Thursday.  They are at = http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I=92ll refer to as Dirk=92s draft) and http://self-issued.info/docs/draft-goland-json-web-token= -00.html (which I=92ll refer to as JWT).  This note points out = some of the differences (and commonalities) in the interest of building consensus towards a unified approach.

 

Commonalities:

=B7         Both have ways of expressing the signature = algorithm, token issuer, token expiration time, and intended = audience.

=B7         Both use a form of base64url encoding of the JSON = claim data.

=B7         Both require support for the HMAC SHA-256 signature = algorithm, and describe how to sign with RSA SHA-256 as = well.

 

Differences:

=B7         Dirk=92s draft uses a base64url encoding that may = include one or two =91=3D=92 pad characters.  The JWT draft uses = base64url encoding without padding.

=B7         JWT uses shorter claim names in the interest of = brevity (=93iss=94, =93exp=94, and =93aud=94, versus =93issuer=94, = =93not_after=94, and =93audience=94).

=B7         JWT also describes how to sign with ECDSA SHA-256, = plus HMAC, RSA, and ECDSA with longer key lengths.

=B7         Dirk=92s tokens must be signed, whereas signing = JWTs is optional.

=B7         Dirk=92s draft provides for a key_id parameter and = a means of serializing keys.

=B7         Dirk=92s draft utilizes a Magic Signatures = envelope, whereas the only =93envelope=94 component of a JWT is the = encoded signature.

=B7         Dirk=92s draft proposes that a particular discovery = mechanism be used with JSON tokens.

 

Let me = tackle the differences one at a time, in hopes of driving towards a = consensus position.


Hi = there - thanks for writhing this up. Comments below:

=B7         To pad or not to pad:  The =91=3D=92 = pad characters add length, are not URL-safe (and therefore must be = escaped when used in URLs, adding more length), and add no = information.  Therefore, I would propose that we agree not to use padding (as permitted by RFC 4648, Section 5), especially since a no-padding implementation = is trivial, as shown in JWT Section 13.


I don't feel strongly about = this, but remember John Panzer's cautionary tales here: Apparently, = padding-less encoding is not well-supported in some frameworks, which = can lead to confusion.
 

=B7         Claim name length: Given that a core goal of = both specs is short tokens, I would propose that we use the shorter = reserved claim names.  Having short tokens is especially important = when used with mobile browsers, where URL length restrictions may be severe.  (People are always free to use = longer ones in any particular application context if they have a reason = to do so.)


I don't feel = strongly about this, but I think many people do want to have more = descriptive names here. 
 

=B7         Elliptic curve crypto and longer key = lengths:  The JWT spec defines how to use ECC as well as HMAC = and RSA.  Given ECC=92s inclusion in NSA Suite B and that it has engineering = advantages over RSA (shorter key lengths and more efficient = computations), it makes sense that any modern spec incorporating = cryptography allow its use as an option.  Likewise, it makes sense for the spec to = define how to use longer key lengths on an optional = basis.

So this one I do feel more = strongly about: We should only include crypto mechanisms that everybody = MUST support. Otherwise, we'll have to invent some sort of negotiation = step in the protocol: "do you support alg XYZ? No I don't, please use = ABC". Let's not do that. 

As just one datapoint, Google would have a hard time = supporting ECC, since it's not in the Java core library. We don't use = bouncycastle.
 

=B7         Unsigned tokens:  In some application = contexts, it may make sense to send unsigned tokens if carried in a = signed and/or encrypted container or channel.  Allowing for = unsigned tokens means that double signing need not occur.

That one just confuses me :-) What's the = difference between OAuth without signatures and unsigned tokens? Is the = latter not just a more complicated way of doing the = former? 

=B7         Key identification:  I agree that = having means of identifying and distributing keys are critical for to = end-to-end security of signed tokens.  That=92s a separate point = from whether the key identification and distribution mechanisms should be part of the token format specification, or treated = separately.  I would advocate that it be treated separately (as was = done with SWTs as well), but am open to discussion on this = point.

=B7         Discovery:  Like key distribution, I = believe that an agreement on discovery mechanisms is critical to many = use cases.  But like key distribution, I=92d like us to take that = up in a separate specification, rather than tightly binding the use of JSON tokens to a particular discovery = mechanism.

Here is where I'm coming from: I find the public-key = versions of the signatures much more intriguing - they allow for easier = key management, key rotation, etc. To actually reap the benefits of key = rotation, though, we need to say how to find out what the currently-used = key is. If we don't, then a lot of the potential advantage of using = public keys evaporates. I'm concerned that, lacking the discovery spec, = developers will start hard-coding keys into their servers, and we'll end = up in a situation where we can't rotate keys when Something Bad = happens.

=B7

 

Dirk, = and others, please jump in!

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp;     -- Mike

 

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
=
+1 425 345 6756               =           http://www.twitter.com/xmlgrrl=

= --Apple-Mail-32-542956409-- From pelle@kodfabrik.se Fri Oct 1 07:41:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7011E3A6C63 for ; Fri, 1 Oct 2010 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bDbP-he20pN for ; Fri, 1 Oct 2010 07:41:22 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 813573A6C83 for ; Fri, 1 Oct 2010 07:41:22 -0700 (PDT) Received: by pvg7 with SMTP id 7so1019126pvg.31 for ; Fri, 01 Oct 2010 07:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.92.3 with SMTP id p3mr6394689wab.77.1285944130571; Fri, 01 Oct 2010 07:42:10 -0700 (PDT) Received: by 10.115.77.10 with HTTP; Fri, 1 Oct 2010 07:42:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 1 Oct 2010 16:42:10 +0200 Message-ID: From: Pelle Wessman To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00163645950a1a8f0204918f330b Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:41:24 -0000 --00163645950a1a8f0204918f330b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1, I think this sounds like a sensible path forward On Tue, Sep 28, 2010 at 8:25 AM, Eran Hammer-Lahav wro= te: > (Please take a break from the other threads and read this with an open > mind. I have tried to make this both informative and balanced.) > > > > --- IETF Process > > > > For those unfamiliar with the IETF process, we operate using rough > consensus. This means most people agree and no one strongly objects. If > someone strongly objects, it takes a very unified group to ignore that > person, with full documentation of why the group chose to do so. That per= son > can raise the issue again during working group last call, area director > review, and IETF last call - each has the potential to trigger another ro= und > of discussions with a wider audience. That person can also appeal the > working group decision before it is approved as an RFC. > > > > The process is managed by the working group chairs. The chairs elect the > editor and make consensus calls. So far this working group had only a few > consensus calls (breaking the 1.0a RFC into two parts and dropping these = in > favor of a unified WRAP + 1.0a draft). From my experience and understandi= ng > of the process, this working group does not have rough consensus on any o= f > the open items to make consensus calls and close the issues. Simply > dismissing the few objections raised will not accomplish finishing the > document sooner, but will only add more rounds of debates now and at a la= ter > time. > > > > One of the problems we have is that we work without a charter. Usually, t= he > charter is the most useful tool chairs have when limiting scope and closi= ng > debates. For example, had we fixed the charter last year to explicitly sa= y > that we will publish one document with both bearer tokens and signatures, > the chairs could have ended this argument by pointing to the charter. Sin= ce > we have no charter, the chairs have little to offer in terms of ending th= ese > disagreements. We never officially agreed what we are here to solve. > > > > The reality of this working group is that we need to find a way to make > everyone happy. That includes every one of those expressing strong opinio= ns. > Any attempt to push people around, dismiss their views, or reject reasona= ble > compromises will just keep the issues open. If this small group cannot re= ach > agreement, the specification will surely fall apart during working group > last call, area director review, IETF last call, application area review, > security area review, general area review, IANA review, and IESG review. > > > > It=92s a long process, and at each step, anyone can raise their hand and > object. A united working group is the most important tool to end discussi= ons > over objections and concerns raised at each step. It also give people the > confidence to implement a working group final draft before it is publishe= d > as an RFC (because it is much less likely to change). > > > > --- Open Issues > > > > This working group has failed to reach consensus on a long list of items, > among them are the inclusion of signatures, signatures format, use of HTT= P > authentication headers, restrictions on bearer tokens, support for specif= ic > profiles, etc. While many of these items faded away, I would not be surpr= ise > to see them all come back. > > > > The current argument over signatures ignores compromises and agreements > reached over the past two years. This working group explicitly rejected W= RAP > as the replacement for OAuth 1.0 and the whole point of combining 1.0a wi= th > WRAP was the inclusion of signatures. We reached another agreement to kee= p > signatures at the Anaheim meeting. The current draft is a version of WRAP > alone. > > > > There are currently three separate threads going on: > > > > 1. OAuth 1.0a style signatures vs. JSON proposals > > 2. Including a signature mechanism in core > > 3. Concerns about bearer tokens and HTTPS > > > > The first item will not be resolved because we are not going to reach > industry consensus over a single signature algorithm (this is a general > comment, not specific to these two proposals). The only thing we can do i= s > let those who care about each solution publish their own specification an= d > let the market decide. > > The second item, while it was part of the very first compromise this > working group made (when we combined the two specifications), cannot be > resolved because of #1. We can=92t agree on which signature method to inc= lude, > and including all is not practical. For these reasons, including a signat= ure > algorithm in core is not likely to happen. I have made some proposals but > they received instant negative feedback which means we have no consensus. > > > > The third item has also been debated and blogged for a long time and is n= ot > going to be resolved in consensus. Instead, we will need to find the righ= t > language to balance security concerns with the reality that many provider= s > are going to deploy bearer tokens no matter what the IETF says. The OAuth > 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTP= S, > and I would expect the same issue to come up with the current draft. > > --- Proposal > > > > 1. Add a parameter to the token response to include an extensible token > scheme. > > > > The default (if omitted) will be whatever the bearer token scheme is > called. This will allow the authorization server to return any token type= it > deems appropriate, and for other specifications to define additional > parameters such as token_secret. Others can extend the token request > endpoint by allow the client to request a specific token scheme. > > > > 2. Break the core specification into multiple parts. > > > > Go back to the original working group consensus to break the document int= o > two parts: getting a token and using a token. Getting a token will includ= e > everything from core expect for section 5. Section 5 will become a new > specification which will describe how to use a bearer token (replacing th= e > generic =91OAuth=92 scheme with something more descriptive like). > > > > 3. Introduce two signature proposals in one or more documents, for the JS= ON > token and 1.0a-like method. > > > > One, both, or none can become working group item. > > > > --- Benefits > > > > 1. Remove the HTTP binding from the core specification, leaving it > transport agnostic for using access tokens. > > > > 2. Solve a few open issues: > > > > * Concerns over bearer tokens as the preferred/promoted/default token > method. > > * The use of one or more HTTP authentication schemes, and the general > architecture of using tokens. > > * Issues around scheme names. > > * Concerns over requiring HTTPS will be limited to only one part of the > protocol. > > * The need to pick one signature format. > > * The need to finish signatures before the core (=91how to get an access > token=92). > > * The need to decide on discovery for the entire protocol (moves it to ea= ch > scheme). > > > > 3. Allow moving the core specification to last call within a few weeks (a= nd > maybe also the bearer token part). > > > > --- Downside > > > > The only downside of this approach is that people will need to read at > least two documents. It will not take any more effort or time, just some > guidance. > > > > --- Request for feedback > > > > This proposal represents a purely editorial compromise. I believe it give= s > everyone enough to move forward. It has no impact on implementations. By > breaking the problem into pieces, we allow those who strongly disagree to > simply disengage that work and focus on the parts that matter to them. > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00163645950a1a8f0204918f330b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1, I think this sounds like a sensible path forward

On Tue, Sep 28, 2010 at 8:25 AM, Eran Hammer-Lahav <eran@hueniverse.com>= ; wrote:

(Please take = a break from the other threads and read this with an open mind. I have trie= d to make this both informative and balanced.)

=A0

--- IETF Process

=A0

For those unfamiliar wit= h the IETF process, we operate using rough consensus. This means most peopl= e agree and no one strongly objects. If someone strongly objects, it takes = a very unified group to ignore that person, with full documentation of why = the group chose to do so. That person can raise the issue again during work= ing group last call, area director review, and IETF last call - each has th= e potential to trigger another round of discussions with a wider audience. = That person can also appeal the working group decision before it is approve= d as an RFC.

=A0

The process is managed= by the working group chairs. The chairs elect the editor and make consensu= s calls. So far this working group had only a few consensus calls (breaking= the 1.0a RFC into two parts and dropping these in favor of a unified WRAP = + 1.0a draft). From my experience and understanding of the process, this wo= rking group does not have rough consensus on any of the open items to make = consensus calls and close the issues. Simply dismissing the few objections = raised will not accomplish finishing the document sooner, but will only add= more rounds of debates now and at a later time.

=A0

One of the problems we= have is that we work without a charter. Usually, the charter is the most u= seful tool chairs have when limiting scope and closing debates. For example= , had we fixed the charter last year to explicitly say that we will publish= one document with both bearer tokens and signatures, the chairs could have= ended this argument by pointing to the charter. Since we have no charter, = the chairs have little to offer in terms of ending these disagreements. We = never officially agreed what we are here to solve.

=A0

The reality of this wo= rking group is that we need to find a way to make everyone happy. That incl= udes every one of those expressing strong opinions. Any attempt to push peo= ple around, dismiss their views, or reject reasonable compromises will just= keep the issues open. If this small group cannot reach agreement, the spec= ification will surely fall apart during working group last call, area direc= tor review, IETF last call, application area review, security area review, = general area review, IANA review, and IESG review.

=A0

It=92s a long process,= and at each step, anyone can raise their hand and object. A united working= group is the most important tool to end discussions over objections and co= ncerns raised at each step. It also give people the confidence to implement= a working group final draft before it is published as an RFC (because it i= s much less likely to change).

=A0

--- Open Issues

=A0

This working group has fa= iled to reach consensus on a long list of items, among them are the inclusi= on of signatures, signatures format, use of HTTP authentication headers, re= strictions on bearer tokens, support for specific profiles, etc. While many= of these items faded away, I would not be surprise to see them all come ba= ck.

=A0

The current argument o= ver signatures ignores compromises and agreements reached over the past two= years. This working group explicitly rejected WRAP as the replacement for = OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion= of signatures. We reached another agreement to keep signatures at the Anah= eim meeting. The current draft is a version of WRAP alone.

=A0

There are currently th= ree separate threads going on:

=A0

1. OAuth 1.0a style signatures vs. JSON proposals

2. Including a signature mechanism in core

3. Con= cerns about bearer tokens and HTTPS

=A0

The first item will not be resolved because we are not goi= ng to reach industry consensus over a single signature algorithm (this is a= general comment, not specific to these two proposals). The only thing we c= an do is let those who care about each solution publish their own specifica= tion and let the market decide.

The second item, while i= t was part of the very first compromise this working group made (when we co= mbined the two specifications), cannot be resolved because of #1. We can=92= t agree on which signature method to include, and including all is not prac= tical. For these reasons, including a signature algorithm in core is not li= kely to happen. I have made some proposals but they received instant negati= ve feedback which means we have no consensus.

=A0

The third item has als= o been debated and blogged for a long time and is not going to be resolved = in consensus. Instead, we will need to find the right language to balance s= ecurity concerns with the reality that many providers are going to deploy b= earer tokens no matter what the IETF says. The OAuth 1.0a RFC was blocked b= y the IESG until the PLAINTEXT method required HTTPS, and I would expect th= e same issue to come up with the current draft.

--- Proposal

=A0

1. Add a parameter to the toke= n response to include an extensible token scheme.

=A0

The default (if omitted) will be whatever the bearer token scheme is called= . This will allow the authorization server to return any token type it deem= s appropriate, and for other specifications to define additional parameters= such as token_secret. Others can extend the token request endpoint by allo= w the client to request a specific token scheme.

=A0

2. Break the core spec= ification into multiple parts.

=A0

Go back to the original working group consensus to break the do= cument into two parts: getting a token and using a token. Getting a token w= ill include everything from core expect for section 5. Section 5 will becom= e a new specification which will describe how to use a bearer token (replac= ing the generic =91OAuth=92 scheme with something more descriptive like). <= /p>

=A0

3. Introduce two signa= ture proposals in one or more documents, for the JSON token and 1.0a-like m= ethod.

=A0

One, both, o= r none can become working group item.

=A0

--- Benefits

=A0

1. Remove the HTTP binding f= rom the core specification, leaving it transport agnostic for using access = tokens.

=A0

2. Solve a few open is= sues:

=A0

* Concerns ov= er bearer tokens as the preferred/promoted/default token method.

* The use of one or more HTTP authentication schemes, and the general archi= tecture of using tokens.

* Issues around scheme n= ames.

* Concerns over requiring HTTPS will be lim= ited to only one part of the protocol.

* The need to pick one signature format.

* The need to finish signatures before the core (=91how to g= et an access token=92).

* The need to decide on d= iscovery for the entire protocol (moves it to each scheme).

=A0

3. Allow moving the co= re specification to last call within a few weeks (and maybe also the bearer= token part).

=A0

--- D= ownside

=A0

The only downside of t= his approach is that people will need to read at least two documents. It wi= ll not take any more effort or time, just some guidance.

=A0

--- Request for feedback

=A0

This proposal represents a purely edito= rial compromise. I believe it gives everyone enough to move forward. It has= no impact on implementations. By breaking the problem into pieces, we allo= w those who strongly disagree to simply disengage that work and focus on th= e parts that matter to them.

=A0

EHL

=A0

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--00163645950a1a8f0204918f330b-- From prateek.mishra@oracle.com Fri Oct 1 09:38:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C35F3A6EE1 for ; Fri, 1 Oct 2010 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEAm8TGuG3A4 for ; Fri, 1 Oct 2010 09:38:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 69C263A6BE4 for ; Fri, 1 Oct 2010 09:38:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o91GcEi7032170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Oct 2010 16:38:15 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o918u3ZY016155; Fri, 1 Oct 2010 16:38:13 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 654863091285950995; Fri, 01 Oct 2010 09:36:35 -0700 Received: from [192.168.1.7] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Oct 2010 09:36:35 -0700 Message-ID: <4CA60E13.3060005@oracle.com> Date: Fri, 01 Oct 2010 12:36:35 -0400 From: PRATEEK MISHRA Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4CA3CCBE.80107@oracle.com> <709E7810-2F66-4E4B-85B2-B18BB8751EA5@lodderstedt.net> In-Reply-To: <709E7810-2F66-4E4B-85B2-B18BB8751EA5@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------040709030604010809020303" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] specification of authorization code properties X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:38:40 -0000 This is a multi-part message in MIME format. --------------040709030604010809020303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Torsten, Brain Campbell points out that previous discussions suggest that the authorization code is meant to be a cryptographically protected one-use token (vs. a random string) but that these key (essential!) details are not available draft 10. http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html I would say then that the analogy with the SAML Web SSO browser profile isn't exact but nevertheless some threats are common to both scenarios. I will try to summarize these once a concrete proposal for authorization code is made available by the authors. - prateek > Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. > > Regards, > Torsten. > > > Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA : > > >> I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks. >> >> I would also comment that the exchanges between the end-user, client and authorization endpoints, beginning with the issuance of an authorization code (in SAML 2.0 called a browser artifact) and terminating with the client obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) essentially follow the SAML web browser artifact profile and are therefore open to all of the attacks that the SSTC considered for this protocol. >> >> 1) For example, given the current description it seems that perfectly reasonable for an end-user authorization endpoint to generate a sequence of increasing integers as an authorization code or always return a constant value for a request with a given (client_id, redirection_uri) pair of inputs. So this leads to the possibility of an adversary using some simple techniques to guess valid authorization codes and obtain an access token. >> >> 2) There is a need to articulate some of the minimum properties that an authorization code should possess. I understand that there is an attempt here to give maximum choice to implementors. >> >> For example, the SAML 2.0 artifact format description includes the following language - >> >> [quote] >> The MessageHandle value is constructed from a cryptographically strong random or >> pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of >> values of at least 16 bytes in size. >> [\quote] >> >> >> 3) I am also puzzled by the discrepancy between the language used to describe the generation and use of an authorization code - >> >> [quote - generation - p.18] >> The authorization code >> SHOULD expire shortly after it is issued. The authorization >> server MUST invalidate the authorization code after a single >> usage. The authorization code is bound to the client >> identifier and redirection URI. >> [\quote] >> >> VS >> >> >> [quote - use - p.23] >> The authorization server MUST: >> o Validate the client credentials (if present) and ensure they match >> the authorization code. >> o Verify that the authorization code and redirection URI are all >> valid and match its stored association. >> [\quote] >> >> >> I dont understand how the authorization code is related to the client credentials, or what is meant by "valid" or the reference >> to "stored association". Is there an assumption that authorization server has a stateful table of (authorization code, client id, redirection uri) values? >> Shouldnt this test be limited to checking whether the authorization code is being used with the correct client identifier and redirection URI? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040709030604010809020303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Torsten,

Brain Campbell points out that previous discussions suggest that the authorization code is meant to be a cryptographically protected one-use token (vs. a random string) but that these
key (essential!) details are not available draft 10.

http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html

I would say then that the analogy with the SAML Web SSO browser profile isn't exact but nevertheless some threats are common to both scenarios. I will try to summarize
these once a concrete proposal for authorization code is made available by the authors.

- prateek
Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. 

Regards,
Torsten.


Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA <prateek.mishra@oracle.com>:

  
I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks.

I would also comment that the exchanges between the end-user, client and authorization endpoints, beginning with the issuance of an authorization code (in SAML 2.0 called a browser artifact) and terminating with the client obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) essentially follow the SAML web browser artifact profile and are therefore open to all of the attacks that the SSTC considered for this protocol.

1) For example, given the current description it seems that perfectly reasonable for an end-user authorization endpoint to generate a sequence of increasing integers as an authorization code or always return a constant value for a request with a given (client_id, redirection_uri) pair of inputs. So this leads to the possibility of an adversary using some simple techniques to guess valid authorization codes and obtain an access token.

2) There is a need to articulate some of the minimum properties that an authorization code should possess. I understand that there is an attempt here to give maximum choice to implementors.

For example, the SAML 2.0 artifact format description includes the following language -

[quote]
The MessageHandle value is constructed from a cryptographically strong random or
pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of
values of at least 16 bytes in size.
[\quote]


3) I am also puzzled by the discrepancy between the language used to describe the generation and use of an authorization code -

[quote - generation - p.18]
The authorization code
SHOULD expire shortly after it is issued. The authorization
server MUST invalidate the authorization code after a single
usage. The authorization code is bound to the client
identifier and redirection URI.
[\quote]

VS


[quote - use - p.23]
The authorization server MUST:
o Validate the client credentials (if present) and ensure they match
the authorization code.
o Verify that the authorization code and redirection URI are all
valid and match its stored association.
[\quote]


I dont understand how the authorization code is related to the client credentials, or what is meant by "valid" or the reference
to "stored association". Is there an assumption that authorization server has a stateful table of (authorization code, client id, redirection uri) values?
Shouldnt this test be limited to checking whether the authorization code is being used with the correct client identifier and redirection URI?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040709030604010809020303-- From torsten@lodderstedt.net Fri Oct 1 09:54:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0155C3A6AED for ; Fri, 1 Oct 2010 09:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grJBHVRrrB1Z for ; Fri, 1 Oct 2010 09:54:02 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id EE0A73A6918 for ; Fri, 1 Oct 2010 09:54:01 -0700 (PDT) Received: from [79.253.25.117] (helo=[192.168.71.43]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1P1isi-0006eI-EI; Fri, 01 Oct 2010 18:54:48 +0200 Message-ID: <4CA61276.3080608@lodderstedt.net> Date: Fri, 01 Oct 2010 18:55:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: PRATEEK MISHRA References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4CA3CCBE.80107@oracle.com> <709E7810-2F66-4E4B-85B2-B18BB8751EA5@lodderstedt.net> <4CA60E13.3060005@oracle.com> In-Reply-To: <4CA60E13.3060005@oracle.com> Content-Type: multipart/alternative; boundary="------------030208050704030008080303" X-Df-Sender: torsten@lodderstedt-online.de Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] specification of authorization code properties X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:54:04 -0000 This is a multi-part message in MIME format. --------------030208050704030008080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Prateek, as I remember previous discussions, both design options (self-contained short-living/one-time use tokens as well as random strings) shall be feasible. So your contribution would helpful anyway. regards, Torsten. Am 01.10.2010 18:36, schrieb PRATEEK MISHRA: > Torsten, > > Brain Campbell points out that previous discussions suggest that the > authorization code is meant to be a cryptographically protected > one-use token (vs. a random string) but that these > key (essential!) details are not available draft 10. > > http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html > > I would say then that the analogy with the SAML Web SSO browser > profile isn't exact but nevertheless some threats are common to both > scenarios. I will try to summarize > these once a concrete proposal for authorization code is made > available by the authors. > > - prateek >> Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. >> >> Regards, >> Torsten. >> >> >> Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA: >> >> >>> I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks. >>> >>> I would also comment that the exchanges between the end-user, client and authorization endpoints, beginning with the issuance of an authorization code (in SAML 2.0 called a browser artifact) and terminating with the client obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) essentially follow the SAML web browser artifact profile and are therefore open to all of the attacks that the SSTC considered for this protocol. >>> >>> 1) For example, given the current description it seems that perfectly reasonable for an end-user authorization endpoint to generate a sequence of increasing integers as an authorization code or always return a constant value for a request with a given (client_id, redirection_uri) pair of inputs. So this leads to the possibility of an adversary using some simple techniques to guess valid authorization codes and obtain an access token. >>> >>> 2) There is a need to articulate some of the minimum properties that an authorization code should possess. I understand that there is an attempt here to give maximum choice to implementors. >>> >>> For example, the SAML 2.0 artifact format description includes the following language - >>> >>> [quote] >>> The MessageHandle value is constructed from a cryptographically strong random or >>> pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of >>> values of at least 16 bytes in size. >>> [\quote] >>> >>> >>> 3) I am also puzzled by the discrepancy between the language used to describe the generation and use of an authorization code - >>> >>> [quote - generation - p.18] >>> The authorization code >>> SHOULD expire shortly after it is issued. The authorization >>> server MUST invalidate the authorization code after a single >>> usage. The authorization code is bound to the client >>> identifier and redirection URI. >>> [\quote] >>> >>> VS >>> >>> >>> [quote - use - p.23] >>> The authorization server MUST: >>> o Validate the client credentials (if present) and ensure they match >>> the authorization code. >>> o Verify that the authorization code and redirection URI are all >>> valid and match its stored association. >>> [\quote] >>> >>> >>> I dont understand how the authorization code is related to the client credentials, or what is meant by "valid" or the reference >>> to "stored association". Is there an assumption that authorization server has a stateful table of (authorization code, client id, redirection uri) values? >>> Shouldnt this test be limited to checking whether the authorization code is being used with the correct client identifier and redirection URI? >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> --------------030208050704030008080303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Prateek,

as I remember previous discussions, both design options (self-contained short-living/one-time use tokens as well as random strings) shall be feasible. So your contribution would helpful anyway.

regards,
Torsten.

Am 01.10.2010 18:36, schrieb PRATEEK MISHRA:
Torsten,

Brain Campbell points out that previous discussions suggest that the authorization code is meant to be a cryptographically protected one-use token (vs. a random string) but that these
key (essential!) details are not available draft 10.

http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html

I would say then that the analogy with the SAML Web SSO browser profile isn't exact but nevertheless some threats are common to both scenarios. I will try to summarize
these once a concrete proposal for authorization code is made available by the authors.

- prateek
Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. 

Regards,
Torsten.


Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA <prateek.mishra@oracle.com>:

  
I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks.

I would also comment that the exchanges between the end-user, client and authorization endpoints, beginning with the issuance of an authorization code (in SAML 2.0 called a browser artifact) and terminating with the client obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) essentially follow the SAML web browser artifact profile and are therefore open to all of the attacks that the SSTC considered for this protocol.

1) For example, given the current description it seems that perfectly reasonable for an end-user authorization endpoint to generate a sequence of increasing integers as an authorization code or always return a constant value for a request with a given (client_id, redirection_uri) pair of inputs. So this leads to the possibility of an adversary using some simple techniques to guess valid authorization codes and obtain an access token.

2) There is a need to articulate some of the minimum properties that an authorization code should possess. I understand that there is an attempt here to give maximum choice to implementors.

For example, the SAML 2.0 artifact format description includes the following language -

[quote]
The MessageHandle value is constructed from a cryptographically strong random or
pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of
values of at least 16 bytes in size.
[\quote]


3) I am also puzzled by the discrepancy between the language used to describe the generation and use of an authorization code -

[quote - generation - p.18]
The authorization code
SHOULD expire shortly after it is issued. The authorization
server MUST invalidate the authorization code after a single
usage. The authorization code is bound to the client
identifier and redirection URI.
[\quote]

VS


[quote - use - p.23]
The authorization server MUST:
o Validate the client credentials (if present) and ensure they match
the authorization code.
o Verify that the authorization code and redirection URI are all
valid and match its stored association.
[\quote]


I dont understand how the authorization code is related to the client credentials, or what is meant by "valid" or the reference
to "stored association". Is there an assumption that authorization server has a stateful table of (authorization code, client id, redirection uri) values?
Shouldnt this test be limited to checking whether the authorization code is being used with the correct client identifier and redirection URI?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------030208050704030008080303-- From bcampbell@pingidentity.com Fri Oct 1 11:22:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC5A3A6DDE for ; Fri, 1 Oct 2010 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk+Q0BlKbn68 for ; Fri, 1 Oct 2010 11:22:19 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 158063A6C80 for ; Fri, 1 Oct 2010 11:22:18 -0700 (PDT) Received: from source ([209.85.161.54]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTKYnC1ljTKR740yAGHwYbl1od4guPAI8@postini.com; Fri, 01 Oct 2010 11:23:08 PDT Received: by fxm9 with SMTP id 9so3658974fxm.27 for ; Fri, 01 Oct 2010 11:23:06 -0700 (PDT) Received: by 10.223.114.69 with SMTP id d5mr4044328faq.58.1285957386267; Fri, 01 Oct 2010 11:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.3 with HTTP; Fri, 1 Oct 2010 11:22:35 -0700 (PDT) In-Reply-To: <4CA61276.3080608@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4CA3CCBE.80107@oracle.com> <709E7810-2F66-4E4B-85B2-B18BB8751EA5@lodderstedt.net> <4CA60E13.3060005@oracle.com> <4CA61276.3080608@lodderstedt.net> From: Brian Campbell Date: Fri, 1 Oct 2010 12:22:35 -0600 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" , PRATEEK MISHRA Subject: Re: [OAUTH-WG] specification of authorization code properties X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:22:21 -0000 Yes Torsten, I believe the consensus we ended up out of that last discussion was that the spec and associated security considerations should be written in such a way as to allow for either approach. On Fri, Oct 1, 2010 at 10:55 AM, Torsten Lodderstedt wrote: > Prateek, > > as I remember previous discussions, both design options (self-contained > short-living/one-time use tokens as well as random strings) shall be > feasible. So your contribution would helpful anyway. > > regards, > Torsten. > > Am 01.10.2010 18:36, schrieb PRATEEK MISHRA: > > Torsten, > > Brain Campbell points out that previous discussions suggest that the > authorization code is meant to be a cryptographically protected one-use > token (vs. a random string) but that these > key (essential!) details are not available draft 10. > > http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html > > I would say then that the analogy with the SAML Web SSO browser profile > isn't exact but nevertheless some threats are common to both scenarios. I > will try to summarize > these once a concrete proposal for authorization code is made available by > the authors. > > - prateek > > Thank you for your advice. The Oauth security considerations are not > finished yet. They will handle the issues you raised, too. > > Regards, > Torsten. > > > Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA : > > > > I read through v10 from the perspective of an implementor, and it seemed to > me that properties of generated authorization code and its treatment by > various entities need to be called out explicitly as a counter-measure > against various simple attacks. > > I would also comment that the exchanges between the end-user, client and > authorization endpoints, beginning with the issuance of an authorization > code (in SAML 2.0 called a browser artifact) and terminating with the client > obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) > essentially follow the SAML web browser artifact profile and are therefore > open to all of the attacks that the SSTC considered for this protocol. > > 1) For example, given the current description it seems that perfectly > reasonable for an end-user authorization endpoint to generate a sequence of > increasing integers as an authorization code or always return a constant > value for a request with a given (client_id, redirection_uri) pair of > inputs. So this leads to the possibility of an adversary using some simple > techniques to guess valid authorization codes and obtain an access token. > > 2) There is a need to articulate some of the minimum properties that an > authorization code should possess. I understand that there is an attempt > here to give maximum choice to implementors. > > For example, the SAML 2.0 artifact format description includes the following > language - > > [quote] > The MessageHandle value is constructed from a cryptographically strong > random or > pseudorandom number sequence [RFC1750] generated by the issuer. The sequence > consists of > values of at least 16 bytes in size. > [\quote] > > > 3) I am also puzzled by the discrepancy between the language used to > describe the generation and use of an authorization code - > > [quote - generation - p.18] > The authorization code > SHOULD expire shortly after it is issued. The authorization > server MUST invalidate the authorization code after a single > usage. The authorization code is bound to the client > identifier and redirection URI. > [\quote] > > VS > > > [quote - use - p.23] > The authorization server MUST: > o Validate the client credentials (if present) and ensure they match > the authorization code. > o Verify that the authorization code and redirection URI are all > valid and match its stored association. > [\quote] > > > I dont understand how the authorization code is related to the client > credentials, or what is meant by "valid" or the reference > to "stored association". Is there an assumption that authorization server > has a stateful table of (authorization code, client id, redirection uri) > values? > Shouldnt this test be limited to checking whether the authorization code is > being used with the correct client identifier and redirection URI? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From yarong@microsoft.com Fri Oct 1 15:40:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF333A6DBD for ; Fri, 1 Oct 2010 15:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.891 X-Spam-Level: X-Spam-Status: No, score=-9.891 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXDlr1K0qqDk for ; Fri, 1 Oct 2010 15:40:31 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1B6943A6C0F for ; Fri, 1 Oct 2010 15:40:31 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Oct 2010 15:41:14 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.15]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0218.012; Fri, 1 Oct 2010 15:41:14 -0700 From: Yaron Goland To: Anthony Nadalin , Dirk Balfanz , Mike Jones Thread-Topic: [OAUTH-WG] Comparing the JSON Token drafts Thread-Index: Actepo9jOHYKrp9WTw+gSIlGeIAPVgAxfo4AAB+fEkAAc5aNgA== Date: Fri, 1 Oct 2010 22:41:13 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> In-Reply-To: <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C635D37DBTK5EX14MBXC113r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:40:44 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C635D37DBTK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No matter what algorithm or key size we pick the choice will prove unsuppor= table for any number of implementers due to everything from security issues= (no matter what key size we pick, someone will have a real need for someth= ing larger) to legal issues (various countries have their own opinions abou= t what to use where, a la the NSA suite list). So we are going to have to support multiple algorithms and we are going to = have to deal with algorithm negotiation. I literally can see no way around = that. Yaron From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= nthony Nadalin Sent: Wednesday, September 29, 2010 8:34 AM To: Dirk Balfanz; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts > So this one I do feel more strongly about: We should only include crypto = mechanisms that everybody MUST support. Otherwise, we'll have to invent som= e sort of negotiation step in the protocol: "do you support alg XYZ? No I d= on't, > please use ABC". Let's not do that. >As just one datapoint, Google would have a hard time supporting ECC, since= it's not in the Java core library. We don't use bouncycastle. I agree that there can be license issues that one could encounter with ECC = (as we all did with RSA), there are already customers that require ECC, and= so there is a need to have alternative algorithms that you don't have to s= upport. We already have the issue of "do you support" with claims and token= types, etc From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz Sent: Tuesday, September 28, 2010 10:23 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones > wrote: Dirk and I both posted JSON Token drafts on Thursday. They are at http://b= alfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'l= l refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-j= son-web-token-00.html (which I'll refer to as JWT). This note points out s= ome of the differences (and commonalities) in the interest of building cons= ensus towards a unified approach. Commonalities: * Both have ways of expressing the signature algorithm, token issue= r, token expiration time, and intended audience. * Both use a form of base64url encoding of the JSON claim data. * Both require support for the HMAC SHA-256 signature algorithm, an= d describe how to sign with RSA SHA-256 as well. Differences: * Dirk's draft uses a base64url encoding that may include one or tw= o '=3D' pad characters. The JWT draft uses base64url encoding without padd= ing. * JWT uses shorter claim names in the interest of brevity ("iss", "= exp", and "aud", versus "issuer", "not_after", and "audience"). * JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA= , and ECDSA with longer key lengths. * Dirk's tokens must be signed, whereas signing JWTs is optional. * Dirk's draft provides for a key_id parameter and a means of seria= lizing keys. * Dirk's draft utilizes a Magic Signatures envelope, whereas the on= ly "envelope" component of a JWT is the encoded signature. * Dirk's draft proposes that a particular discovery mechanism be us= ed with JSON tokens. Let me tackle the differences one at a time, in hopes of driving towards a = consensus position. Hi there - thanks for writhing this up. Comments below: * To pad or not to pad: The '=3D' pad characters add length, are n= ot URL-safe (and therefore must be escaped when used in URLs, adding more l= ength), and add no information. Therefore, I would propose that we agree n= ot to use padding (as permitted by RFC 4648, Section 5), especially since a no-padding implementation is= trivial, as shown in JWT Section 13. I don't feel strongly about this, but remember John Panzer's cautionary tal= es here: Apparently, padding-less encoding is not well-supported in some fr= ameworks, which can lead to confusion. * Claim name length: Given that a core goal of both specs is short = tokens, I would propose that we use the shorter reserved claim names. Havi= ng short tokens is especially important when used with mobile browsers, whe= re URL length restrictions may be severe. (People are always free to use l= onger ones in any particular application context if they have a reason to d= o so.) I don't feel strongly about this, but I think many people do want to have m= ore descriptive names here. * Elliptic curve crypto and longer key lengths: The JWT spec defin= es how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Su= ite B and t= hat it has engineering advantages over RSA (shorter key lengths and more ef= ficient computations), it makes sense that any modern spec incorporating cr= yptography allow its use as an option. Likewise, it makes sense for the sp= ec to define how to use longer key lengths on an optional basis. So this one I do feel more strongly about: We should only include crypto me= chanisms that everybody MUST support. Otherwise, we'll have to invent some = sort of negotiation step in the protocol: "do you support alg XYZ? No I don= 't, please use ABC". Let's not do that. As just one datapoint, Google would have a hard time supporting ECC, since = it's not in the Java core library. We don't use bouncycastle. * Unsigned tokens: In some application contexts, it may make sense= to send unsigned tokens if carried in a signed and/or encrypted container = or channel. Allowing for unsigned tokens means that double signing need no= t occur. That one just confuses me :-) What's the difference between OAuth without s= ignatures and unsigned tokens? Is the latter not just a more complicated wa= y of doing the former? * Key identification: I agree that having means of identifying and= distributing keys are critical for to end-to-end security of signed tokens= . That's a separate point from whether the key identification and distribu= tion mechanisms should be part of the token format specification, or treate= d separately. I would advocate that it be treated separately (as was done = with SWTs as well), but am open to discussion on this point. * Discovery: Like key distribution, I believe that an agreement on= discovery mechanisms is critical to many use cases. But like key distribu= tion, I'd like us to take that up in a separate specification, rather than = tightly binding the use of JSON tokens to a particular discovery mechanism. Here is where I'm coming from: I find the public-key versions of the signat= ures much more intriguing - they allow for easier key management, key rotat= ion, etc. To actually reap the benefits of key rotation, though, we need to= say how to find out what the currently-used key is. If we don't, then a lo= t of the potential advantage of using public keys evaporates. I'm concerned= that, lacking the discovery spec, developers will start hard-coding keys i= nto their servers, and we'll end up in a situation where we can't rotate ke= ys when Something Bad happens. * Envelope structure: Dirk's draft proposes that the signed conten= t be wrapped in a particular kind of envelope. Among other things, this en= velope can help prevent a token from being repurposed from one context to a= nother, by having a clear (and cryptographically verified) declaration that= "This is a JSON token". I understand this motivation and am open to discu= ssions on how to best achieve it, while still providing as little mechanism= as possible (but no less :)). Well, you've seen my proposal on how to achieve it :-), but I'm also open t= o better ways, if someone comes up with one... Dirk. Dirk, and others, please jump in! -- Mike --_000_7C01E631FF4B654FA1E783F1C0265F8C635D37DBTK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No matter what algorithm = or key size we pick the choice will prove unsupportable for any number of i= mplementers due to everything from security issues (no matter what key size we pick, someone will have a real need for something larger)= to legal issues (various countries have their own opinions about what to u= se where, a la the NSA suite list).

 <= /p>

So we are going to have t= o support multiple algorithms and we are going to have to deal with algorit= hm negotiation. I literally can see no way around that.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;  Yaron

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, September 29, 2010 8:34 AM
To: Dirk Balfanz; Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

 

> So this one I= do feel more strongly about: We should only include crypto mechanisms that= everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: "do you support alg XYZ? No= I don't, > please use ABC". Let's not do that. 

 

>As just one datapoint, Google would have a hard = time supporting ECC, since it's not in the Java core library. We don't use = bouncycastle.

 <= /p>

I agree that there can be= license issues that one could encounter with ECC (as we all did with RSA),= there are already customers that require ECC, and so there is a need to have alternative algorithms that you don’t have to supp= ort. We already have the issue of “do you support” with claims = and token types, etc

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Dirk Balfanz
Sent: Tuesday, September 28, 2010 10:23 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts

 

On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Dirk and I both posted JSON Token drafts on Thursday.  They a= re at http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I’ll refer to as Dirk’s draft) and http://self-issued.info/docs/draft-goland-json-web-token-00.html (which= I’ll refer to as JWT).  This note points out some of the differ= ences (and commonalities) in the interest of building consensus towards a u= nified approach.

 

Commonalities:

·         Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.

·         Both use a form of base64url encoding of the JSON claim data.

·         Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.

 

Differences:

·         Dirk’s draft uses a base64url encoding that may include one or= two ‘=3D’ pad characters.  The JWT draft uses base64url e= ncoding without padding.

·         JWT uses shorter claim names in the interest of brevity (“iss&= #8221;, “exp”, and “aud”, versus “issuer̶= 1;, “not_after”, and “audience”).

·         JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.

·         Dirk’s tokens must be signed, whereas signing JWTs is optional= .

·         Dirk’s draft provides for a key_id parameter and a means of se= rializing keys.

·         Dirk’s draft utilizes a Magic Signatures envelope, whereas the= only “envelope” component of a JWT is the encoded signature.

·         Dirk’s draft proposes that a particular discovery mechanism be= used with JSON tokens.

 

Let me tackle the differences one at a time, in hopes of driving t= owards a consensus position.

 

Hi there - thanks for writhing this up. Comments bel= ow:

·         To pad or not to pad:  The ‘=3D’ pad charact= ers add length, are not URL-safe (and therefore must be escaped when used i= n URLs, adding more length), and add no information.  Therefore, I wou= ld propose that we agree not to use padding (as permitted by RFC 4648, Section 5), especially since a no-padding implementation = is trivial, as shown in JWT Section 13.

 

I don't feel strongly about this, but remember John = Panzer's cautionary tales here: Apparently, padding-less encoding is not we= ll-supported in some frameworks, which can lead to confusion.

 

·         Claim name length: Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.&n= bsp; Having short tokens is especially important when used with mobile brow= sers, where URL length restrictions may be severe.  (People are always free to use longer ones in any particu= lar application context if they have a reason to do so.)

 

I don't feel strongly about this, but I think many p= eople do want to have more descriptive names here. 

 

·         Elliptic curve crypto and longer key lengths:  The JWT s= pec defines how to use ECC as well as HMAC and RSA.  Given ECC’s= inclusion in NSA Suite B and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.  Likewise,= it makes sense for the spec to define how to use longer key lengths on an optional basis.

So this one I do feel more strongly about: We should= only include crypto mechanisms that everybody MUST support. Otherwise, we'= ll have to invent some sort of negotiation step in the protocol: "do y= ou support alg XYZ? No I don't, please use ABC". Let's not do that. 

 

As just one datapoint, Google would have a hard time= supporting ECC, since it's not in the Java core library. We don't use boun= cycastle.

 

·         Unsigned tokens:  In some application contexts, it may m= ake sense to send unsigned tokens if carried in a signed and/or encrypted c= ontainer or channel.  Allowing for unsigned tokens means that double s= igning need not occur.

That one just confuses me :-) What's the difference = between OAuth without signatures and unsigned tokens? Is the latter not jus= t a more complicated way of doing the former? 

 

·         Key identification:  I agree that having means of identi= fying and distributing keys are critical for to end-to-end security of sign= ed tokens.  That’s a separate point from whether the key identif= ication and distribution mechanisms should be part of the token format specification, or treated separately.  I would ad= vocate that it be treated separately (as was done with SWTs as well), but a= m open to discussion on this point.

·         Discovery:  Like key distribution, I believe that an agr= eement on discovery mechanisms is critical to many use cases.  But lik= e key distribution, I’d like us to take that up in a separate specifi= cation, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.

 

Here is where I'm coming from: I find the public-key= versions of the signatures much more intriguing - they allow for easier ke= y management, key rotation, etc. To actually reap the benefits of key rotat= ion, though, we need to say how to find out what the currently-used key is. If we don't, then a lot of the po= tential advantage of using public keys evaporates. I'm concerned that, lack= ing the discovery spec, developers will start hard-coding keys into their s= ervers, and we'll end up in a situation where we can't rotate keys when Something Bad happens.

 

·         E= nvelope structure:  Dirk’s draft proposes that the signed co= ntent be wrapped in a particular kind of envelope.  Among other things= , this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that “This is a JSON = token”.  I understand this motivation and am open to discussions= on how to best achieve it, while still providing as little mechanism as possible (but no less J).

Well, you've seen my proposal on how to achieve it := -), but I'm also open to better ways, if someone comes up with one...<= /o:p>

 

Dirk.

 

 

Dirk, and others, please jump in!

 

           =             &nb= sp;            =             &nb= sp;            =    -- Mike

 

 

--_000_7C01E631FF4B654FA1E783F1C0265F8C635D37DBTK5EX14MBXC113r_-- From yarong@microsoft.com Fri Oct 1 15:47:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450963A6E15 for ; Fri, 1 Oct 2010 15:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XOQbUQICUUo for ; Fri, 1 Oct 2010 15:47:20 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5856D3A6E06 for ; Fri, 1 Oct 2010 15:47:20 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Oct 2010 15:48:03 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.15]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0218.012; Fri, 1 Oct 2010 15:48:02 -0700 From: Yaron Goland To: PRATEEK MISHRA Thread-Topic: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? Thread-Index: ActcLVkcw12z9VXcRZaPemtNsnYbYQAQ74MAAVJFP2A= Date: Fri, 1 Oct 2010 22:48:02 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C635D3859@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C635347FF@TK5EX14MBXC111.redmond.corp.microsoft.com> <4C9D23B6.8090605@oracle.com> In-Reply-To: <4C9D23B6.8090605@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:47:22 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the core OAuth spec the scenario is a tightly related token and applicat= ion endpoint. It presumes that they will take the appropriate security mech= anisms between them such as signed tokens but doesn't require any particula= r solution for how to implement such a mechanism. When the issue was extended to address discovery based scenarios (a scenari= o not currently supported by the core spec) this brought up the problem tha= t a standard mechanism to provide audience protection is needed. So my arti= cle suggests that when discovery is in scope then we will introduce a stand= ard mechanism (in my article I suggest a standardized signed token format i= ncluding an audience value) to address the issue. In other words, the current spec leaves the issue unaddressed because it is= n't in scope but when the scope extends to discovery we'll have to provide = an explicit mechanism. Yaron From: PRATEEK MISHRA [mailto:prateek.mishra@oracle.com] Sent: Friday, September 24, 2010 3:19 PM To: Yaron Goland Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? Yaron, You have referenced the SAML browser SSO protocol (POST profile) in your b= log posting, and correctly observed that the same problem would manifest it= self there as well. As a counter-measure, the SAML POST profile explicitly requires that the ta= rget (destination) URL or similar identifier be carried as part of the SAM= L payload, and, that further the SAML payload is signed. This allows for th= e recipient to determine whether it was the intended target and to ignore p= ayloads directed at other targets. I dont believe that similar constraints have been placed on the OAuth acces= s token - it is essentially undefined? - but maybe I missed that in my read= ing of the specification draft. - prateek My understanding of Eran's article (http://hueniverse.com/2010/09/oauth-2-0= -without-signatures-is-bad-for-the-web/) is that Eran believes that bearer = tokens are not good enough as a security mechanism because they allow for r= eplay attacks in discovery style scenarios. He then, if I understood the ar= ticle correctly, argues that the solution to the replay attack is to sign O= Auth 2.0 requests. In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to = demonstrate that in fact one can easily prevent replay attacks in discovery= scenarios using OAuth 2.0 and bearer tokens. If the article is correct the= n it is not a requirement to introduce message signing into OAuth 2.0 in or= der to prevent the attacks that Eran identified. So this leaves me wondering, what's the critical scenario that can't be met= unless we use sign OAuth 2.0 requests? Thanks, Yaron ________________________________ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the core OAuth spec= the scenario is a tightly related token and application endpoint. It presu= mes that they will take the appropriate security mechanisms between them su= ch as signed tokens but doesn't require any particular solution for how to implement such a mechanism.<= /span>

 

When the issue was ext= ended to address discovery based scenarios (a scenario not currently suppor= ted by the core spec) this brought up the problem that a standard mechanism= to provide audience protection is needed. So my article suggests that when discovery is in scope then we will introd= uce a standard mechanism (in my article I suggest a standardized signed tok= en format including an audience value) to address the issue.

 

In other words, the cu= rrent spec leaves the issue unaddressed because it isn't in scope but when = the scope extends to discovery we'll have to provide an explicit mechanism.=

 

   &nbs= p;            &= nbsp;           &nbs= p;   Yaron

 

From: PRATEEK MISHRA [mailto:prateek.mishra@oracle.com]
Sent: Friday, September 24, 2010 3:19 PM
To: Yaron Goland
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 re= quests?

 

Yaron,

You have referenced the SAML browser SSO protocol  (POST profile) in y= our blog posting, and correctly observed that the same problem would manife= st itself there as well.

As a counter-measure, the SAML POST profile explicitly requires that the ta= rget  (destination) URL or similar identifier be carried as part of th= e SAML payload, and, that further the SAML payload is signed. This allows f= or the recipient to determine whether it was the intended target and to ignore payloads directed at other target= s.

I dont believe that similar constraints have been placed on the OAuth acces= s token - it is essentially undefined? - but maybe I missed that in my read= ing of the specification draft.

- prateek

My understanding of Eran's article (= http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-w= eb/) is that Eran believes that bearer tokens are not good enough as a security mechanism because they all= ow for replay attacks in discovery style scenarios. He then, if I understoo= d the article correctly, argues that the solution to the replay attack is t= o sign OAuth 2.0 requests.

In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to= demonstrate that in fact one can easily prevent replay attacks in discover= y scenarios using OAuth 2.0 and bearer tokens. If the article is correct th= en it is not a requirement to introduce message signing into OAuth 2.0 in order to prevent the attacks that Eran i= dentified.

 

So this leaves me wondering, what's the critical sce= nario that can't be met unless we use sign OAuth 2.0 requests?

 

        &nbs= p;       Thanks,

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Yaron

 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth
 
--_000_7C01E631FF4B654FA1E783F1C0265F8C635D3859TK5EX14MBXC113r_-- From yarong@microsoft.com Fri Oct 1 16:28:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2CE3A6D53 for ; Fri, 1 Oct 2010 16:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.417 X-Spam-Level: X-Spam-Status: No, score=-10.417 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRmnJqNqZZtp for ; Fri, 1 Oct 2010 16:28:29 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 38A3A3A6C7D for ; Fri, 1 Oct 2010 16:28:29 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Oct 2010 16:29:12 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.15]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0218.012; Fri, 1 Oct 2010 16:29:12 -0700 From: Yaron Goland To: Eran Hammer-Lahav , OAuth WG Thread-Topic: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? Thread-Index: ActcLVkcw12z9VXcRZaPemtNsnYbYQALjU6xAVfKB/A= Date: Fri, 1 Oct 2010 23:29:11 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C635D3966@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C635347FF@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C635D3966TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:28:36 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3966TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Relying on HTTPS - I would be interested in use cases where HTTPS isn't availa= ble but OAuth 1.0 signatures are a sufficient substitute. Also, HTTPS shoul= d be used with an application endpoint if it is dealing with high value con= tent. Bearer tokens and discovery - Unless an application endpoint requires a different access = token for each URL then there must always be some kind of policy defining w= hich application endpoints are willing to share tokens. So the issue isn't = policy, it's what happens when a client screws up and sends a token some pl= ace they shouldn't have? In cases where an error is a real risk an easy solution to = this problem that doesn't require signing the message is to use a proof of = possession token. Just require that the OAuth token in the HTTP authorizati= on header is a token signed/hmac'd with the proof-of-possession key where t= he audience is the application endpoint and the original access token is in= cluded as a claim. Yaron From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, September 24, 2010 7:44 PM To: Yaron Goland; OAuth WG Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests? These are my two: 1. Remove the need to rely solely on HTTPS There are plenty of cases where people can't or don't want to use HTTPS. Cl= early, the web is not all HTTPS and OAuth should be useful on the entire we= b. We are not going to settle the long debate over the cost or speed of usi= ng HTTPS. It doesn't matter. There are enough people who are set in their m= ind about it and we need to offer an alternative. >From an implementation perspective, HTTP client implementations are notorio= usly broken. Not the library code, but the way developers use it. For examp= le, most developer ignore exceptions about invalid or expired certificates.= This is why the major browsers had to change their UI to make it really ha= rd for users to accept bad certificated (which people still do). We keep fo= rgetting that while HTTPS is properly executed in most browsers, it is not = the case in most client applications. I would like to see a detailed section in the specification detailing every= thing a developer has to check to actually ensure their HTTPS connection is= secure and to the right destination. It is nice to put the burden on HTTPS= and point people there, but if we know they are going to do stupid things = (like they have done before), we have the responsibility to write a defensi= ve protocol that prevents exploits when developers make predictable mistake= s. Another aspect of HTTPS is that in most cases, it terminates at the entry p= oint to the server deployment which exposes the tokens internally to anyone= with access, beyond the final applications. *** If HTTPS is to remain optional for protected resource requests, a signa= ture-based alternative is required. 2. Ensure that tokens are not open to phishing attacks Discovery as well as future use cases for OAuth will create the need for cl= ients to authenticate using tokens against servers that are not hard-coded = into the application. When this happens, bearer tokens are simply too dange= rous. Any solution that is based on sending secrets in the clear (that is, = whoever receives them on the other side can use them, legally or not) is go= ing to cause secrets to leak. I don't need to lay out the exact exploit, only to point to the past 20 yea= rs and show that every single password-based solution has been proven broke= n, even when used over secure channels. It is sad that some of the people w= ho criticized WRAP for this exact reason are not taking part of this discus= sion and gave up (some due to lack of time or interest, others due to being= told to STFU by their employer). It is true that there are methods for using bearer tokens with discovery, b= ut those I have seen all require the client to basically ask the server aft= er each new resource they encounter if it is ok to send the token there. Th= is is very inefficient, when a signature solves that (as offered successful= ly by OpenID). The other solution is to tell the client using some form of = policy where it is ok to send tokens (as is done with cookies), and that's = clearly an approach guaranteed to fail. EHL On 9/24/10 2:18 PM, "Yaron Goland" wrote: My understanding of Eran's article (http://hueniverse.com/2010/09/oauth-2-0= -without-signatures-is-bad-for-the-web/) is that Eran believes that bearer = tokens are not good enough as a security mechanism because they allow for r= eplay attacks in discovery style scenarios. He then, if I understood the ar= ticle correctly, argues that the solution to the replay attack is to sign O= Auth 2.0 requests. In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to = demonstrate that in fact one can easily prevent replay attacks in discovery= scenarios using OAuth 2.0 and bearer tokens. If the article is correct the= n it is not a requirement to introduce message signing into OAuth 2.0 in or= der to prevent the attacks that Eran identified. So this leaves me wondering, what's the critical scenario that can't be met= unless we use sign OAuth 2.0 requests? Thanks, Yaron --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3966TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?</= title> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Relying on HTTPS - <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           I would b= e interested in use cases where HTTPS isn't available but OAuth 1.0 signatu= res are a sufficient substitute. Also, HTTPS should be used with an application endpoint if it is dealing with high value content.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Bearer tokens and discove= ry -<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           Unless an= application endpoint requires a different access token for each URL then t= here must always be some kind of policy defining which application endpoints are willing to share tokens. So the issue isn't policy, it's wha= t happens when a client screws up and sends a token some place they shouldn= 't have?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           In cases = where an error is a real risk an easy solution to this problem that doesn't= require signing the message is to use a proof of possession token. Just require that the OAuth token in the HTTP authorization header = is a token signed/hmac'd with the proof-of-possession key where the audienc= e is the application endpoint and the original access token is included as = a claim.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           &nbs= p;            &= nbsp;  Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Eran Ham= mer-Lahav [mailto:eran@hueniverse.com] <br> <b>Sent:</b> Friday, September 24, 2010 7:44 PM<br> <b>To:</b> Yaron Goland; OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 re= quests?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:11.0pt;font-family:"Calibri","sans-serif"">These ar= e my two:<br> <br> 1. Remove the need to rely solely on HTTPS<br> <br> There are plenty of cases where people can’t or don’t want to u= se HTTPS. Clearly, the web is not all HTTPS and OAuth should be useful on t= he entire web. We are not going to settle the long debate over the cost or = speed of using HTTPS. It doesn’t matter. There are enough people who are set in their mind about it and we need to offer = an alternative.<br> <br> >From an implementation perspective, HTTP client implementations are notorio= usly broken. Not the library code, but the way developers use it. For examp= le, most developer ignore exceptions about invalid or expired certificates.= This is why the major browsers had to change their UI to make it really hard for users to accept bad cert= ificated (which people still do). We keep forgetting that while HTTPS is pr= operly executed in most browsers, it is not the case in most client applica= tions.<br> <br> I would like to see a detailed section in the specification detailing every= thing a developer has to check to actually ensure their HTTPS connection is= secure and to the right destination. It is nice to put the burden on HTTPS= and point people there, but if we know they are going to do stupid things (like they have done before), w= e have the responsibility to write a defensive protocol that prevents explo= its when developers make predictable mistakes.<br> <br> Another aspect of HTTPS is that in most cases, it terminates at the entry p= oint to the server deployment which exposes the tokens internally to anyone= with access, beyond the final applications.<br> <br> *** If HTTPS is to remain optional for protected resource requests, a signa= ture-based alternative is required.<br> <br> 2. Ensure that tokens are not open to phishing attacks<br> <br> Discovery as well as future use cases for OAuth will create the need for cl= ients to authenticate using tokens against servers that are not hard-coded = into the application. When this happens, bearer tokens are simply too dange= rous. Any solution that is based on sending secrets in the clear (that is, whoever receives them on the oth= er side can use them, legally or not) is going to cause secrets to leak.<br= > <br> I don’t need to lay out the exact exploit, only to point to the past = 20 years and show that every single password-based solution has been proven= broken, even when used over secure channels. It is sad that some of the pe= ople who criticized WRAP for this exact reason are not taking part of this discussion and gave up (some due to lac= k of time or interest, others due to being told to STFU by their employer).= <br> <br> It is true that there are methods for using bearer tokens with discovery, b= ut those I have seen all require the client to basically ask the server aft= er each new resource they encounter if it is ok to send the token there. Th= is is very inefficient, when a signature solves that (as offered successfully by OpenID). The other solution is to = tell the client using some form of policy where it is ok to send tokens (as= is done with cookies), and that’s clearly an approach guaranteed to = fail.<br> <br> EHL<br> <br> <br> <br> On 9/24/10 2:18 PM, "Yaron Goland" <<a href=3D"yarong@microsof= t.com">yarong@microsoft.com</a>> wrote:</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:11.0pt;font-family:"Calibri","sans-serif"">My under= standing of Eran's article (<a href=3D"http://hueniverse.com/2010/09/oauth-= 2-0-without-signatures-is-bad-for-the-web/">http://hueniverse.com/2010/09/o= auth-2-0-without-signatures-is-bad-for-the-web/</a>) is that Eran believes that bearer tokens are not good enough as a security= mechanism because they allow for replay attacks in discovery style scenari= os. He then, if I understood the article correctly, argues that the solutio= n to the replay attack is to sign OAuth 2.0 requests.<br> In <a href=3D"http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/"= >http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/</a> I tried t= o demonstrate that in fact one can easily prevent replay attacks in discove= ry scenarios using OAuth 2.0 and bearer tokens. If the article is correct then it is not a requirement to introduc= e message signing into OAuth 2.0 in order to prevent the attacks that Eran = identified.<br>  <br> So this leaves me wondering, what's the critical scenario that can't be met= unless we use sign OAuth 2.0 requests?<br>  <br>             &nb= sp;   Thanks,<br>  <br>             &nb= sp;            =             &nb= sp;          Yaron</span>= <o:p></o:p></p> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C635D3966TK5EX14MBXC113r_-- From jpanzer@google.com Fri Oct 1 17:11:51 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B773A6E0F for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 17:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.41 X-Spam-Level: X-Spam-Status: No, score=-105.41 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyub5Jtq6VFl for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 17:11:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D51BE3A6DF4 for <oauth@ietf.org>; Fri, 1 Oct 2010 17:11:47 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o920CZGm024636 for <oauth@ietf.org>; Fri, 1 Oct 2010 17:12:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285978356; bh=zErNSj+3O3PefQqc5PQWFs82zMY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HPCJA/2TK5dK+ZCJJszbZ8FuIKnsVMHNmQHtUKUIUM1++Uo6p6KhdtQALGzJf2Vvi KhabsHTJrSEARGuTbAAOA== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq12.eem.corp.google.com with ESMTP id o920CXjY009465 for <oauth@ietf.org>; Fri, 1 Oct 2010 17:12:34 -0700 Received: by pzk28 with SMTP id 28so2602000pzk.25 for <oauth@ietf.org>; Fri, 01 Oct 2010 17:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=2f/yeM6TlZTM/MG4YHMbem4PamsKT7hAOGckC9rcWEI=; b=vVYopbLazNuiSN5XFIyryKlY7KrTx+USeONNK29cb54tQrZHDyEtFuKJm2pofXFBTm YzUJxTHWDrgQSY5cs3oQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sGxs8JhLyqFdcXiUbQaf7s4mmZI9aANmWTwP9TKw6fHlpWcz8+oGFN0x6xHsXWcvw2 t0bLTJY44koBqFMgoXZw== Received: by 10.142.249.16 with SMTP id w16mr5425392wfh.251.1285978352786; Fri, 01 Oct 2010 17:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.7 with HTTP; Fri, 1 Oct 2010 17:12:12 -0700 (PDT) In-Reply-To: <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> From: John Panzer <jpanzer@google.com> Date: Fri, 1 Oct 2010 17:12:12 -0700 Message-ID: <AANLkTi=Z0-7NAXGzhx45b1jQY=nq7Ttv8KRsxueSgPLr@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=00504502ca54e81cd10491972ac2 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 02 Oct 2010 00:11:51 -0000 --00504502ca54e81cd10491972ac2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Quick note: On Tue, Sep 28, 2010 at 10:23 AM, Dirk Balfanz <balfanz@google.com> wrote: > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote: > >> Dirk and I both posted JSON Token drafts on Thursday. They are at >> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html= (which I=92ll refer to as Dirk=92s draft) and >> http://self-issued.info/docs/draft-goland-json-web-token-00.html (which >> I=92ll refer to as JWT). This note points out some of the differences (= and >> commonalities) in the interest of building consensus towards a unified >> approach. >> >> >> >> Commonalities: >> >> =B7 Both have ways of expressing the signature algorithm, token >> issuer, token expiration time, and intended audience. >> >> =B7 Both use a form of base64url encoding of the JSON claim data= . >> >> =B7 Both require support for the HMAC SHA-256 signature algorith= m, >> and describe how to sign with RSA SHA-256 as well. >> >> >> >> Differences: >> >> =B7 Dirk=92s draft uses a base64url encoding that may include on= e or >> two =91=3D=92 pad characters. The JWT draft uses base64url encoding wit= hout >> padding. >> >> =B7 JWT uses shorter claim names in the interest of brevity (=93= iss=94, >> =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93a= udience=94). >> >> =B7 JWT also describes how to sign with ECDSA SHA-256, plus HMAC= , >> RSA, and ECDSA with longer key lengths. >> >> =B7 Dirk=92s tokens must be signed, whereas signing JWTs is opti= onal. >> >> =B7 Dirk=92s draft provides for a key_id parameter and a means o= f >> serializing keys. >> >> =B7 Dirk=92s draft utilizes a Magic Signatures envelope, whereas= the >> only =93envelope=94 component of a JWT is the encoded signature. >> >> =B7 Dirk=92s draft proposes that a particular discovery mechanis= m be >> used with JSON tokens. >> >> >> >> Let me tackle the differences one at a time, in hopes of driving towards= a >> consensus position. >> > > Hi there - thanks for writhing this up. Comments below: > >> =B7 *To pad or not to pad:* The =91=3D=92 pad characters add le= ngth, are >> not URL-safe (and therefore must be escaped when used in URLs, adding mo= re >> length), and add no information. Therefore, I would propose that we agr= ee >> not to use padding (as permitted by RFC 4648, Section 5<http://tools.iet= f.org/html/rfc4648#section-5>), >> especially since a no-padding implementation is trivial, as shown in JWT >> Section 13<http://self-issued.info/docs/draft-goland-json-web-token-00.h= tml#base64urlnotes> >> . >> > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, padding-less encoding is not well-supported in so= me > frameworks, which can lead to confusion. > Note: If this were the one remaining blocking issue keeping a shared core signature spec from happening, I and the other implementors I've talked to on Magic Signatures would be okay with switching if you feel really strongly. It will be an interop pain point but not a deal breaker. So I suggest putting this on hold, and seeing if everything else can be worked out first, and if so, then we're done. > > >> =B7 *Claim name length:* Given that a core goal of both specs is >> short tokens, I would propose that we use the shorter reserved claim nam= es. >> Having short tokens is especially important when used with mobile browse= rs, >> where URL length restrictions may be severe. (People are always free to= use >> longer ones in any particular application context if they have a reason = to >> do so.) >> > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > >> =B7 *Elliptic curve crypto and longer key lengths:* The JWT spe= c >> defines how to use ECC as well as HMAC and RSA. Given ECC=92s inclusion= in NSA >> Suite B <http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml>= and that it has engineering advantages over RSA (shorter key lengths and >> more efficient computations), it makes sense that any modern spec >> incorporating cryptography allow its use as an option. Likewise, it mak= es >> sense for the spec to define how to use longer key lengths on an optiona= l >> basis. >> > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > As just one datapoint, Google would have a hard time supporting ECC, sinc= e > it's not in the Java core library. We don't use bouncycastle. > > >> =B7 *Unsigned tokens:* In some application contexts, it may ma= ke >> sense to send unsigned tokens if carried in a signed and/or encrypted >> container or channel. Allowing for unsigned tokens means that double >> signing need not occur. >> > That one just confuses me :-) What's the difference between OAuth without > signatures and unsigned tokens? Is the latter not just a more complicated > way of doing the former? > > =B7 *Key identification:* I agree that having means of identify= ing >> and distributing keys are critical for to end-to-end security of signed >> tokens. That=92s a separate point from whether the key identification a= nd >> distribution mechanisms should be part of the token format specification= , or >> treated separately. I would advocate that it be treated separately (as = was >> done with SWTs as well), but am open to discussion on this point. >> >> =B7 *Discovery:* Like key distribution, I believe that an >> agreement on discovery mechanisms is critical to many use cases. But li= ke >> key distribution, I=92d like us to take that up in a separate specificat= ion, >> rather than tightly binding the use of JSON tokens to a particular disco= very >> mechanism. >> >> > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, k= ey > rotation, etc. To actually reap the benefits of key rotation, though, we > need to say how to find out what the currently-used key is. If we don't, > then a lot of the potential advantage of using public keys evaporates. I'= m > concerned that, lacking the discovery spec, developers will start > hard-coding keys into their servers, and we'll end up in a situation wher= e > we can't rotate keys when Something Bad happens. > > =B7 *Envelope structure:* Dirk=92s draft proposes that the signe= d >> content be wrapped in a particular kind of envelope. Among other things= , >> this envelope can help prevent a token from being repurposed from one >> context to another, by having a clear (and cryptographically verified) >> declaration that =93This is a JSON token=94. I understand this motivati= on and >> am open to discussions on how to best achieve it, while still providing = as >> little mechanism as possible (but no less J). >> > Well, you've seen my proposal on how to achieve it :-), but I'm also open > to better ways, if someone comes up with one... > > Dirk. > > >> >> >> Dirk, and others, please jump in! >> >> >> >> -- Mike >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00504502ca54e81cd10491972ac2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">Quick note:</div><div class=3D"gmail_quote"><br>= </div><div class=3D"gmail_quote">On Tue, Sep 28, 2010 at 10:23 AM, Dirk Bal= fanz <span dir=3D"ltr"><<a href=3D"mailto:balfanz@google.com">balfanz@go= ogle.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On Mon, Sep 27, 2010 at 5= :46 PM, Mike Jones <span dir=3D"ltr"><<a href=3D"mailto:Michael.Jones@mi= crosoft.com" target=3D"_blank">Michael.Jones@microsoft.com</a>></span> w= rote:<br> </div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal">Dirk and I both posted JSON Token drafts on Thursday= .=A0 They are at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I=92ll refer to as Dirk=92s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank">http://self-issued.info/docs/draft-goland-json-web-toke= n-00.html</a> (which I=92ll refer to as JWT).=A0 This note points out some = of the differences (and commonalities) in the interest of building consensus towards a unified approach.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Commonalities:</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Both have ways of expressing the signature algorithm, = token issuer, token expiration time, and intended audience.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Both use a form of base64url encoding of the JSON clai= m data.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Both require support for the HMAC SHA-256 signature al= gorithm, and describe how to sign with RSA SHA-256 as well.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Differences:</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Dirk=92s draft uses a base64url encoding that may incl= ude one or two =91=3D=92 pad characters.=A0 The JWT draft uses base64url en= coding without padding.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>JWT uses shorter claim names in the interest of brevit= y (=93iss=94, =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after= =94, and =93audience=94).</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>JWT also describes how to sign with ECDSA SHA-256, plu= s HMAC, RSA, and ECDSA with longer key lengths.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Dirk=92s tokens must be signed, whereas signing JWTs i= s optional.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Dirk=92s draft provides for a key_id parameter and a m= eans of serializing keys.</p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Dirk=92s draft utilizes a Magic Signatures envelope, w= hereas the only =93envelope=94 component of a JWT is the encoded signature.= </p> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span>Dirk=92s draft proposes that a particular discovery me= chanism be used with JSON tokens.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Let me tackle the differences one at a time, in hope= s of driving towards a consensus position.</p></div></div></blockquote><div= ><br></div></div><div>Hi there - thanks for writhing this up. Comments belo= w:</div> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"p= urple"><div> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>To pad or not to pad:</b>=A0 The =91=3D=92 pad char= acters add length, are not URL-safe (and therefore must be escaped when use= d in URLs, adding more length), and add no information.=A0 Therefore, I wou= ld propose that we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648= #section-5" target=3D"_blank"> RFC 4648, Section 5</a>), especially since a no-padding implementation is t= rivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland-jso= n-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.<= /p> </div></div></blockquote><div><br></div></div><div>I don't feel strongl= y about this, but remember John Panzer's cautionary tales here: Apparen= tly, padding-less encoding is not well-supported in some frameworks, which = can lead to confusion.</div> </div></blockquote><div><br></div><div>Note: If this were the one remaining= blocking issue keeping a shared core signature spec from happening, I and = the other implementors I've talked to on Magic Signatures would be okay= with switching if you feel really strongly. =A0It will be an interop pain = point but not a deal breaker. =A0So I suggest putting this on hold, and see= ing if everything else can be worked out first, and if so, then we're d= one.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"gmail_quote"><d= iv class=3D"im"> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"bl= ue" vlink=3D"purple"><div> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>Claim name length:</b> Given that a core goal of bo= th specs is short tokens, I would propose that we use the shorter reserved = claim names.=A0 Having short tokens is especially important when used with = mobile browsers, where URL length restrictions may be severe.=A0 (People are always free to use longe= r ones in any particular application context if they have a reason to do so= .)</p></div></div></blockquote><div><br></div></div><div>I don't feel s= trongly about this, but I think many people do want to have more descriptiv= e names here.=A0</div> <div class=3D"im"> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"bl= ue" vlink=3D"purple"><div> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>Elliptic curve crypto and longer key lengths:</b>= =A0 The JWT spec defines how to use ECC as well as HMAC and RSA.=A0 Given E= CC=92s inclusion in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank">NSA Suite B</a> and that it has engineering advantages ov= er RSA (shorter key lengths and more efficient computations), it makes sens= e that any modern spec incorporating cryptography allow its use as an option.=A0 Likewise, it makes sense for the spec to define h= ow to use longer key lengths on an optional basis.</p></div></div></blockqu= ote></div><div>So this one I do feel more strongly about: We should only in= clude crypto mechanisms that everybody MUST support. Otherwise, we'll h= ave to invent some sort of negotiation step in the protocol: "do you s= upport alg XYZ? No I don't, please use ABC". Let's not do that= .=A0</div> <div><br></div><div>As just one datapoint, Google would have a hard time su= pporting ECC, since it's not in the Java core library. We don't use= bouncycastle.</div><div class=3D"im"><div>=A0</div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>Unsigned tokens:</b>=A0 In some application context= s, it may make sense to send unsigned tokens if carried in a signed and/or = encrypted container or channel.=A0 Allowing for unsigned tokens means that = double signing need not occur.</p> </div></div></blockquote></div><div>That one just confuses me :-) What'= s the difference between OAuth without signatures and unsigned tokens? Is t= he latter not just a more complicated way of doing the former?=A0</div><div= > <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlin= k=3D"purple"><div><div class=3D"im"> <p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.0pt &q= uot;Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>Key identification:</b>=A0 I agree that having mean= s of identifying and distributing keys are critical for to end-to-end secur= ity of signed tokens.=A0 That=92s a separate point from whether the key ide= ntification and distribution mechanisms should be part of the token format specification, or treated se= parately.=A0 I would advocate that it be treated separately (as was done wi= th SWTs as well), but am open to discussion on this point.</p> </div><p><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7.= 0pt "Times New Roman"">=A0=A0=A0=A0=A0=A0=A0=A0 </span></span></span><b>Discovery:</b>=A0 Like key distribution, I believe = that an agreement on discovery mechanisms is critical to many use cases.=A0= But like key distribution, I=92d like us to take that up in a separate spe= cification, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.</p> <p><span style=3D"font-family:Symbol"><span></span></span></p></div></div><= /blockquote><div><br></div><div>Here is where I'm coming from: I find t= he public-key versions of the signatures much more intriguing - they allow = for easier key management, key rotation, etc. To actually reap the benefits= of key rotation, though, we need to say how to find out what the currently= -used key is. If we don't, then a lot of the potential advantage of usi= ng public keys evaporates. I'm concerned that, lacking the discovery sp= ec, developers will start hard-coding keys into their servers, and we'l= l end up in a situation where we can't rotate keys when Something Bad h= appens.</div> <div class=3D"im"> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"b= lue" vlink=3D"purple"><div><p><span style=3D"font-family:Symbol"><span>=B7<= span>=A0=A0=A0=A0=A0=A0=A0=A0=A0</span></span></span><b>Envelope structure:= </b>=A0 Dirk=92s draft proposes that the signed content be wrapped in a par= ticular kind of envelope. =A0Among other things, this envelope can help pre= vent a token from being repurposed from one context to another, by having a= clear (and cryptographically verified) declaration that =93This is a JSON = token=94.=A0 I understand this motivation and am open to discussions on how= to best achieve it, while still providing as little mechanism as possible = (but no less=A0<span style=3D"font-family:Wingdings">J</span>).</p> </div></div></blockquote></div><div>Well, you've seen my proposal on ho= w to achieve it :-), but I'm also open to better ways, if someone comes= up with one...</div><div><br></div><font color=3D"#888888"><div>Dirk.</div= > </font><div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNorm= al">=A0</p> <p class=3D"MsoNormal">Dirk, and others, please jump in!</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike</p> <p class=3D"MsoNormal">=A0</p> </div> </div> </blockquote></div></div><br> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br> --00504502ca54e81cd10491972ac2-- From balfanz@google.com Fri Oct 1 20:44:16 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830163A6D14 for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 20:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.908 X-Spam-Level: X-Spam-Status: No, score=-104.908 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw0qvcWQx-MI for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 20:44:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 244893A6CF3 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:07 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o923ivaX028168 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285991097; bh=Lh51f9ykmfM73Cv8+tW19J1rcMs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FC30hXseJGpcf75kgxxbcp8UUZu5S6sl8Py/ZQcT8Pr/6tls4T+a79o8bgxW3hG6W e5drglOg/zJnoCl0XGsSw== Received: from iwn37 (iwn37.prod.google.com [10.241.68.101]) by hpaq5.eem.corp.google.com with ESMTP id o923isAR006455 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:55 -0700 Received: by iwn37 with SMTP id 37so5400537iwn.29 for <oauth@ietf.org>; Fri, 01 Oct 2010 20:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=soxnWmswWECWg1sodm+Us8ZGI+YP8KI7JHn03Q7dDtE=; b=vRTT7bf7laarvJ5oeNLxHCytg9wX1YJ4tcXE87J6xUx1wU3pftA2lW+ViNE2HhS/2v 44lYJvTOdRDNzkEPZe/A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s+bLDBMgDTQDs9JpfW1Y9IrxUKqXFuCGkJ5jiMrEPYb4MGlALjULOzSXUh/kV+B+dT mBCE8uWSE8nUT5j226cA== MIME-Version: 1.0 Received: by 10.231.146.212 with SMTP id i20mr6703324ibv.52.1285991094134; Fri, 01 Oct 2010 20:44:54 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Fri, 1 Oct 2010 20:44:54 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Fri, 1 Oct 2010 20:44:54 -0700 Message-ID: <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: Yaron Goland <yarong@microsoft.com> Content-Type: multipart/alternative; boundary=0016e6469b0c59a64a04919a2226 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 02 Oct 2010 03:44:16 -0000 --0016e6469b0c59a64a04919a2226 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com> wrote: > No matter what algorithm or key size we pick the choice will prove > unsupportable for any number of implementers due to everything from secur= ity > issues (no matter what key size we pick, someone will have a real need fo= r > something larger) to legal issues (various countries have their own opini= ons > about what to use where, a la the NSA suite list). > > > > So we are going to have to support multiple algorithms and we are going t= o > have to deal with algorithm negotiation. I literally can see no way aroun= d > that. > I agree that over time, what will be considered secure will change. I also agree that usually this means that there is some sort of negotiation happening on what the two parties support. How would that happen here? Remember that - as one datapoint - Google won't be able to support the ECC algorithm. What happens when you can't support one of the proposed algorithms, and there is no provision in the protocol to signal this to other parties? Dirk. > > > Yaron > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Anthony Nadalin > *Sent:* Wednesday, September 29, 2010 8:34 AM > *To:* Dirk Balfanz; Mike Jones > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > > So this one I do feel more strongly about: We should only include crypt= o > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, > please use ABC". Let's not do that. > > > > >As just one datapoint, Google would have a hard time supporting ECC, sin= ce > it's not in the Java core library. We don't use bouncycastle. > > > > I agree that there can be license issues that one could encounter with EC= C > (as we all did with RSA), there are already customers that require ECC, a= nd > so there is a need to have alternative algorithms that you don=92t have t= o > support. We already have the issue of =93do you support=94 with claims an= d token > types, etc > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Dirk Balfanz > *Sent:* Tuesday, September 28, 2010 10:23 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > Dirk and I both posted JSON Token drafts on Thursday. They are at > http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html(= which I=92ll refer to as Dirk=92s draft) and > http://self-issued.info/docs/draft-goland-json-web-token-00.html (which > I=92ll refer to as JWT). This note points out some of the differences (a= nd > commonalities) in the interest of building consensus towards a unified > approach. > > > > Commonalities: > > =B7 Both have ways of expressing the signature algorithm, token > issuer, token expiration time, and intended audience. > > =B7 Both use a form of base64url encoding of the JSON claim data. > > =B7 Both require support for the HMAC SHA-256 signature algorithm= , > and describe how to sign with RSA SHA-256 as well. > > > > Differences: > > =B7 Dirk=92s draft uses a base64url encoding that may include one= or > two =91=3D=92 pad characters. The JWT draft uses base64url encoding with= out > padding. > > =B7 JWT uses shorter claim names in the interest of brevity (=93i= ss=94, > =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93au= dience=94). > > =B7 JWT also describes how to sign with ECDSA SHA-256, plus HMAC, > RSA, and ECDSA with longer key lengths. > > =B7 Dirk=92s tokens must be signed, whereas signing JWTs is optio= nal. > > =B7 Dirk=92s draft provides for a key_id parameter and a means of > serializing keys. > > =B7 Dirk=92s draft utilizes a Magic Signatures envelope, whereas = the > only =93envelope=94 component of a JWT is the encoded signature. > > =B7 Dirk=92s draft proposes that a particular discovery mechanism= be > used with JSON tokens. > > > > Let me tackle the differences one at a time, in hopes of driving towards = a > consensus position. > > > > Hi there - thanks for writhing this up. Comments below: > > =B7 *To pad or not to pad:* The =91=3D=92 pad characters add le= ngth, are > not URL-safe (and therefore must be escaped when used in URLs, adding mor= e > length), and add no information. Therefore, I would propose that we agre= e > not to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf= .org/html/rfc4648#section-5>), > especially since a no-padding implementation is trivial, as shown in JWT > Section 13<http://self-issued.info/docs/draft-goland-json-web-token-00.ht= ml#base64urlnotes> > . > > > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, padding-less encoding is not well-supported in so= me > frameworks, which can lead to confusion. > > > > =B7 *Claim name length:* Given that a core goal of both specs is > short tokens, I would propose that we use the shorter reserved claim name= s. > Having short tokens is especially important when used with mobile browser= s, > where URL length restrictions may be severe. (People are always free to = use > longer ones in any particular application context if they have a reason t= o > do so.) > > > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > > > =B7 *Elliptic curve crypto and longer key lengths:* The JWT spe= c > defines how to use ECC as well as HMAC and RSA. Given ECC=92s inclusion = in NSA > Suite B <http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml>a= nd that it has engineering advantages over RSA (shorter key lengths and > more efficient computations), it makes sense that any modern spec > incorporating cryptography allow its use as an option. Likewise, it make= s > sense for the spec to define how to use longer key lengths on an optional > basis. > > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > > > As just one datapoint, Google would have a hard time supporting ECC, sinc= e > it's not in the Java core library. We don't use bouncycastle. > > > > =B7 *Unsigned tokens:* In some application contexts, it may mak= e > sense to send unsigned tokens if carried in a signed and/or encrypted > container or channel. Allowing for unsigned tokens means that double > signing need not occur. > > That one just confuses me :-) What's the difference between OAuth withou= t > signatures and unsigned tokens? Is the latter not just a more complicated > way of doing the former? > > > > =B7 *Key identification:* I agree that having means of identify= ing > and distributing keys are critical for to end-to-end security of signed > tokens. That=92s a separate point from whether the key identification an= d > distribution mechanisms should be part of the token format specification,= or > treated separately. I would advocate that it be treated separately (as w= as > done with SWTs as well), but am open to discussion on this point. > > =B7 *Discovery:* Like key distribution, I believe that an agreem= ent > on discovery mechanisms is critical to many use cases. But like key > distribution, I=92d like us to take that up in a separate specification, > rather than tightly binding the use of JSON tokens to a particular discov= ery > mechanism. > > > > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, k= ey > rotation, etc. To actually reap the benefits of key rotation, though, we > need to say how to find out what the currently-used key is. If we don't, > then a lot of the potential advantage of using public keys evaporates. I'= m > concerned that, lacking the discovery spec, developers will start > hard-coding keys into their servers, and we'll end up in a situation wher= e > we can't rotate keys when Something Bad happens. > > > > =B7 *Envelope structure:* Dirk=92s draft proposes that the sign= ed > content be wrapped in a particular kind of envelope. Among other things, > this envelope can help prevent a token from being repurposed from one > context to another, by having a clear (and cryptographically verified) > declaration that =93This is a JSON token=94. I understand this motivatio= n and > am open to discussions on how to best achieve it, while still providing a= s > little mechanism as possible (but no less J). > > Well, you've seen my proposal on how to achieve it :-), but I'm also ope= n > to better ways, if someone comes up with one... > > > > Dirk. > > > > > > Dirk, and others, please jump in! > > > > -- Mike > > > > > --0016e6469b0c59a64a04919a2226 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <span dir=3D"ltr"><<a href= =3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a>></span> wrote:= <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">No ma= tter what algorithm or key size we pick the choice will prove unsupportable= for any number of implementers due to everything from security issues (no = matter what key size we pick, someone will have a real need for something larger)= to legal issues (various countries have their own opinions about what to u= se where, a la the NSA suite list). </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">So we= are going to have to support multiple algorithms and we are going to have = to deal with algorithm negotiation. I literally can see no way around that.= </span></p> </div></div></blockquote><div><br></div><div>I agree that over time, what w= ill be considered secure will change. I also agree that usually this means = that there is some sort of negotiation happening on what the two parties su= pport. How would that happen here? Remember that - as one datapoint - Googl= e won't be able to support the ECC algorithm. What happens when you can= 't support one of the proposed algorithms, and there is no provision in= the protocol to signal this to other parties?</div> <div><br></div><div>Dirk.</div><div>=A0</div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;= "><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Yaron</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org"= target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oau= th-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span></p><div><div></div><div class=3D= "h5"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</div></div><= p></p> </div> </div><div><div></div><div class=3D"h5"> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">><= /span> So this one I do feel more strongly about: We should only include cr= ypto mechanisms that everybody MUST support. Otherwise, we'll have to i= nvent some sort of negotiation step in the protocol: "do you support alg XYZ? No= I don't, > please use ABC". Let's not do that.=A0</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">>As just one datapoint, Google would have a hard = time supporting ECC, since it's not in the Java core library. We don= 9;t use bouncycastle.</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I agr= ee that there can be license issues that one could encounter with ECC (as w= e all did with RSA), there are already customers that require ECC, and so t= here is a need to have alternative algorithms that you don=92t have to support.= We already have the issue of =93do you support=94 with claims and token ty= pes, etc</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org"= target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oau= th-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span></p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a h= ref=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@= microsoft.com</a>> wrote:</p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">Dirk and I both posted JSON Token drafts on Thursday= .=A0 They are at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I=92ll refer to as Dirk=92s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I=92ll refer to as JWT).=A0 This note points out some of the differences (= and commonalities) in the interest of building consensus towards a unified = approach.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Commonalities:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both use a form of base64url encoding of the JSON claim data.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Differences:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft uses a base64url encoding that may include one or two= =91=3D=92 pad characters.=A0 The JWT draft uses base64url encoding without= padding.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT uses shorter claim names in the interest of brevity (=93iss=94, = =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93audi= ence=94).</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s tokens must be signed, whereas signing JWTs is optional.</p= > <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft provides for a key_id parameter and a means of serial= izing keys.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft utilizes a Magic Signatures envelope, whereas the onl= y =93envelope=94 component of a JWT is the encoded signature.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft proposes that a particular discovery mechanism be use= d with JSON tokens.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Let me tackle the differences one at a time, in hope= s of driving towards a consensus position.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Hi there - thanks for writhing this up. Comments bel= ow:</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>To pad or not to pad:</b>=A0 The =91=3D=92 pad characters add len= gth, are not URL-safe (and therefore must be escaped when used in URLs, add= ing more length), and add no information.=A0 Therefore, I would propose tha= t we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but remember J= ohn Panzer's cautionary tales here: Apparently, padding-less encoding i= s not well-supported in some frameworks, which can lead to confusion.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.= =A0 Having short tokens is especially important when used with mobile brows= ers, where URL length restrictions may be severe.=A0 (People are always free to use longer ones in any particular= application context if they have a reason to do so.)</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but I think ma= ny people do want to have more descriptive names here.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Elliptic curve crypto and longer key lengths:</b>=A0 The JWT spec= defines how to use ECC as well as HMAC and RSA.=A0 Given ECC=92s inclusion= in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.=A0 Likewise, it= makes sense for the spec to define how to use longer key lengths on an optional basis.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">So this one I do feel more strongly about: We should= only include crypto mechanisms that everybody MUST support. Otherwise, we&= #39;ll have to invent some sort of negotiation step in the protocol: "= do you support alg XYZ? No I don't, please use ABC". Let's not do that.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">As just one datapoint, Google would have a hard time= supporting ECC, since it's not in the Java core library. We don't = use bouncycastle.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Unsigned tokens:</b>=A0 In some application contexts, it may make= sense to send unsigned tokens if carried in a signed and/or encrypted cont= ainer or channel.=A0 Allowing for unsigned tokens means that double signing= need not occur.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">That one just confuses me :-) What's the differe= nce between OAuth without signatures and unsigned tokens? Is the latter not= just a more complicated way of doing the former?=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Key identification:</b>=A0 I agree that having means of identifyi= ng and distributing keys are critical for to end-to-end security of signed = tokens.=A0 That=92s a separate point from whether the key identification an= d distribution mechanisms should be part of the token format specification, or treated separately.=A0 I would advoc= ate that it be treated separately (as was done with SWTs as well), but am o= pen to discussion on this point.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Discovery:</b>=A0 Like key distribution, I believe that an agreem= ent on discovery mechanisms is critical to many use cases.=A0 But like key = distribution, I=92d like us to take that up in a separate specification, ra= ther than tightly binding the use of JSON tokens to a particular discovery mechanism.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Here is where I'm coming from: I find the public= -key versions of the signatures much more intriguing - they allow for easie= r key management, key rotation, etc. To actually reap the benefits of key r= otation, though, we need to say how to find out what the currently-used key is. If we don't, then a lot of th= e potential advantage of using public keys evaporates. I'm concerned th= at, lacking the discovery spec, developers will start hard-coding keys into= their servers, and we'll end up in a situation where we can't rotate keys when Something Bad happens.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0=A0</span><b>Envelope structure:</b>=A0 Dirk= =92s draft proposes that the signed content be wrapped in a particular kind= of envelope. =A0Among other things, this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that =93This is a JSON toke= n=94.=A0 I understand this motivation and am open to discussions on how to = best achieve it, while still providing as little mechanism as possible (but no less=A0<span style=3D"font-family:= Wingdings">J</span>).</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">Well, you've seen my proposal on how to achieve = it :-), but I'm also open to better ways, if someone comes up with one.= ..</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Dirk.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Dirk, and others, please jump in!</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike</p> <p class=3D"MsoNormal">=A0</p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal">=A0</p> </div></div></div> </div> </div> </blockquote></div><br> --0016e6469b0c59a64a04919a2226-- From Michael.Jones@microsoft.com Fri Oct 1 21:03:31 2010 Return-Path: <Michael.Jones@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34C63A6BF1 for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 21:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.322 X-Spam-Level: X-Spam-Status: No, score=-10.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm8v9R2KjMlT for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 21:03:18 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D23863A6BB8 for <oauth@ietf.org>; Fri, 1 Oct 2010 21:03:18 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Oct 2010 21:04:03 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.160]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0218.012; Fri, 1 Oct 2010 21:04:02 -0700 From: Mike Jones <Michael.Jones@microsoft.com> To: Dirk Balfanz <balfanz@google.com>, Yaron Goland <yarong@microsoft.com> Thread-Topic: [OAUTH-WG] Comparing the JSON Token drafts Thread-Index: Actepo9jOHYKrp9WTw+gSIlGeIAPVgAxfo4AAB+fEkAAc5aNgAAZXjwAAA5S2uA= Date: Sat, 2 Oct 2010 04:04:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394314ABDD4C@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> In-Reply-To: <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394314ABDD4CTK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 02 Oct 2010 04:03:31 -0000 --_000_4E1F6AAD24975D4BA5B168042967394314ABDD4CTK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The situation you site is exactly analogous to the situation where sites ne= ed to determine what claims they need to exchange in order to be able to wo= rk together. There is no provision in the protocol for signaling what claims you underst= and and require. It's not that this isn't essential or that it won't happe= n. It's just that it happens via mechanisms not specified in the protocol. . The same is true of the cryptographic algorithms employed to secure those c= laims. If you're going to interact with a particular site, you need to und= erstand what crypto algorithms both of you support (and that meet the secur= ity requirements of your particular application). That needn't be in the c= ore protocol any more than application-specific sets of claims do. -- Mike From: Dirk Balfanz [mailto:balfanz@google.com] Sent: Friday, October 01, 2010 8:45 PM To: Yaron Goland Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com<mailto:y= arong@microsoft.com>> wrote: No matter what algorithm or key size we pick the choice will prove unsuppor= table for any number of implementers due to everything from security issues= (no matter what key size we pick, someone will have a real need for someth= ing larger) to legal issues (various countries have their own opinions abou= t what to use where, a la the NSA suite list). So we are going to have to support multiple algorithms and we are going to = have to deal with algorithm negotiation. I literally can see no way around = that. I agree that over time, what will be considered secure will change. I also = agree that usually this means that there is some sort of negotiation happen= ing on what the two parties support. How would that happen here? Remember t= hat - as one datapoint - Google won't be able to support the ECC algorithm.= What happens when you can't support one of the proposed algorithms, and th= ere is no provision in the protocol to signal this to other parties? Dirk. Yaron From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Anthony Nadali= n Sent: Wednesday, September 29, 2010 8:34 AM To: Dirk Balfanz; Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts > So this one I do feel more strongly about: We should only include crypto = mechanisms that everybody MUST support. Otherwise, we'll have to invent som= e sort of negotiation step in the protocol: "do you support alg XYZ? No I d= on't, > please use ABC". Let's not do that. >As just one datapoint, Google would have a hard time supporting ECC, since= it's not in the Java core library. We don't use bouncycastle. I agree that there can be license issues that one could encounter with ECC = (as we all did with RSA), there are already customers that require ECC, and= so there is a need to have alternative algorithms that you don't have to s= upport. We already have the issue of "do you support" with claims and token= types, etc From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Dirk Balfanz Sent: Tuesday, September 28, 2010 10:23 AM To: Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com<ma= ilto:Michael.Jones@microsoft.com>> wrote: Dirk and I both posted JSON Token drafts on Thursday. They are at http://b= alfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'l= l refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-j= son-web-token-00.html (which I'll refer to as JWT). This note points out s= ome of the differences (and commonalities) in the interest of building cons= ensus towards a unified approach. Commonalities: * Both have ways of expressing the signature algorithm, token issue= r, token expiration time, and intended audience. * Both use a form of base64url encoding of the JSON claim data. * Both require support for the HMAC SHA-256 signature algorithm, an= d describe how to sign with RSA SHA-256 as well. Differences: * Dirk's draft uses a base64url encoding that may include one or tw= o '=3D' pad characters. The JWT draft uses base64url encoding without padd= ing. * JWT uses shorter claim names in the interest of brevity ("iss", "= exp", and "aud", versus "issuer", "not_after", and "audience"). * JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA= , and ECDSA with longer key lengths. * Dirk's tokens must be signed, whereas signing JWTs is optional. * Dirk's draft provides for a key_id parameter and a means of seria= lizing keys. * Dirk's draft utilizes a Magic Signatures envelope, whereas the on= ly "envelope" component of a JWT is the encoded signature. * Dirk's draft proposes that a particular discovery mechanism be us= ed with JSON tokens. Let me tackle the differences one at a time, in hopes of driving towards a = consensus position. Hi there - thanks for writhing this up. Comments below: * To pad or not to pad: The '=3D' pad characters add length, are n= ot URL-safe (and therefore must be escaped when used in URLs, adding more l= ength), and add no information. Therefore, I would propose that we agree n= ot to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf.or= g/html/rfc4648#section-5>), especially since a no-padding implementation is= trivial, as shown in JWT Section 13<http://self-issued.info/docs/draft-gol= and-json-web-token-00.html#base64urlnotes>. I don't feel strongly about this, but remember John Panzer's cautionary tal= es here: Apparently, padding-less encoding is not well-supported in some fr= ameworks, which can lead to confusion. * Claim name length: Given that a core goal of both specs is short = tokens, I would propose that we use the shorter reserved claim names. Havi= ng short tokens is especially important when used with mobile browsers, whe= re URL length restrictions may be severe. (People are always free to use l= onger ones in any particular application context if they have a reason to d= o so.) I don't feel strongly about this, but I think many people do want to have m= ore descriptive names here. * Elliptic curve crypto and longer key lengths: The JWT spec defin= es how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Su= ite B<http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> and t= hat it has engineering advantages over RSA (shorter key lengths and more ef= ficient computations), it makes sense that any modern spec incorporating cr= yptography allow its use as an option. Likewise, it makes sense for the sp= ec to define how to use longer key lengths on an optional basis. So this one I do feel more strongly about: We should only include crypto me= chanisms that everybody MUST support. Otherwise, we'll have to invent some = sort of negotiation step in the protocol: "do you support alg XYZ? No I don= 't, please use ABC". Let's not do that. As just one datapoint, Google would have a hard time supporting ECC, since = it's not in the Java core library. We don't use bouncycastle. * Unsigned tokens: In some application contexts, it may make sense= to send unsigned tokens if carried in a signed and/or encrypted container = or channel. Allowing for unsigned tokens means that double signing need no= t occur. That one just confuses me :-) What's the difference between OAuth without s= ignatures and unsigned tokens? Is the latter not just a more complicated wa= y of doing the former? * Key identification: I agree that having means of identifying and= distributing keys are critical for to end-to-end security of signed tokens= . That's a separate point from whether the key identification and distribu= tion mechanisms should be part of the token format specification, or treate= d separately. I would advocate that it be treated separately (as was done = with SWTs as well), but am open to discussion on this point. * Discovery: Like key distribution, I believe that an agreement on= discovery mechanisms is critical to many use cases. But like key distribu= tion, I'd like us to take that up in a separate specification, rather than = tightly binding the use of JSON tokens to a particular discovery mechanism. Here is where I'm coming from: I find the public-key versions of the signat= ures much more intriguing - they allow for easier key management, key rotat= ion, etc. To actually reap the benefits of key rotation, though, we need to= say how to find out what the currently-used key is. If we don't, then a lo= t of the potential advantage of using public keys evaporates. I'm concerned= that, lacking the discovery spec, developers will start hard-coding keys i= nto their servers, and we'll end up in a situation where we can't rotate ke= ys when Something Bad happens. * Envelope structure: Dirk's draft proposes that the signed conten= t be wrapped in a particular kind of envelope. Among other things, this en= velope can help prevent a token from being repurposed from one context to a= nother, by having a clear (and cryptographically verified) declaration that= "This is a JSON token". I understand this motivation and am open to discu= ssions on how to best achieve it, while still providing as little mechanism= as possible (but no less :)). Well, you've seen my proposal on how to achieve it :-), but I'm also open t= o better ways, if someone comes up with one... Dirk. Dirk, and others, please jump in! -- Mike --_000_4E1F6AAD24975D4BA5B168042967394314ABDD4CTK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#002060;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">The situation you site is= exactly analogous to the situation where sites need to determine what clai= ms they need to exchange in order to be able to work together.<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">There is no provision in = the protocol for signaling what claims you understand and require.  It= ’s not that this isn’t essential or that it won’t happen.=   It’s just that it happens via mechanisms not specified in the protocol.<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">The same is true of the c= ryptographic algorithms employed to secure those claims.  If you’= ;re going to interact with a particular site, you need to understand what crypto algorithms both of you support (and that meet the security req= uirements of your particular application).  That needn’t be in t= he core protocol any more than application-specific sets of claims do.<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   -- Mike<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Dirk Bal= fanz [mailto:balfanz@google.com] <br> <b>Sent:</b> Friday, October 01, 2010 8:45 PM<br> <b>To:</b> Yaron Goland<br> <b>Cc:</b> Anthony Nadalin; Mike Jones; oauth@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <<a = href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a>> wrote:<o:= p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">No matter what algo= rithm or key size we pick the choice will prove unsupportable for any numbe= r of implementers due to everything from security issues (no matter what key size we pick, someone will have a real= need for something larger) to legal issues (various countries have their o= wn opinions about what to use where, a la the NSA suite list). </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">So we are going to = have to support multiple algorithms and we are going to have to deal with a= lgorithm negotiation. I literally can see no way around that.</span><o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I agree that over time, what will be considered secu= re will change. I also agree that usually this means that there is some sor= t of negotiation happening on what the two parties support. How would that = happen here? Remember that - as one datapoint - Google won't be able to support the ECC algorithm. What happen= s when you can't support one of the proposed algorithms, and there is no pr= ovision in the protocol to signal this to other parties?<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">   &= nbsp;           &nbs= p;            &= nbsp;   Yaron</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span><o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">></span> So this= one I do feel more strongly about: We should only include crypto mechanism= s that everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: "= do you support alg XYZ? No I don't, > please use ABC". Let's not do= that. <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">>As just one datapoint, Google would have a hard time supportin= g ECC, since it's not in the Java core library. We don't use bouncycastle.<= o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">I agree that there = can be license issues that one could encounter with ECC (as we all did with= RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that yo= u don’t have to support. We already have the issue of “do you s= upport” with claims and token types, etc</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a href=3D"mailto:= Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@microsoft.com<= /a>> wrote:<o:p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk and I both posted JSON Token drafts on Thursday.  They a= re at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I’ll refer to as Dirk’s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I’ll refer to as JWT).  This note points out some of the differ= ences (and commonalities) in the interest of building consensus towards a u= nified approach.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Commonalities:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both use a form of base64url encoding of the JSON claim data.<o:p></= o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Differences:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft uses a base64url encoding that may include one or= two ‘=3D’ pad characters.  The JWT draft uses base64url e= ncoding without padding.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT uses shorter claim names in the interest of brevity (“iss&= #8221;, “exp”, and “aud”, versus “issuer̶= 1;, “not_after”, and “audience”).<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s tokens must be signed, whereas signing JWTs is optional= .<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft provides for a key_id parameter and a means of se= rializing keys.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft utilizes a Magic Signatures envelope, whereas the= only “envelope” component of a JWT is the encoded signature.<o= :p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft proposes that a particular discovery mechanism be= used with JSON tokens.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Let me tackle the differences one at a time, in hopes of driving t= owards a consensus position.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Hi there - thanks for writhing this up. Comments below:<o:p></o:p>= </p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>To pad or not to pad:</b>  The ‘=3D’ pad charact= ers add length, are not URL-safe (and therefore must be escaped when used i= n URLs, adding more length), and add no information.  Therefore, I wou= ld propose that we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but remember John Panzer's cauti= onary tales here: Apparently, padding-less encoding is not well-supported i= n some frameworks, which can lead to confusion.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.&n= bsp; Having short tokens is especially important when used with mobile brow= sers, where URL length restrictions may be severe.  (People are always free to use longer ones in any particu= lar application context if they have a reason to do so.)<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but I think many people do want = to have more descriptive names here. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Elliptic curve crypto and longer key lengths:</b>  The JWT s= pec defines how to use ECC as well as HMAC and RSA.  Given ECC’s= inclusion in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.  Likewise,= it makes sense for the spec to define how to use longer key lengths on an optional basis.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">So this one I do feel more strongly about: We should only include = crypto mechanisms that everybody MUST support. Otherwise, we'll have to inv= ent some sort of negotiation step in the protocol: "do you support alg XYZ? No I don't, please use ABC&quo= t;. Let's not do that. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">As just one datapoint, Google would have a hard time supporting EC= C, since it's not in the Java core library. We don't use bouncycastle.<o:p>= </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Unsigned tokens:</b>  In some application contexts, it may m= ake sense to send unsigned tokens if carried in a signed and/or encrypted c= ontainer or channel.  Allowing for unsigned tokens means that double s= igning need not occur.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">That one just confuses me :-) What's the difference between OAuth = without signatures and unsigned tokens? Is the latter not just a more compl= icated way of doing the former? <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Key identification:</b>  I agree that having means of identi= fying and distributing keys are critical for to end-to-end security of sign= ed tokens.  That’s a separate point from whether the key identif= ication and distribution mechanisms should be part of the token format specification, or treated separately.  I would ad= vocate that it be treated separately (as was done with SWTs as well), but a= m open to discussion on this point.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Discovery:</b>  Like key distribution, I believe that an agr= eement on discovery mechanisms is critical to many use cases.  But lik= e key distribution, I’d like us to take that up in a separate specifi= cation, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Here is where I'm coming from: I find the public-key versions of t= he signatures much more intriguing - they allow for easier key management, = key rotation, etc. To actually reap the benefits of key rotation, though, we need to say how to find out what = the currently-used key is. If we don't, then a lot of the potential advanta= ge of using public keys evaporates. I'm concerned that, lacking the discove= ry spec, developers will start hard-coding keys into their servers, and we'll end up in a situation where we can't ro= tate keys when Something Bad happens.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>E= nvelope structure:</b>  Dirk’s draft proposes that the signed co= ntent be wrapped in a particular kind of envelope.  Among other things= , this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that “This is a JSON = token”.  I understand this motivation and am open to discussions= on how to best achieve it, while still providing as little mechanism as possible (but no less <span style=3D"font-fami= ly:Wingdings">J</span>).<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Well, you've seen my proposal on how to achieve it :-), but I'm al= so open to better ways, if someone comes up with one...<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk, and others, please jump in!<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =             &nb= sp;            =             &nb= sp;            =    -- Mike<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </div> </div> </div> </blockquote> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_4E1F6AAD24975D4BA5B168042967394314ABDD4CTK5EX14MBXC207r_-- From eran@hueniverse.com Fri Oct 1 21:06:28 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43D13A6E3E for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 21:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps9tRpo-IJMA for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 21:06:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6DE9D3A6BB8 for <oauth@ietf.org>; Fri, 1 Oct 2010 21:06:15 -0700 (PDT) Received: (qmail 7145 invoked from network); 2 Oct 2010 04:07:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2010 04:07:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 1 Oct 2010 21:07:04 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Fri, 1 Oct 2010 21:07:00 -0700 Thread-Topic: Looking for a compromise on signatures and other open issues Thread-Index: Actez1CK1yneinyMRserD5y1FIwYngDFzEjQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DC0BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343D460DC0BBP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 02 Oct 2010 04:06:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343D460DC0BBP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given the overwhelming support for this proposal, I am officially asking th= e chairs to make a consensus call to break the current document into two pa= rts. This will be done with the understanding that the result will be revie= wed by the working group again once the parts are stable to determine if it= compromises the overall readability and security analysis of the protocol. I am also requesting that the chairs assign a new editor for the bearer tok= en part of the specification. I will continue as editor on the 'how to obta= in a token' part, and will also publish an individual submission I-D for an= alternative signature proposal based on my proposal in the -05 draft. EHL From: Eran Hammer-Lahav Sent: Monday, September 27, 2010 11:26 PM To: OAuth WG (oauth@ietf.org) Subject: Looking for a compromise on signatures and other open issues (Please take a break from the other threads and read this with an open mind= . I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensu= s. This means most people agree and no one strongly objects. If someone str= ongly objects, it takes a very unified group to ignore that person, with fu= ll documentation of why the group chose to do so. That person can raise the= issue again during working group last call, area director review, and IETF= last call - each has the potential to trigger another round of discussions= with a wider audience. That person can also appeal the working group decis= ion before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the ed= itor and make consensus calls. So far this working group had only a few con= sensus calls (breaking the 1.0a RFC into two parts and dropping these in fa= vor of a unified WRAP + 1.0a draft). From my experience and understanding o= f the process, this working group does not have rough consensus on any of t= he open items to make consensus calls and close the issues. Simply dismissi= ng the few objections raised will not accomplish finishing the document soo= ner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the= charter is the most useful tool chairs have when limiting scope and closin= g debates. For example, had we fixed the charter last year to explicitly sa= y that we will publish one document with both bearer tokens and signatures,= the chairs could have ended this argument by pointing to the charter. Sinc= e we have no charter, the chairs have little to offer in terms of ending th= ese disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make eve= ryone happy. That includes every one of those expressing strong opinions. A= ny attempt to push people around, dismiss their views, or reject reasonable= compromises will just keep the issues open. If this small group cannot rea= ch agreement, the specification will surely fall apart during working group= last call, area director review, IETF last call, application area review, = security area review, general area review, IANA review, and IESG review. It's a long process, and at each step, anyone can raise their hand and obje= ct. A united working group is the most important tool to end discussions ov= er objections and concerns raised at each step. It also give people the con= fidence to implement a working group final draft before it is published as = an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, a= mong them are the inclusion of signatures, signatures format, use of HTTP a= uthentication headers, restrictions on bearer tokens, support for specific = profiles, etc. While many of these items faded away, I would not be surpris= e to see them all come back. The current argument over signatures ignores compromises and agreements rea= ched over the past two years. This working group explicitly rejected WRAP a= s the replacement for OAuth 1.0 and the whole point of combining 1.0a with = WRAP was the inclusion of signatures. We reached another agreement to keep = signatures at the Anaheim meeting. The current draft is a version of WRAP a= lone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach indus= try consensus over a single signature algorithm (this is a general comment,= not specific to these two proposals). The only thing we can do is let thos= e who care about each solution publish their own specification and let the = market decide. The second item, while it was part of the very first compromise this workin= g group made (when we combined the two specifications), cannot be resolved = because of #1. We can't agree on which signature method to include, and inc= luding all is not practical. For these reasons, including a signature algor= ithm in core is not likely to happen. I have made some proposals but they r= eceived instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not= going to be resolved in consensus. Instead, we will need to find the right= language to balance security concerns with the reality that many providers= are going to deploy bearer tokens no matter what the IETF says. The OAuth = 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS,= and I would expect the same issue to come up with the current draft. --- Proposal 1. Add a parameter to the token response to include an extensible token sch= eme. The default (if omitted) will be whatever the bearer token scheme is called= . This will allow the authorization server to return any token type it deem= s appropriate, and for other specifications to define additional parameters= such as token_secret. Others can extend the token request endpoint by allo= w the client to request a specific token scheme. 2. Break the core specification into multiple parts. Go back to the original working group consensus to break the document into = two parts: getting a token and using a token. Getting a token will include = everything from core expect for section 5. Section 5 will become a new spec= ification which will describe how to use a bearer token (replacing the gene= ric 'OAuth' scheme with something more descriptive like). 3. Introduce two signature proposals in one or more documents, for the JSON= token and 1.0a-like method. One, both, or none can become working group item. --- Benefits 1. Remove the HTTP binding from the core specification, leaving it transpor= t agnostic for using access tokens. 2. Solve a few open issues: * Concerns over bearer tokens as the preferred/promoted/default token metho= d. * The use of one or more HTTP authentication schemes, and the general archi= tecture of using tokens. * Issues around scheme names. * Concerns over requiring HTTPS will be limited to only one part of the pro= tocol. * The need to pick one signature format. * The need to finish signatures before the core ('how to get an access toke= n'). * The need to decide on discovery for the entire protocol (moves it to each= scheme). 3. Allow moving the core specification to last call within a few weeks (and= maybe also the bearer token part). --- Downside The only downside of this approach is that people will need to read at leas= t two documents. It will not take any more effort or time, just some guidan= ce. --- Request for feedback This proposal represents a purely editorial compromise. I believe it gives = everyone enough to move forward. It has no impact on implementations. By br= eaking the problem into pieces, we allow those who strongly disagree to sim= ply disengage that work and focus on the parts that matter to them. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343D460DC0BBP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>Given the overwhelming support for this proposal, I am offici= ally asking the chairs to make a consensus call to break the current docume= nt into two parts. This will be done with the understanding that the result= will be reviewed by the working group again once the parts are stable to d= etermine if it compromises the overall readability and security analysis of= the protocol.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'col= or:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D= 'color:#1F497D'>I am also requesting that the chairs assign a new editor fo= r the bearer token part of the specification. I will continue as editor on = the ‘how to obtain a token’ part, and will also publish an indi= vidual submission I-D for an alternative signature proposal based on my pro= posal in the -05 draft.<o:p></o:p></span></p><p class=3DMsoNormal><span sty= le=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span= style=3D'color:#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal>= <span style=3D'color:#1F497D'><o:p> </o:p></span></p><div style=3D'bor= der:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div = style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0= in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Ta= homa","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-fa= mily:"Tahoma","sans-serif"'> Eran Hammer-Lahav <br><b>Sent:</b> Monday, Sep= tember 27, 2010 11:26 PM<br><b>To:</b> OAuth WG (oauth@ietf.org)<br><b>Subj= ect:</b> Looking for a compromise on signatures and other open issues<o:p><= /o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p cl= ass=3DMsoNormal>(Please take a break from the other threads and read this w= ith an open mind. I have tried to make this both informative and balanced.)= <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorm= al>--- IETF Process<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p= ><p class=3DMsoNormal>For those unfamiliar with the IETF process, we operat= e using rough consensus. This means most people agree and no one strongly o= bjects. If someone strongly objects, it takes a very unified group to ignor= e that person, with full documentation of why the group chose to do so. Tha= t person can raise the issue again during working group last call, area dir= ector review, and IETF last call - each has the potential to trigger anothe= r round of discussions with a wider audience. That person can also appeal t= he working group decision before it is approved as an RFC.<o:p></o:p></p><p= class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>The process is= managed by the working group chairs. The chairs elect the editor and make = consensus calls. So far this working group had only a few consensus calls (= breaking the 1.0a RFC into two parts and dropping these in favor of a unifi= ed WRAP + 1.0a draft). From my experience and understanding of the process,= this working group does not have rough consensus on any of the open items = to make consensus calls and close the issues. Simply dismissing the few obj= ections raised will not accomplish finishing the document sooner, but will = only add more rounds of debates now and at a later time.<o:p></o:p></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>One of the probl= ems we have is that we work without a charter. Usually, the charter is the = most useful tool chairs have when limiting scope and closing debates. For e= xample, had we fixed the charter last year to explicitly say that we will p= ublish one document with both bearer tokens and signatures, the chairs coul= d have ended this argument by pointing to the charter. Since we have no cha= rter, the chairs have little to offer in terms of ending these disagreement= s. We never officially agreed what we are here to solve.<o:p></o:p></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>The reality of t= his working group is that we need to find a way to make everyone happy. Tha= t includes every one of those expressing strong opinions. Any attempt to pu= sh people around, dismiss their views, or reject reasonable compromises wil= l just keep the issues open. If this small group cannot reach agreement, th= e specification will surely fall apart during working group last call, area= director review, IETF last call, application area review, security area re= view, general area review, IANA review, and IESG review.<o:p></o:p></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>It’s a lon= g process, and at each step, anyone can raise their hand and object. A unit= ed working group is the most important tool to end discussions over objecti= ons and concerns raised at each step. It also give people the confidence to= implement a working group final draft before it is published as an RFC (be= cause it is much less likely to change).<o:p></o:p></p><p class=3DMsoNormal= ><o:p> </o:p></p><p class=3DMsoNormal>--- Open Issues<o:p></o:p></p><p= class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>This working g= roup has failed to reach consensus on a long list of items, among them are = the inclusion of signatures, signatures format, use of HTTP authentication = headers, restrictions on bearer tokens, support for specific profiles, etc.= While many of these items faded away, I would not be surprise to see them = all come back.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p c= lass=3DMsoNormal>The current argument over signatures ignores compromises a= nd agreements reached over the past two years. This working group explicitl= y rejected WRAP as the replacement for OAuth 1.0 and the whole point of com= bining 1.0a with WRAP was the inclusion of signatures. We reached another a= greement to keep signatures at the Anaheim meeting. The current draft is a = version of WRAP alone.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p>= </p><p class=3DMsoNormal>There are currently three separate threads going o= n:<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal>1. OAuth 1.0a style signatures vs. JSON proposals<o:p></o:p></p><p cla= ss=3DMsoNormal>2. Including a signature mechanism in core<o:p></o:p></p><p = class=3DMsoNormal>3. Concerns about bearer tokens and HTTPS<o:p></o:p></p><= p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>The first ite= m will not be resolved because we are not going to reach industry consensus= over a single signature algorithm (this is a general comment, not specific= to these two proposals). The only thing we can do is let those who care ab= out each solution publish their own specification and let the market decide= .<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNor= mal>The second item, while it was part of the very first compromise this wo= rking group made (when we combined the two specifications), cannot be resol= ved because of #1. We can’t agree on which signature method to includ= e, and including all is not practical. For these reasons, including a signa= ture algorithm in core is not likely to happen. I have made some proposals = but they received instant negative feedback which means we have no consensu= s.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal>The third item has also been debated and blogged for a long time and i= s not going to be resolved in consensus. Instead, we will need to find the = right language to balance security concerns with the reality that many prov= iders are going to deploy bearer tokens no matter what the IETF says. The O= Auth 1.0a RFC was blocked by the IESG until the PLAINTEXT method required H= TTPS, and I would expect the same issue to come up with the current draft.<= o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorma= l>--- Proposal<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p c= lass=3DMsoNormal>1. Add a parameter to the token response to include an ext= ensible token scheme.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p><= /p><p class=3DMsoNormal>The default (if omitted) will be whatever the beare= r token scheme is called. This will allow the authorization server to retur= n any token type it deems appropriate, and for other specifications to defi= ne additional parameters such as token_secret. Others can extend the token = request endpoint by allow the client to request a specific token scheme.<o:= p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= 2. Break the core specification into multiple parts.<o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Go back to the origi= nal working group consensus to break the document into two parts: getting a= token and using a token. Getting a token will include everything from core= expect for section 5. Section 5 will become a new specification which will= describe how to use a bearer token (replacing the generic ‘OAuthR= 17; scheme with something more descriptive like). <o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>3. Introduce two sig= nature proposals in one or more documents, for the JSON token and 1.0a-like= method.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>One, both, or none can become working group item.<o:p></o:p></= p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>--- Benefi= ts<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal>1. Remove the HTTP binding from the core specification, leaving it tra= nsport agnostic for using access tokens.<o:p></o:p></p><p class=3DMsoNormal= ><o:p> </o:p></p><p class=3DMsoNormal>2. Solve a few open issues:<o:p>= </o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>* = Concerns over bearer tokens as the preferred/promoted/default token method.= <o:p></o:p></p><p class=3DMsoNormal>* The use of one or more HTTP authentic= ation schemes, and the general architecture of using tokens.<o:p></o:p></p>= <p class=3DMsoNormal>* Issues around scheme names.<o:p></o:p></p><p class= =3DMsoNormal>* Concerns over requiring HTTPS will be limited to only one pa= rt of the protocol.<o:p></o:p></p><p class=3DMsoNormal>* The need to pick o= ne signature format.<o:p></o:p></p><p class=3DMsoNormal>* The need to finis= h signatures before the core (‘how to get an access token’).<o:= p></o:p></p><p class=3DMsoNormal>* The need to decide on discovery for the = entire protocol (moves it to each scheme).<o:p></o:p></p><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoNormal>3. Allow moving the core speci= fication to last call within a few weeks (and maybe also the bearer token p= art).<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMs= oNormal>--- Downside<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></= p><p class=3DMsoNormal>The only downside of this approach is that people wi= ll need to read at least two documents. It will not take any more effort or= time, just some guidance.<o:p></o:p></p><p class=3DMsoNormal><o:p> </= o:p></p><p class=3DMsoNormal>--- Request for feedback<o:p></o:p></p><p clas= s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>This proposal repre= sents a purely editorial compromise. I believe it gives everyone enough to = move forward. It has no impact on implementations. By breaking the problem = into pieces, we allow those who strongly disagree to simply disengage that = work and focus on the parts that matter to them.<o:p></o:p></p><p class=3DM= soNormal><o:p> </o:p></p><p class=3DMsoNormal>EHL<o:p></o:p></p><p cla= ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p><= /p></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343D460DC0BBP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Sat Oct 2 09:51:31 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA19E3A6E96 for <oauth@core3.amsl.com>; Sat, 2 Oct 2010 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKnZ4b31kiIw for <oauth@core3.amsl.com>; Sat, 2 Oct 2010 09:51:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 218F23A6C5A for <oauth@ietf.org>; Sat, 2 Oct 2010 09:51:30 -0700 (PDT) Received: by iwn3 with SMTP id 3so6108116iwn.31 for <oauth@ietf.org>; Sat, 02 Oct 2010 09:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UDrRh0mtvNfdrcYLTIamo2wlmA6a/jVcpVIJpga8U9I=; b=A9+6ucWEgIcKFjqEaa0ciGd5hnP5yvoEI5nD6KJ7K7j4cheMSXzAcrgGH0L6KbuZA6 gbKbl65Qk3dBShbUORoe6ix4mvzgtahX2kDXzZ7heYVT93fg1Qys64xbFiKsmL39NFgo WmnJ+sQihRPGO//wU5QbX+9m+Ol8GVNafd+pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XoBndVSy+Mw4o0+95RQq2JdsDnSdgSHNF6xPytiahgu/WSkD4nWHoZfK/hRq61kZ3C gctbJjW7FpxJUD4Y0ajZ6pXkm3ZxYCBwCpVzlOXICdDZzeWgZwazj/HqmYSTZ6M83Cpy MLOC7fjW1DgJj9nN2M/Xi9z3xH8fAzVg2U4f8= MIME-Version: 1.0 Received: by 10.231.35.77 with SMTP id o13mr7462948ibd.92.1286038340917; Sat, 02 Oct 2010 09:52:20 -0700 (PDT) Received: by 10.231.154.213 with HTTP; Sat, 2 Oct 2010 09:52:20 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DC0BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D460DC0BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 2 Oct 2010 09:52:20 -0700 Message-ID: <AANLkTinR=u2+kb7GD_pfY=rgqPGUvuMi9a-F0sFXH=JS@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 02 Oct 2010 16:51:31 -0000 I support breaking the document into two parts. Methods to access APIs are not going to be many -- there are currently two proposals on the table, OAuth1.0-like signatures and signed JSON tokens -- but the existing proposals are fundamentally different. There's probably little to gain in writing them together. In particular, they require completely different security considerations treatment. On the other hand, the methods to obtain tokens are already many, and I suspect that future use cases will appear that will lead to new ways to obtain tokens [1]. However varied these methods may be, they seem to share enough context that reading them together is not confusing. [1] For e.g., There is a variety of mechanisms to authenticate users that do not involve HTTP but need to provide a bridge to authenticate users to web-based APIs. Even for HTTP-based authentication, there is precedent established by OAuth1.0(a) -- one example of a flow not covered in the protocol spec would be the OpenID+OAuth extension. On Fri, Oct 1, 2010 at 9:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > Given the overwhelming support for this proposal, I am officially asking = the > chairs to make a consensus call to break the current document into two > parts. This will be done with the understanding that the result will be > reviewed by the working group again once the parts are stable to determin= e > if it compromises the overall readability and security analysis of the > protocol. > > > > I am also requesting that the chairs assign a new editor for the bearer > token part of the specification. I will continue as editor on the =91how = to > obtain a token=92 part, and will also publish an individual submission I-= D for > an alternative signature proposal based on my proposal in the -05 draft. > > > > EHL > > > > > > From: Eran Hammer-Lahav > Sent: Monday, September 27, 2010 11:26 PM > > To: OAuth WG (oauth@ietf.org) > Subject: Looking for a compromise on signatures and other open issues > > > > (Please take a break from the other threads and read this with an open mi= nd. > I have tried to make this both informative and balanced.) > > > > --- IETF Process > > > > For those unfamiliar with the IETF process, we operate using rough > consensus. This means most people agree and no one strongly objects. If > someone strongly objects, it takes a very unified group to ignore that > person, with full documentation of why the group chose to do so. That per= son > can raise the issue again during working group last call, area director > review, and IETF last call - each has the potential to trigger another ro= und > of discussions with a wider audience. That person can also appeal the > working group decision before it is approved as an RFC. > > > > The process is managed by the working group chairs. The chairs elect the > editor and make consensus calls. So far this working group had only a few > consensus calls (breaking the 1.0a RFC into two parts and dropping these = in > favor of a unified WRAP + 1.0a draft). From my experience and understandi= ng > of the process, this working group does not have rough consensus on any o= f > the open items to make consensus calls and close the issues. Simply > dismissing the few objections raised will not accomplish finishing the > document sooner, but will only add more rounds of debates now and at a la= ter > time. > > > > One of the problems we have is that we work without a charter. Usually, t= he > charter is the most useful tool chairs have when limiting scope and closi= ng > debates. For example, had we fixed the charter last year to explicitly sa= y > that we will publish one document with both bearer tokens and signatures, > the chairs could have ended this argument by pointing to the charter. Sin= ce > we have no charter, the chairs have little to offer in terms of ending th= ese > disagreements. We never officially agreed what we are here to solve. > > > > The reality of this working group is that we need to find a way to make > everyone happy. That includes every one of those expressing strong opinio= ns. > Any attempt to push people around, dismiss their views, or reject reasona= ble > compromises will just keep the issues open. If this small group cannot re= ach > agreement, the specification will surely fall apart during working group > last call, area director review, IETF last call, application area review, > security area review, general area review, IANA review, and IESG review. > > > > It=92s a long process, and at each step, anyone can raise their hand and > object. A united working group is the most important tool to end discussi= ons > over objections and concerns raised at each step. It also give people the > confidence to implement a working group final draft before it is publishe= d > as an RFC (because it is much less likely to change). > > > > --- Open Issues > > > > This working group has failed to reach consensus on a long list of items, > among them are the inclusion of signatures, signatures format, use of HTT= P > authentication headers, restrictions on bearer tokens, support for specif= ic > profiles, etc. While many of these items faded away, I would not be surpr= ise > to see them all come back. > > > > The current argument over signatures ignores compromises and agreements > reached over the past two years. This working group explicitly rejected W= RAP > as the replacement for OAuth 1.0 and the whole point of combining 1.0a wi= th > WRAP was the inclusion of signatures. We reached another agreement to kee= p > signatures at the Anaheim meeting. The current draft is a version of WRAP > alone. > > > > There are currently three separate threads going on: > > > > 1. OAuth 1.0a style signatures vs. JSON proposals > > 2. Including a signature mechanism in core > > 3. Concerns about bearer tokens and HTTPS > > > > The first item will not be resolved because we are not going to reach > industry consensus over a single signature algorithm (this is a general > comment, not specific to these two proposals). The only thing we can do i= s > let those who care about each solution publish their own specification an= d > let the market decide. > > > > The second item, while it was part of the very first compromise this work= ing > group made (when we combined the two specifications), cannot be resolved > because of #1. We can=92t agree on which signature method to include, and > including all is not practical. For these reasons, including a signature > algorithm in core is not likely to happen. I have made some proposals but > they received instant negative feedback which means we have no consensus. > > > > The third item has also been debated and blogged for a long time and is n= ot > going to be resolved in consensus. Instead, we will need to find the righ= t > language to balance security concerns with the reality that many provider= s > are going to deploy bearer tokens no matter what the IETF says. The OAuth > 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTP= S, > and I would expect the same issue to come up with the current draft. > > > > --- Proposal > > > > 1. Add a parameter to the token response to include an extensible token > scheme. > > > > The default (if omitted) will be whatever the bearer token scheme is call= ed. > This will allow the authorization server to return any token type it deem= s > appropriate, and for other specifications to define additional parameters > such as token_secret. Others can extend the token request endpoint by all= ow > the client to request a specific token scheme. > > > > 2. Break the core specification into multiple parts. > > > > Go back to the original working group consensus to break the document int= o > two parts: getting a token and using a token. Getting a token will includ= e > everything from core expect for section 5. Section 5 will become a new > specification which will describe how to use a bearer token (replacing th= e > generic =91OAuth=92 scheme with something more descriptive like). > > > > 3. Introduce two signature proposals in one or more documents, for the JS= ON > token and 1.0a-like method. > > > > One, both, or none can become working group item. > > > > --- Benefits > > > > 1. Remove the HTTP binding from the core specification, leaving it transp= ort > agnostic for using access tokens. > > > > 2. Solve a few open issues: > > > > * Concerns over bearer tokens as the preferred/promoted/default token > method. > > * The use of one or more HTTP authentication schemes, and the general > architecture of using tokens. > > * Issues around scheme names. > > * Concerns over requiring HTTPS will be limited to only one part of the > protocol. > > * The need to pick one signature format. > > * The need to finish signatures before the core (=91how to get an access > token=92). > > * The need to decide on discovery for the entire protocol (moves it to ea= ch > scheme). > > > > 3. Allow moving the core specification to last call within a few weeks (a= nd > maybe also the bearer token part). > > > > --- Downside > > > > The only downside of this approach is that people will need to read at le= ast > two documents. It will not take any more effort or time, just some guidan= ce. > > > > --- Request for feedback > > > > This proposal represents a purely editorial compromise. I believe it give= s > everyone enough to move forward. It has no impact on implementations. By > breaking the problem into pieces, we allow those who strongly disagree to > simply disengage that work and focus on the parts that matter to them. > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Breno de Medeiros From tonynad@microsoft.com Mon Oct 4 00:36:53 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38343A6E4B for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 00:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.291 X-Spam-Level: X-Spam-Status: No, score=-10.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl4XfkDn5El7 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 00:36:41 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B80CE3A6F3A for <oauth@ietf.org>; Mon, 4 Oct 2010 00:36:40 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Oct 2010 00:37:23 -0700 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.145]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0218.012; Mon, 4 Oct 2010 00:37:23 -0700 From: Anthony Nadalin <tonynad@microsoft.com> To: Dirk Balfanz <balfanz@google.com>, Yaron Goland <yarong@microsoft.com> Thread-Topic: [OAUTH-WG] Comparing the JSON Token drafts Thread-Index: Actepo9jOHYKrp9WTw+gSIlGeIAPVgAxfo4AAB+fEkAAc5aNgAAZXjwAAF3pQcA= Date: Mon, 4 Oct 2010 07:37:22 +0000 Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> In-Reply-To: <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_1990A18DEA6E97429CFD1B4D2C5DA7E70D88DATK5EX14MBXC101red_" MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 07:36:53 -0000 --_000_1990A18DEA6E97429CFD1B4D2C5DA7E70D88DATK5EX14MBXC101red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't believe that negotiation (policy) has to be part of this proposal, = so in the spec if one of the claims is not supported then the token MUST no= t be processed. We have this today in the web services security stack and t= here are really no issues. From: Dirk Balfanz [mailto:balfanz@google.com] Sent: Friday, October 01, 2010 8:45 PM To: Yaron Goland Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com<mailto:y= arong@microsoft.com>> wrote: No matter what algorithm or key size we pick the choice will prove unsuppor= table for any number of implementers due to everything from security issues= (no matter what key size we pick, someone will have a real need for someth= ing larger) to legal issues (various countries have their own opinions abou= t what to use where, a la the NSA suite list). So we are going to have to support multiple algorithms and we are going to = have to deal with algorithm negotiation. I literally can see no way around = that. I agree that over time, what will be considered secure will change. I also = agree that usually this means that there is some sort of negotiation happen= ing on what the two parties support. How would that happen here? Remember t= hat - as one datapoint - Google won't be able to support the ECC algorithm.= What happens when you can't support one of the proposed algorithms, and th= ere is no provision in the protocol to signal this to other parties? Dirk. Yaron From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Anthony Nadali= n Sent: Wednesday, September 29, 2010 8:34 AM To: Dirk Balfanz; Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts > So this one I do feel more strongly about: We should only include crypto = mechanisms that everybody MUST support. Otherwise, we'll have to invent som= e sort of negotiation step in the protocol: "do you support alg XYZ? No I d= on't, > please use ABC". Let's not do that. >As just one datapoint, Google would have a hard time supporting ECC, since= it's not in the Java core library. We don't use bouncycastle. I agree that there can be license issues that one could encounter with ECC = (as we all did with RSA), there are already customers that require ECC, and= so there is a need to have alternative algorithms that you don't have to s= upport. We already have the issue of "do you support" with claims and token= types, etc From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Dirk Balfanz Sent: Tuesday, September 28, 2010 10:23 AM To: Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com<ma= ilto:Michael.Jones@microsoft.com>> wrote: Dirk and I both posted JSON Token drafts on Thursday. They are at http://b= alfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'l= l refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-j= son-web-token-00.html (which I'll refer to as JWT). This note points out s= ome of the differences (and commonalities) in the interest of building cons= ensus towards a unified approach. Commonalities: * Both have ways of expressing the signature algorithm, token issue= r, token expiration time, and intended audience. * Both use a form of base64url encoding of the JSON claim data. * Both require support for the HMAC SHA-256 signature algorithm, an= d describe how to sign with RSA SHA-256 as well. Differences: * Dirk's draft uses a base64url encoding that may include one or tw= o '=3D' pad characters. The JWT draft uses base64url encoding without padd= ing. * JWT uses shorter claim names in the interest of brevity ("iss", "= exp", and "aud", versus "issuer", "not_after", and "audience"). * JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA= , and ECDSA with longer key lengths. * Dirk's tokens must be signed, whereas signing JWTs is optional. * Dirk's draft provides for a key_id parameter and a means of seria= lizing keys. * Dirk's draft utilizes a Magic Signatures envelope, whereas the on= ly "envelope" component of a JWT is the encoded signature. * Dirk's draft proposes that a particular discovery mechanism be us= ed with JSON tokens. Let me tackle the differences one at a time, in hopes of driving towards a = consensus position. Hi there - thanks for writhing this up. Comments below: * To pad or not to pad: The '=3D' pad characters add length, are n= ot URL-safe (and therefore must be escaped when used in URLs, adding more l= ength), and add no information. Therefore, I would propose that we agree n= ot to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf.or= g/html/rfc4648#section-5>), especially since a no-padding implementation is= trivial, as shown in JWT Section 13<http://self-issued.info/docs/draft-gol= and-json-web-token-00.html#base64urlnotes>. I don't feel strongly about this, but remember John Panzer's cautionary tal= es here: Apparently, padding-less encoding is not well-supported in some fr= ameworks, which can lead to confusion. * Claim name length: Given that a core goal of both specs is short = tokens, I would propose that we use the shorter reserved claim names. Havi= ng short tokens is especially important when used with mobile browsers, whe= re URL length restrictions may be severe. (People are always free to use l= onger ones in any particular application context if they have a reason to d= o so.) I don't feel strongly about this, but I think many people do want to have m= ore descriptive names here. * Elliptic curve crypto and longer key lengths: The JWT spec defin= es how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Su= ite B<http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> and t= hat it has engineering advantages over RSA (shorter key lengths and more ef= ficient computations), it makes sense that any modern spec incorporating cr= yptography allow its use as an option. Likewise, it makes sense for the sp= ec to define how to use longer key lengths on an optional basis. So this one I do feel more strongly about: We should only include crypto me= chanisms that everybody MUST support. Otherwise, we'll have to invent some = sort of negotiation step in the protocol: "do you support alg XYZ? No I don= 't, please use ABC". Let's not do that. As just one datapoint, Google would have a hard time supporting ECC, since = it's not in the Java core library. We don't use bouncycastle. * Unsigned tokens: In some application contexts, it may make sense= to send unsigned tokens if carried in a signed and/or encrypted container = or channel. Allowing for unsigned tokens means that double signing need no= t occur. That one just confuses me :-) What's the difference between OAuth without s= ignatures and unsigned tokens? Is the latter not just a more complicated wa= y of doing the former? * Key identification: I agree that having means of identifying and= distributing keys are critical for to end-to-end security of signed tokens= . That's a separate point from whether the key identification and distribu= tion mechanisms should be part of the token format specification, or treate= d separately. I would advocate that it be treated separately (as was done = with SWTs as well), but am open to discussion on this point. * Discovery: Like key distribution, I believe that an agreement on= discovery mechanisms is critical to many use cases. But like key distribu= tion, I'd like us to take that up in a separate specification, rather than = tightly binding the use of JSON tokens to a particular discovery mechanism. Here is where I'm coming from: I find the public-key versions of the signat= ures much more intriguing - they allow for easier key management, key rotat= ion, etc. To actually reap the benefits of key rotation, though, we need to= say how to find out what the currently-used key is. If we don't, then a lo= t of the potential advantage of using public keys evaporates. I'm concerned= that, lacking the discovery spec, developers will start hard-coding keys i= nto their servers, and we'll end up in a situation where we can't rotate ke= ys when Something Bad happens. * Envelope structure: Dirk's draft proposes that the signed conten= t be wrapped in a particular kind of envelope. Among other things, this en= velope can help prevent a token from being repurposed from one context to a= nother, by having a clear (and cryptographically verified) declaration that= "This is a JSON token". I understand this motivation and am open to discu= ssions on how to best achieve it, while still providing as little mechanism= as possible (but no less :)). Well, you've seen my proposal on how to achieve it :-), but I'm also open t= o better ways, if someone comes up with one... Dirk. Dirk, and others, please jump in! -- Mike --_000_1990A18DEA6E97429CFD1B4D2C5DA7E70D88DATK5EX14MBXC101red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I don’t believe tha= t negotiation (policy) has to be part of this proposal, so in the spec if o= ne of the claims is not supported then the token MUST not be processed. We have this today in the web services security stack and there are really= no issues.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Dirk Bal= fanz [mailto:balfanz@google.com] <br> <b>Sent:</b> Friday, October 01, 2010 8:45 PM<br> <b>To:</b> Yaron Goland<br> <b>Cc:</b> Anthony Nadalin; Mike Jones; oauth@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <<a = href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a>> wrote:<o:= p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">No matter what algo= rithm or key size we pick the choice will prove unsupportable for any numbe= r of implementers due to everything from security issues (no matter what key size we pick, someone will have a real= need for something larger) to legal issues (various countries have their o= wn opinions about what to use where, a la the NSA suite list). </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">So we are going to = have to support multiple algorithms and we are going to have to deal with a= lgorithm negotiation. I literally can see no way around that.</span><o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I agree that over time, what will be considered secu= re will change. I also agree that usually this means that there is some sor= t of negotiation happening on what the two parties support. How would that = happen here? Remember that - as one datapoint - Google won't be able to support the ECC algorithm. What happen= s when you can't support one of the proposed algorithms, and there is no pr= ovision in the protocol to signal this to other parties?<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">   &= nbsp;           &nbs= p;            &= nbsp;   Yaron</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span><o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">></span> So this= one I do feel more strongly about: We should only include crypto mechanism= s that everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: "= do you support alg XYZ? No I don't, > please use ABC". Let's not do= that. <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">>As just one datapoint, Google would have a hard time supportin= g ECC, since it's not in the Java core library. We don't use bouncycastle.<= o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">I agree that there = can be license issues that one could encounter with ECC (as we all did with= RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that yo= u don’t have to support. We already have the issue of “do you s= upport” with claims and token types, etc</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a href=3D"mailto:= Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@microsoft.com<= /a>> wrote:<o:p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk and I both posted JSON Token drafts on Thursday.  They a= re at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I’ll refer to as Dirk’s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I’ll refer to as JWT).  This note points out some of the differ= ences (and commonalities) in the interest of building consensus towards a u= nified approach.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Commonalities:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both use a form of base64url encoding of the JSON claim data.<o:p></= o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Differences:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft uses a base64url encoding that may include one or= two ‘=3D’ pad characters.  The JWT draft uses base64url e= ncoding without padding.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT uses shorter claim names in the interest of brevity (“iss&= #8221;, “exp”, and “aud”, versus “issuer̶= 1;, “not_after”, and “audience”).<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s tokens must be signed, whereas signing JWTs is optional= .<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft provides for a key_id parameter and a means of se= rializing keys.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft utilizes a Magic Signatures envelope, whereas the= only “envelope” component of a JWT is the encoded signature.<o= :p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft proposes that a particular discovery mechanism be= used with JSON tokens.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Let me tackle the differences one at a time, in hopes of driving t= owards a consensus position.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Hi there - thanks for writhing this up. Comments below:<o:p></o:p>= </p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>To pad or not to pad:</b>  The ‘=3D’ pad charact= ers add length, are not URL-safe (and therefore must be escaped when used i= n URLs, adding more length), and add no information.  Therefore, I wou= ld propose that we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but remember John Panzer's cauti= onary tales here: Apparently, padding-less encoding is not well-supported i= n some frameworks, which can lead to confusion.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.&n= bsp; Having short tokens is especially important when used with mobile brow= sers, where URL length restrictions may be severe.  (People are always free to use longer ones in any particu= lar application context if they have a reason to do so.)<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but I think many people do want = to have more descriptive names here. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Elliptic curve crypto and longer key lengths:</b>  The JWT s= pec defines how to use ECC as well as HMAC and RSA.  Given ECC’s= inclusion in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.  Likewise,= it makes sense for the spec to define how to use longer key lengths on an optional basis.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">So this one I do feel more strongly about: We should only include = crypto mechanisms that everybody MUST support. Otherwise, we'll have to inv= ent some sort of negotiation step in the protocol: "do you support alg XYZ? No I don't, please use ABC&quo= t;. Let's not do that. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">As just one datapoint, Google would have a hard time supporting EC= C, since it's not in the Java core library. We don't use bouncycastle.<o:p>= </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Unsigned tokens:</b>  In some application contexts, it may m= ake sense to send unsigned tokens if carried in a signed and/or encrypted c= ontainer or channel.  Allowing for unsigned tokens means that double s= igning need not occur.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">That one just confuses me :-) What's the difference between OAuth = without signatures and unsigned tokens? Is the latter not just a more compl= icated way of doing the former? <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Key identification:</b>  I agree that having means of identi= fying and distributing keys are critical for to end-to-end security of sign= ed tokens.  That’s a separate point from whether the key identif= ication and distribution mechanisms should be part of the token format specification, or treated separately.  I would ad= vocate that it be treated separately (as was done with SWTs as well), but a= m open to discussion on this point.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Discovery:</b>  Like key distribution, I believe that an agr= eement on discovery mechanisms is critical to many use cases.  But lik= e key distribution, I’d like us to take that up in a separate specifi= cation, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Here is where I'm coming from: I find the public-key versions of t= he signatures much more intriguing - they allow for easier key management, = key rotation, etc. To actually reap the benefits of key rotation, though, we need to say how to find out what = the currently-used key is. If we don't, then a lot of the potential advanta= ge of using public keys evaporates. I'm concerned that, lacking the discove= ry spec, developers will start hard-coding keys into their servers, and we'll end up in a situation where we can't ro= tate keys when Something Bad happens.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>E= nvelope structure:</b>  Dirk’s draft proposes that the signed co= ntent be wrapped in a particular kind of envelope.  Among other things= , this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that “This is a JSON = token”.  I understand this motivation and am open to discussions= on how to best achieve it, while still providing as little mechanism as possible (but no less <span style=3D"font-fami= ly:Wingdings">J</span>).<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Well, you've seen my proposal on how to achieve it :-), but I'm al= so open to better ways, if someone comes up with one...<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk, and others, please jump in!<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =             &nb= sp;            =             &nb= sp;            =    -- Mike<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </div> </div> </div> </blockquote> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_1990A18DEA6E97429CFD1B4D2C5DA7E70D88DATK5EX14MBXC101red_-- From skylar@kiva.org Mon Oct 4 05:03:11 2010 Return-Path: <skylar@kiva.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB2E3A6F84 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 05:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqhk60bxK548 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 05:03:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A31593A6F83 for <oauth@ietf.org>; Mon, 4 Oct 2010 05:03:09 -0700 (PDT) Received: by wwj40 with SMTP id 40so2849440wwj.13 for <oauth@ietf.org>; Mon, 04 Oct 2010 05:04:04 -0700 (PDT) Received: by 10.216.164.66 with SMTP id b44mr5136144wel.81.1286193844012; Mon, 04 Oct 2010 05:04:04 -0700 (PDT) Received: from larwmobile.home (AMontsouris-756-1-25-119.w92-128.abo.wanadoo.fr [92.128.0.119]) by mx.google.com with ESMTPS id x33sm2913987weq.47.2010.10.04.05.04.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 05:04:02 -0700 (PDT) From: Skylar Woodward <skylar@kiva.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 14:03:59 +0200 Message-Id: <E2A56EAC-0477-425A-A051-5A46899E8887@kiva.org> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] On splitting the spec and the scope of signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 12:03:11 -0000 Apologies in advance for adding a new thread, but I've only just = switched from digest mode. I'm jumping into the middle of the discussion = as our organization (kiva.org) is in the process of becoming an OAuth = provider and we're planning to start with a OAuth 2.0-based API (or = nearly so) out of the gate. As such, we have an interest in seeing 2.0 = finalized, and hopefully in a way that suits Kiva's needs (protecting = user's and partner's financial data, and being agile - we're a small = non-profit compared to many organizations active in the discussion). +1 for signatures (If I may be so bold on the first post). I'll = withhold other votes until we've had time to digest more of this. Meanwhile, I'd like to throw out a strawman for splitting the = specification in a different way - that is, by guarantee-able security = contexts rather than by sequence, as in getting vs. using tokens. (I'm = know everyone has voted on Eran's proposal and I don't mean to impede = progress - this suggestion is easily enough ignored if it's found to be = without sufficient merit.) In OAuth 1.0, it always troubled me that two dramatically different use = cases co-existed in the same specification. For discussion purposes can = call these two the Web Server use case and the User App use case. In = terms of OAuth mechanics, you might see these two as apps that can = protect a client secret, and those that can't. In the pre-OAuth days at = Yahoo! this had evolved as BBAuth and CBAuth (client-based auth), since = we had decided that the inability of (consumer device-base) clients to = keep secrets justified an independent spec and set of best practices. Now, I'm going to digress a bit and talk our history with all this in = building Fire Eagle at Yahoo!... When the team first committed to OAuth = and was digesting the specification, it took a while for the team as a = whole to get our head around the fact that we couldn't offer the same = level of security/privacy to users of User Apps (desktop, iPhone, etc.) = vs. users of Web Server apps (dopplr, etc.). The OAuth spec presented a = single system for everyone based on mechanics most of us knew well = (flickr, bbauth, etc.) and most people on the team knew webs apps well = but few had experience building downloadable client apps. That meant we = often focused on the flows and security provided by Web Server apps. = After struggling through it all and the evolving OAuth spec, we hand a = good handle on the differences, and thus, in the end, we supported = different capabilities to Web apps vs. Desktop/Mobile apps. We also = forced developers to choose their type of app on sign-up because we = thought it was important they also understood this difference too so = they could best uphold the contract they had conveyed to their users = (and ours) both in their UI and in how they might use their client = secrets. The unfortunate part of all this is that desktop apps and smartphone = apps were unnecessarily complex based on the contract they provided. At = the same time we were just ahead of a tidal wave of new User App = development that few people would have expected as Apple's app store = (and all the trends that followed) didn't exist yet. So being a = minority, there wasn't much of a push to create a different flow for = User App types - they were just to use the same mechanics as Web Server = apps. A bit of a compromise was PLAINTEXT signing, which let apps (who = already had their client secrets in the clear) just put them in the API = calls to avoid complex signatures. This worked for us as we also = eventually committed to SSL-based connections for everything on the = basis that all data we were transmitting was user-private anyway. = However, User Apps still had to do the whole OAuth dance which I'm = guessing has become more and more annoying as smartphone client = development has increased. Thus, what you guys are doing is great because OAuth 2.0 lets those = unable to protect their secrets dismiss all the crud designed for = server-server systems. v10 proposes something so simple, you might not = even need a client lib to get your API off the ground. However, I'm = afraid what has been lost is all the extra security and potential that = is still offered by OAuth 1.0. In a sense, the split I would propose is already achieved by OAuth 2.0 = and OAuth 1.0. The problem is that most people will see 2.0 as an = "upgrade" to 1.0 rather than a reduced and simplified security model. If = you add signatures, it's 1.0 but with the focus on the less secure = transactions out of the gate. If you split the spec on access = token/usage it seems to weaken the system entirely to something that = needs to be brought back together in a parent spec (as the ICE spec did = for all the disparate P2P/VoIP specs) for it to have value. Then, I'd = fear you actually end up with two parent specs - one that ties things = together for apps that can keep secrets, and another for those that = can't. Another alternative strawman to my own strawman would be to postpose the = final OAuth 2.0 and start with "OAuth for Devices." That is, it's OAuth = without client identity enforced. This allows Google, Facebook and = others to proceed with something equally secure to WRAP or similar = implementations they have now. Then, you could proceed by adapting 1.0 = mechanics for apps with client identity in the 2.0 style (including = other improvements/provisions made) to a final spec and resolve all the = tension with how to combine these very different experiences and = contracts into one spec. Hopefully, you'll also end up with two basic = mechanics that work for lots of people rather than one mix of rules that = are highly adapted on a case-by-case basis resulting a myriad of = resulting mechanics that aren't interoperable and likely also devalue at = the end of the day what it means to be "OAuth compliant." In any case, thanks to everyone here for working hard to hammer out = something for the rest of the world. Our resources are limited, but I'll = contribute where it seems helpful or if what's evolving seems contrary = to Kiva's API security needs. skylar From gffletch@aol.com Mon Oct 4 09:19:40 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED1E3A6FD9 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCgnIDAnkhZ6 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 09:19:35 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id 2BB813A6CAB for <oauth@ietf.org>; Mon, 4 Oct 2010 09:19:35 -0700 (PDT) Received: from mtaout-da02.r1000.mx.aol.com (mtaout-da02.r1000.mx.aol.com [172.29.51.130]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o94GJxu7015788; Mon, 4 Oct 2010 12:19:59 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5EF47E000087; Mon, 4 Oct 2010 12:19:58 -0400 (EDT) Message-ID: <4CA9FEAC.8090407@aol.com> Date: Mon, 04 Oct 2010 12:19:56 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------010205030904060000090408" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:466027680:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33824ca9feae4517 X-AOL-IP: 10.181.183.108 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 16:19:40 -0000 This is a multi-part message in MIME format. --------------010205030904060000090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Zachary, Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case. Thanks, George Use case: Signed Messages Description: Alice manages all her personal health records in her personal health data store (www.myhealth.example.com). Alice's Primary Care Physician (www.pcp.example.com) recommends that Alice see a sleep specialist (www.sleepwell.example.com). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at www.pcp.example.com verifies that Alice has authorized www.sleepwell.example.com to access her health data as well as enforces that www.sleepwell.example.com is the only application that can retrieve that data with that specific authorization. Pre-conditions: * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc). * The application at www.myhealth.example.com manages authorization of access to Alice's participating health systems * The application at www.myhealth.example.com can issues authorization tokens understood by Alice's participating health systems * The application at www.pcp.example.com stores Alice's basic health and prescription records * The application at www.sleepwell.com stores results of Alice's sleep tests Post-conditions: * A successful procedure results in just the information that Alice authorized being transferred from the Primary Care Physician (www.pcp.example.com) to the sleep specialist (www.sleepwell.example.com). * The transfer of health data only occurs if the application at www.pcp.example.com can verify that www.sleepwell.example.com is the party requesting access and that the authorization token presented by www.sleepwell.example.com is issued by the application at www.myhealth.example.com with a restricted audience of www.sleepwell.example.com Requirements: * The application at www.sleepwell.example.com accesses www.myhealth.example.com to discover the location of the PCP system (XRD discovery) * The application at www.sleepwell.example.com requests Alice to authorize access to the application at www.pcp.example.com for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case. * The application at www.myhealth.example.com issues a token bound to www.sleepwell.example.com for access to the application at www.pcp.example.com. Note that a signed token (JWT) can be used to prove who issued the token. * The application at www.sleepwell.example.com constructs a request (includes the token issued by www.myhealth.example.com) to the application at www.pcp.example.com * The application at www.sleepwell.example.com signs the request before sending it to www.pcp.example.com * The application at www.pcp.example.com receives the request and verifies the signature * The application at www.pcp.example.com parses the message and finds the authorization token * The application at www.pcp.example.com verifies the signature of the authorization token * The application at www.pcp.example.com parses the authorization token and verifies that this token was issued to the application at www.sleepwell.com * The application at www.pcp.example.com retrieves the requested data and returns it to the application at www.sleepwell.example.com On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: > > These use cases are not in the draft > https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth. > > Could you write them up? > > Thanks, > > Zachary > > ------------------------------------------------------------------------ > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *George Fletcher > *Sent:* Tuesday, September 28, 2010 11:39 AM > *To:* OAuth WG > *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? > > I think of the signature issues as falling into two classes... I think > they map to your classification as well... > > * *Signing tokens* is important for interoperability especially > looking forward to a time when tokens issued by multiple > Authorization Servers are accepted at a given host. > * *Signing messages* is important because it provides a mechanism > to ensure that the entity making the API call (and presenting an > access token) is really the entity that is allowed to make the > API call. > > Signing messages applies to the re-delegation use cases. I've heard > the need for this class of use cases from both the hData (health data) > community as well as the user managed access (UMA) community. > > Signing tokens covers both your second class of tokens as well as > another use case that Eran has mentioned as well. Namely, a protected > resource server honoring tokens from multiple Authorization Servers. > > These are the two classes of use cases that I'd like to see solved. > > Thanks, > George > > > On 9/28/10 12:58 AM, David Recordon wrote: > > If you know me then you'll know that I'm generally one of the last > people to talk about Alice and Bob. That said, there are a lot of > technical proposals flying across the list with very little shared > understanding of the problem(s) we're trying to solve. > > From what I've seen there are two distinct classes of signature use cases. > > 1) The first is where the HTTP request parameters must be part of the > signature. An example is any OAuth 1.0a style API where you want to > make sure that the HTTP POST your server just received isn't > masquerading itself as a GET. > > 2) The second is where the HTTP request is orthogonal. An example > is OpenSocial where the server is sending state information to the > client such as what user is currently logged in. > > The main practical example I have of the first use case is what > Twitter wants to do with redelegation. In this case TweetDeck can't > given TwitPic it's own bearer token, but needs to sign the POST > request and pass that signature to TwitPic for it to include in the > final API request to Twitter. > > In terms of signing protected resource requests, I haven't heard > anyone bring up specific and detailed needs for this recently. > > JSON tokens pretty clearly make sense for the second class of > signature use cases and it's actually a bit hard to argue why they > would be a part of OAuth. Facebook shipped this a bit over a month ago > for canvas applications. We include a `signed_request` parameter which > is signature.base64url(JSON). Parsing it is 18 lines of PHP. > http://developers.facebook.com/docs/authentication/canvas > > This second class of use case will also be required by OpenID Connect > where the server is signing identity information and sending it to the > client. I imagine that OpenSocial will also still have it and wish to > continue relying on public key algorithms. > > So a few questions: > > * Do we want to tackle both of these classes of signatures in OAuth? > > * Why do you consider the second class part of OAuth versus something > completely separate that might happen to include an OAuth access token? > > * Is the Twitter redelegation use case the right focus for the first > class? > > * Is there an example of an OAuth 2.0 server that can't use bearer > tokens for protected resource requests and thus requires signatures? > > Thanks, > > --David > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > --------------010205030904060000090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Helvetica, Arial, sans-serif">Hi Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case.<br> <br> Thanks,<br> George<br> <br> </font><font face="Helvetica, Arial, sans-serif">Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data store (<a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) recommends that Alice see a sleep specialist (<a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies that Alice has authorized <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> to access her health data as well as enforces that <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the only application that can retrieve that data with that specific authorization.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> stores Alice's basic health and prescription records<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authorized being transferred from the Primary Care Physician (<a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>).<br> * The transfer of health data only occurs if the application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> can verify that <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the party requesting access and that the authorization token presented by <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is issued by the application at <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> with a restricted audience of <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> Requirements:<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> accesses <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> requests Alice to authorize access to the application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> issues a token bound to <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> for access to the application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>) to the application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> signs the request before sending it to <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> receives the request and verifies the signature<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the message and finds the authorization token<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a><br> * The application at <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </font><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <blockquote cite="mid:5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman"; color:black;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:130027848; mso-list-template-ids:931952956;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="Section1"> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">These use cases are not in the draft <a moz-do-not-send="true" href="https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Could you write them up?<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Thanks,<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Zachary<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <div> <div class="MsoNormal" style="text-align: center;" align="center"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt; color: windowtext;"> <hr tabindex="-1" align="center" size="2" width="100%"> </span></font></div> <p class="MsoNormal"><b><font color="black" face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext; font-weight: bold;">From:</span></font></b><font color="black" face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext;"> <a class="moz-txt-link-abbreviated" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a class="moz-txt-link-freetext" href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>] <b><span style="font-weight: bold;">On Behalf Of </span></b>George Fletcher<br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, September 28, 2010 11:39 AM<br> <b><span style="font-weight: bold;">To:</span></b> OAuth WG<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</span></font><font color="black"><span style="color: windowtext;"><o:p></o:p></span></font></p> </div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica;">I think of the signature issues as falling into two classes... I think they map to your classification as well...</span></font><o:p></o:p></p> <ul type="disc"> <li class="MsoNormal" style=""><b><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing tokens</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span></font><o:p></o:p></li> <li class="MsoNormal" style=""><b><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing messages</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.</span></font><o:p></o:p></li> </ul> <p class="MsoNormal"><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica;">Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span></font>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">From what I've seen there are two distinct classes of signature use cases.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <meta charset="utf-8"> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a href="http://developers.facebook.com/docs/authentication/canvas" moz-do-not-send="true">http://developers.facebook.com/docs/authentication/canvas</a><o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">So a few questions:<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Do we want to tackle both of these classes of signatures in OAuth?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Is the Twitter redelegation use case the right focus for the first class?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">Thanks,<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">--David<o:p></o:p></span></font></p> </div> <pre wrap=""><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><fieldset class="mimeAttachmentHeader"></fieldset><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;">_______________________________________________<o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;">OAuth mailing list<o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></span></font></pre> <p class="MsoNormal" style="margin-bottom: 12pt;"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> </blockquote> <br> </body> </html> --------------010205030904060000090408-- From tim.freeman@hp.com Mon Oct 4 10:59:33 2010 Return-Path: <tim.freeman@hp.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5D13A6CC5 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 10:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIw66wVLidRu for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 10:59:31 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by core3.amsl.com (Postfix) with ESMTP id ADC2E3A6FF9 for <oauth@ietf.org>; Mon, 4 Oct 2010 10:59:30 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 325D224481; Mon, 4 Oct 2010 18:00:26 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Oct 2010 17:59:13 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Mon, 4 Oct 2010 17:59:14 +0000 From: "Freeman, Tim" <tim.freeman@hp.com> To: George Fletcher <gffletch@aol.com>, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> Date: Mon, 4 Oct 2010 17:59:12 +0000 Thread-Topic: Signatures don't solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?) Thread-Index: Actj4BdmsXZTlqKbR7O6ddUCfcMgSgACjIqQ Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> In-Reply-To: <4CA9FEAC.8090407@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76GVW0432EXBame_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: [OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 17:59:33 -0000 --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76GVW0432EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Putting the use cases on the table is good because it makes things much cle= arer. Unfortunately, it's clear that this use case does not work. I'd like to number the steps under "Requirements" so I can refer to them un= ambiguously: 1. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> t= o discover the location of the PCP system (XRD discovery) 2. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> requests Alice to authorize access to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> for the purpose of retrieving basic he= alth data (e.g. date-of-birth, weight, height, etc). The mechanism Alice us= es to authorize this access is out of scope for this use case. 3. The application at www.myhealth.example.com<http://www.myhealth.example.= com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell= .example.com> for access to the application at www.pcp.example.com<http://w= ww.pcp.example.com>. Note that a signed token (JWT) can be used to prove wh= o issued the token. 4. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> constructs a request (includes the token issued by www.myhealth.exam= ple.com<http://www.myhealth.example.com>) to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> 5. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> signs the request before sending it to www.pcp.example.com<http://ww= w.pcp.example.com> 6. The application at www.pcp.example.com<http://www.pcp.example.com> recei= ves the request and verifies the signature 7. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the message and finds the authorization token 8. The application at www.pcp.example.com<http://www.pcp.example.com> verif= ies the signature of the authorization token 9. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the authorization token and verifies that this token was issued to the ap= plication at www.sleepwell.com<http://www.sleepwell.com> 10. The application at www.pcp.example.com<http://www.pcp.example.com> retr= ieves the requested data and returns it to the application at www.sleepwell= .example.com<http://www.sleepwell.example.com> The stated purpose of signatures is: >The application at www.pcp.example.com<http://www.pcp.example.com> verifie= s that Alice has authorized >www.sleepwell.example.com<http://www.sleepwell.example.com> to access her = health data as well as enforces >that www.sleepwell.example.com<http://www.sleepwell.example.com> is the on= ly application that can retrieve that >data with that specific authorization. I'll abbreviate domain names like "www.sleepwell.example.com" to "sleepwell= ". Bearer tokens work fine when verifying that Alice has authorized sleepwell= <http://www.sleepwell.example.com> to access her health data, so the claim = is apparently that signatures give the added benefit of enforcing that slee= pwell<http://www.sleepwell.example.com> is the only application that can re= trieve that data with that specific authorization. Unfortunately, signatures do not do that. Suppose sleepwell wanted to give= Alice's data to apneacheck. Sleepwell could follow the protocol up to ste= p 4. Then, instead of signing the request and sending the signed request t= o pcp, sleepwell could transmit the signed request to apneacheck. apneache= ck could then complete the protocol and get Alice's data from www.pcp.examp= le.com. If sleepwell has can retrive to Alice's data, and the protocol doesn't mand= ate an invasive control of sleepwell's computation and outputs, it's hopele= ss to prevent sleepwell from allowing apneacheck to retrieve Alice's data. = If all else fails, sleepwell could access Alice's data itself and then all= ow apneacheck to access the data from sleepwell. For all I know, signatures might be a solution to some problem, but they ar= en't a solution to this problem. Tim Freeman Email: tim.freeman@hp.com<mailto:tim.freeman@hp.com> Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G= eorge Fletcher Sent: Monday, October 04, 2010 9:20 AM To: Zeltsan, Zachary (Zachary) Cc: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? Hi Zachary, Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are ed= itorial changes required. I've include the list to see if others have feed = back on this use case. Thanks, George Use case: Signed Messages Description: Alice manages all her personal health records in her personal health data s= tore (www.myhealth.example.com<http://www.myhealth.example.com>). Alice's P= rimary Care Physician (www.pcp.example.com<http://www.pcp.example.com>) rec= ommends that Alice see a sleep specialist (www.sleepwell.example.com<http:/= /www.sleepwell.example.com>). Alice arrives at the sleep specialist's offic= e and authorizes it to access her basic health data from her PCP. The appli= cation at www.pcp.example.com<http://www.pcp.example.com> verifies that Ali= ce has authorized www.sleepwell.example.com<http://www.sleepwell.example.co= m> to access her health data as well as enforces that www.sleepwell.example= .com<http://www.sleepwell.example.com> is the only application that can ret= rieve that data with that specific authorization. Pre-conditions: * Alice has a personal health data store that allows for discovery of her p= articipating health systems (e.g. psychiatrist, sleep specialist, pcp, orth= odontist, ophthalmologist, etc). * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> manages authorization of access to Alice's participating health systems * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> can issues authorization tokens understood by Alice's participating hea= lth systems * The application at www.pcp.example.com<http://www.pcp.example.com> stores= Alice's basic health and prescription records * The application at www.sleepwell.com<http://www.sleepwell.com> stores res= ults of Alice's sleep tests Post-conditions: * A successful procedure results in just the information that Alice authori= zed being transferred from the Primary Care Physician (www.pcp.example.com<= http://www.pcp.example.com>) to the sleep specialist (www.sleepwell.example= .com<http://www.sleepwell.example.com>). * The transfer of health data only occurs if the application at www.pcp.exa= mple.com<http://www.pcp.example.com> can verify that www.sleepwell.example.= com<http://www.sleepwell.example.com> is the party requesting access and th= at the authorization token presented by www.sleepwell.example.com<http://ww= w.sleepwell.example.com> is issued by the application at www.myhealth.examp= le.com<http://www.myhealth.example.com> with a restricted audience of www.s= leepwell.example.com<http://www.sleepwell.example.com> Requirements: 1. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> t= o discover the location of the PCP system (XRD discovery) 2. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> requests Alice to authorize access to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> for the purpose of retrieving basic he= alth data (e.g. date-of-birth, weight, height, etc). The mechanism Alice us= es to authorize this access is out of scope for this use case. 3. The application at www.myhealth.example.com<http://www.myhealth.example.= com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell= .example.com> for access to the application at www.pcp.example.com<http://w= ww.pcp.example.com>. Note that a signed token (JWT) can be used to prove wh= o issued the token. 4. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> constructs a request (includes the token issued by www.myhealth.exam= ple.com<http://www.myhealth.example.com>) to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> 5. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> signs the request before sending it to www.pcp.example.com<http://ww= w.pcp.example.com> 6. The application at www.pcp.example.com<http://www.pcp.example.com> recei= ves the request and verifies the signature 7. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the message and finds the authorization token 8. The application at www.pcp.example.com<http://www.pcp.example.com> verif= ies the signature of the authorization token 9. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the authorization token and verifies that this token was issued to the ap= plication at www.sleepwell.com<http://www.sleepwell.com> 10. The application at www.pcp.example.com<http://www.pcp.example.com> retr= ieves the requested data and returns it to the application at www.sleepwell= .example.com<http://www.sleepwell.example.com> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: These use cases are not in the draft https://datatracker.ietf.org/doc/draft= -zeltsan-use-cases-oauth. Could you write them up? Thanks, Zachary ________________________________ From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org] On Behalf Of George Fletcher Sent: Tuesday, September 28, 2010 11:39 AM To: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? I think of the signature issues as falling into two classes... I think they= map to your classification as well... * Signing tokens is important for interoperability especially looking fo= rward to a time when tokens issued by multiple Authorization Servers are ac= cepted at a given host. * Signing messages is important because it provides a mechanism to ensur= e that the entity making the API call (and presenting an access token) is r= eally the entity that is allowed to make the API call. Signing messages applies to the re-delegation use cases. I've heard the nee= d for this class of use cases from both the hData (health data) community a= s well as the user managed access (UMA) community. Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource serve= r honoring tokens from multiple Authorization Servers. These are the two classes of use cases that I'd like to see solved. Thanks, George On 9/28/10 12:58 AM, David Recordon wrote: If you know me then you'll know that I'm generally one of the last people t= o talk about Alice and Bob. That said, there are a lot of technical proposa= ls flying across the list with very little shared understanding of the prob= lem(s) we're trying to solve. >From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signa= ture. An example is any OAuth 1.0a style API where you want to make sure th= at the HTTP POST your server just received isn't masquerading itself as a G= ET. 2) The second is where the HTTP request is orthogonal. An example is OpenSo= cial where the server is sending state information to the client such as wh= at user is currently logged in. The main practical example I have of the first use case is what Twitter wan= ts to do with redelegation. In this case TweetDeck can't given TwitPic it's= own bearer token, but needs to sign the POST request and pass that signatu= re to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bri= ng up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use= cases and it's actually a bit hard to argue why they would be a part of OA= uth. Facebook shipped this a bit over a month ago for canvas applications. = We include a `signed_request` parameter which is signature.base64url(JSON).= Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authent= ication/canvas This second class of use case will also be required by OpenID Connect where= the server is signing identity information and sending it to the client. I= imagine that OpenSocial will also still have it and wish to continue relyi= ng on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something comp= letely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class= ? * Is there an example of an OAuth 2.0 server that can't use bearer tokens = for protected resource requests and thus requires signatures? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76GVW0432EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= 40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"Times New\000D\000A Roman"; panose-1:0 0 0 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:blue; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle19 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1077285682; mso-list-template-ids:1441661176;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DWordSection1> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>Putting the use cases on the table is good because it makes things much clearer.  Unfortunately, it's clear that this use case doe= s not work.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>I'd like to number the steps under "Requirements" = so I can refer to them unambiguously:<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'> <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>1. The application at <a href=3D"http://www.sleepwell.exampl= e.com">www.sleepwell.example.com</a> accesses <a href=3D"http://www.myhealth.example.com">www.myhealth.example.c= om</a> to discover the location of the PCP system (XRD discovery)<br> 2. The application at <a href=3D"http://www.sleepwell.example.com">www.slee= pwell.example.com</a> requests Alice to authorize access to the application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> for the purpose= of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> 3. The application at <a href=3D"http://www.myhealth.example.com">www.myhea= lth.example.com</a> issues a token bound to <a href=3D"http://www.sleepwell.example.com">www.sl= eepwell.example.com</a> for access to the application at <a href=3D"http://www.pcp.example.com">www= .pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<b= r> 4. The application at <a href=3D"http://www.sleepwell.example.com">www.slee= pwell.example.com</a> constructs a request (includes the token issued by <a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a>) to t= he application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</= a><br> 5. The application at <a href=3D"http://www.sleepwell.example.com">www.slee= pwell.example.com</a> signs the request before sending it to <a href=3D"http://www.pcp.example.co= m">www.pcp.example.com</a><br> 6. The application at <a href=3D"http://www.pcp.example.com">www.pcp.exampl= e.com</a> receives the request and verifies the signature<br> 7. The application at <a href=3D"http://www.pcp.example.com">www.pcp.exampl= e.com</a> parses the message and finds the authorization token<br> 8. The application at <a href=3D"http://www.pcp.example.com">www.pcp.exampl= e.com</a> verifies the signature of the authorization token<br> 9. The application at <a href=3D"http://www.pcp.example.com">www.pcp.exampl= e.com</a> parses the authorization token and verifies that this token was issued to t= he application at <a href=3D"http://www.sleepwell.com">www.sleepwell.com</a><b= r> 10. The application at <a href=3D"http://www.pcp.example.com">www.pcp.examp= le.com</a> retrieves the requested data and returns it to the application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>The stated purpose of signatures is:<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>The application at <a href=3D"http://www.pcp.example.com= ">www.pcp.example.com</a> verifies that Alice has authorized <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>><a href=3D"http://www.sleepwell.example.com">www.sleepwe= ll.example.com</a> to access her health data as well as enforces <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>that <a href=3D"http://www.sleepwell.example.com">www.sl= eepwell.example.com</a> is the only application that can retrieve that <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>data with that specific authorization.<o:p></o:p></span>= </p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>I'll abbreviate domain names like "www.sleepwell.exampl= e.com" to "sleepwell".<br> <br> <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>Bearer tokens work fine when verifying that Alice has author= ized  <a href=3D"http://www.sleepwell.example.com">sleepwell</a> to access = her health data, so the claim is apparently that signatures give the added bene= fit of enforcing that <a href=3D"http://www.sleepwell.example.com">sleepwell</a= > is the only application that can retrieve that data with that specific authorization.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>Unfortunately, signatures do not do that.  Suppose slee= pwell wanted to give Alice's data to apneacheck.  Sleepwell could follow the protocol up to step 4.  Then, instead of signing the request and sendi= ng the signed request to pcp, sleepwell could transmit the signed request to a= pneacheck.  apneacheck could then complete the protocol and get Alice's data from www.pcp.example.com.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>If sleepwell has can retrive to Alice's data, and the protoc= ol doesn't mandate an invasive control of sleepwell's computation and outputs,= it's hopeless to prevent sleepwell from allowing apneacheck to retrieve Alice's = data.  If all else fails, sleepwell could access Alice's data itself and then allo= w apneacheck to access the data from sleepwell.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'> <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>For all I know, signatures might be a solution to some probl= em, but they aren't a solution to this problem.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;color:#1F497D'>Tim Fre= eman<br> Email: <a href=3D"mailto:tim.freeman@hp.com">tim.freeman@hp.com</a><br> Desk in Palo Alto: (650) 857-2581<br> Home: (408) 774-1298<br> Cell: (408) 348-7536<o:p></o:p></span></p> </div> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in'> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma= ","sans-serif"; color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly: "Tahoma","sans-serif";color:windowtext'> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Monday, October 04, 2010 9:20 AM<br> <b>To:</b> Zeltsan, Zachary (Zachary)<br> <b>Cc:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?<o:= p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>H= i Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are edito= rial changes required. I've include the list to see if others have feed back on = this use case.<br> <br> Thanks,<br> George<br> <br> Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data s= tore (<a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a href=3D"http://www.pcp.example.com">www.= pcp.example.com</a>) recommends that Alice see a sleep specialist (<a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a>). A= lice arrives at the sleep specialist's office and authorizes it to access her ba= sic health data from her PCP. The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> verifies that A= lice has authorized <a href=3D"http://www.sleepwell.example.com">www.sleepwell.e= xample.com</a> to access her health data as well as enforces that <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = the only application that can retrieve that data with that specific authorizati= on.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a href=3D"http://www.myhealth.example.com">www.myheal= th.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a href=3D"http://www.myhealth.example.com">www.myheal= th.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> stores Alice's basic health and prescription records<br> * The application at <a href=3D"http://www.sleepwell.com">www.sleepwell.com= </a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authori= zed being transferred from the Primary Care Physician (<a href=3D"http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a href=3D"http://www.sleepwell.example.com">www.sleepwell.exam= ple.com</a>).<br> * The transfer of health data only occurs if the application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> can verify that= <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = the party requesting access and that the authorization token presented by <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = issued by the application at <a href=3D"http://www.myhealth.example.com">www.myhea= lth.example.com</a> with a restricted audience of <a href=3D"http://www.sleepwell.example.com">= www.sleepwell.example.com</a><br> <br> Requirements:<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>1= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> acc= esses <a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a> to di= scover the location of the PCP system (XRD discovery)<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>2= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> req= uests Alice to authorize access to the application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> for the purpose= of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>3= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a> issue= s a token bound to <a href=3D"http://www.sleepwell.example.com">www.sleepwell.e= xample.com</a> for access to the application at <a href=3D"http://www.pcp.example.com">www= .pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<b= r> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>4= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a>) to t= he application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</= a><br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>5= . </span><span style=3D'font-family:"Helvetica","sans-serif"'>The application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> sig= ns the request before sending it to <a href=3D"http://www.pcp.example.com">www.pcp= .example.com</a><br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>6= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> receives the re= quest and verifies the signature<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>7= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> parses the mess= age and finds the authorization token<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>8= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>9= .</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the applicat= ion at <a href=3D"http://www.sleepwell.com">www.sleepwell.com</a><br> </span><span style=3D'font-family:"Helvetica","sans-serif";color:#1F497D'>1= 0.</span><span style=3D'font-family:"Helvetica","sans-serif"'> The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </span><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>These use cases are not in the draft <a href=3D"https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">htt= ps://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.</span><o:p= ></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Could you write them up?</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'> </span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Thanks,</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Zachary</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'> </span><o:p></o:p></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span style=3D'color:windowtext'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></div> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma= ","sans-serif"; color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly: "Tahoma","sans-serif";color:windowtext'> <a href=3D"mailto:oauth-bounces@ie= tf.org">oauth-bounces@ietf.org</a> [<a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a= >] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Tuesday, September 28, 2010 11:39 AM<br> <b>To:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</s= pan><o:p></o:p></p> </div> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>I= think of the signature issues as falling into two classes... I think they map to = your classification as well...</span><o:p></o:p></p> <ul style=3D'margin-top:0in' type=3Ddisc> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><span style=3D'= font-family: "Helvetica","sans-serif"'>Signing tokens</span></b><span style=3D'font= -family: "Helvetica","sans-serif"'> is important for interoperability especiall= y looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span><o:p></o:p></li> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><span style=3D'= font-family: "Helvetica","sans-serif"'>Signing messages</span></b><span style=3D'font-family:"Helvetica","sans-serif"'> is important because i= t provides a mechanism to ensure that the entity making the API call (an= d presenting an access token) is really the entity that is allowed to ma= ke the API call.</span><o:p></o:p></li> </ul> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>S= igning messages applies to the re-delegation use cases. I've heard the need for th= is class of use cases from both the hData (health data) community as well as t= he user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>If you know me then you'll know that I'm generally one of the last people to t= alk about Alice and Bob. That said, there are a lot of technical proposals flyi= ng across the list with very little shared understanding of the problem(s) we'= re trying to solve.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>From what I've seen there are two distinct classes of signature use cases.</span= ><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>1) The first is where the HTTP request parameters must be part of the signatur= e. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.</sp= an><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the cli= ent such as what user is currently logged in.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>The main practical example I have of the first use case is what Twitter wants t= o do with redelegation. In this case TweetDeck can't given TwitPic it's own bear= er token, but needs to sign the POST request and pass that signature to TwitPi= c for it to include in the final API request to Twitter.</span><o:p></o:p></p= > </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>In terms of signing protected resource requests, I haven't heard anyone bring = up specific and detailed needs for this recently.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>JSON tokens pretty clearly make sense for the second class of signature use case= s and it's actually a bit hard to argue why they would be a part of OAuth. Fa= cebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it i= s 18 lines of PHP. <a href=3D"http://developers.facebook.com/docs/authentication/canvas">http://d= evelopers.facebook.com/docs/authentication/canvas</a></span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imag= ine that OpenSocial will also still have it and wish to continue relying on pub= lic key algorithms.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>So a few questions:</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> * Do we want to tackle both of these classes of signatures in OAuth?</span><o= :p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> * Why do you consider the second class part of OAuth versus something complet= ely separate that might happen to include an OAuth access token?</span><o:p></o= :p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> * Is the Twitter redelegation use case the right focus for the first class?</= span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?</span><o:p></o:p>= </p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'> </span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>Thanks,</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span style=3D'font-family:"Times New = Roman","serif"'>--David</span><o:p></o:p></p> </div> <pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre>______________= _________________________________<o:p></o:p></pre><pre>OAuth mailing list<o= :p></o:p></pre><pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre><pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/m= ailman/listinfo/oauth</a><o:p></o:p></pre> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'> <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76GVW0432EXBame_-- From gffletch@aol.com Mon Oct 4 11:28:04 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE4B3A6E42 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 11:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSUJdwmU9GFO for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 11:28:01 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id A10F93A704E for <oauth@ietf.org>; Mon, 4 Oct 2010 11:28:00 -0700 (PDT) Received: from mtaout-db04.r1000.mx.aol.com (mtaout-db04.r1000.mx.aol.com [172.29.51.196]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o94ISEkm000836; Mon, 4 Oct 2010 14:28:14 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EC463E00014D; Mon, 4 Oct 2010 14:28:13 -0400 (EDT) Message-ID: <4CAA1CBB.80001@aol.com> Date: Mon, 04 Oct 2010 14:28:11 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Freeman, Tim" <tim.freeman@hp.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> Content-Type: multipart/alternative; boundary="------------030008040104020909070507" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:447038208:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c44caa1cbd3693 X-AOL-IP: 10.181.183.108 Cc: "Zeltsan, Zachary \(Zachary\)" <zachary.zeltsan@alcatel-lucent.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 18:28:04 -0000 This is a multi-part message in MIME format. --------------030008040104020909070507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Tim, Thanks for the feedback. Some comments/questions inline... On 10/4/10 1:59 PM, Freeman, Tim wrote: > > Putting the use cases on the table is good because it makes things > much clearer. Unfortunately, it's clear that this use case does not work. > > I'd like to number the steps under "Requirements" so I can refer to > them unambiguously: > > 1. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> accesses www.myhealth.example.com > <http://www.myhealth.example.com> to discover the location of the PCP > system (XRD discovery) > 2. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> requests Alice to authorize access > to the application at www.pcp.example.com <http://www.pcp.example.com> > for the purpose of retrieving basic health data (e.g. date-of-birth, > weight, height, etc). The mechanism Alice uses to authorize this > access is out of scope for this use case. > 3. The application at www.myhealth.example.com > <http://www.myhealth.example.com> issues a token bound to > www.sleepwell.example.com <http://www.sleepwell.example.com> for > access to the application at www.pcp.example.com > <http://www.pcp.example.com>. Note that a signed token (JWT) can be > used to prove who issued the token. > 4. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> constructs a request (includes the > token issued by www.myhealth.example.com > <http://www.myhealth.example.com>) to the application at > www.pcp.example.com <http://www.pcp.example.com> > 5. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> signs the request before sending it > to www.pcp.example.com <http://www.pcp.example.com> > 6. The application at www.pcp.example.com <http://www.pcp.example.com> > receives the request and verifies the signature > 7. The application at www.pcp.example.com <http://www.pcp.example.com> > parses the message and finds the authorization token > 8. The application at www.pcp.example.com <http://www.pcp.example.com> > verifies the signature of the authorization token > 9. The application at www.pcp.example.com <http://www.pcp.example.com> > parses the authorization token and verifies that this token was issued > to the application at www.sleepwell.com <http://www.sleepwell.com> > 10. The application at www.pcp.example.com > <http://www.pcp.example.com> retrieves the requested data and returns > it to the application at www.sleepwell.example.com > <http://www.sleepwell.example.com> > > The stated purpose of signatures is: > > >The application at www.pcp.example.com <http://www.pcp.example.com> > verifies that Alice has authorized > > >www.sleepwell.example.com <http://www.sleepwell.example.com> to access > her health data as well as enforces > > >that www.sleepwell.example.com <http://www.sleepwell.example.com> is > the only application that can retrieve that > > >data with that specific authorization. > > I'll abbreviate domain names like "www.sleepwell.example.com" to > "sleepwell". > > Bearer tokens work fine when verifying that Alice has authorized > sleepwell <http://www.sleepwell.example.com> to access her health > data, so the claim is apparently that signatures give the added > benefit of enforcing that sleepwell <http://www.sleepwell.example.com> > is the only application that can retrieve that data with that specific > authorization. > I suppose this depends on how you define "work fine". While the authorization token issued by myhealthdata and given to sleepwell to present to pcp can be passed as a bearer token (so in that sense it works fine) there is no security around the token. In the case of health data, just possession of an autorization token is NOT good enough to grant access. Instead the PCP site needs to ensure that the presenting entity is specifically authorized by the Authorization Server. I contend that to establish this "chain of trust" signatures are needed. Given that in most cases pcp will want to decode the token itself, it will need some form of signed structured token because pcp is the recipient of the token and not the issuer. > Unfortunately, signatures do not do that. Suppose sleepwell wanted to > give Alice's data to apneacheck. Sleepwell could follow the protocol > up to step 4. Then, instead of signing the request and sending the > signed request to pcp, sleepwell could transmit the signed request to > apneacheck. apneacheck could then complete the protocol and get > Alice's data from www.pcp.example.com. > Maybe I wasn't clear in the use case. The point of signatures is not to enable authorization but to ensure that release of data only happens within the context that was authorized by the user. Let's take the flip side where signatures are not used. Any site with access to the bearer token issued to sleepwell has access to the Alice's data at the PCP. This is not acceptable with sensitive data. So the point of signatures in this use case is to create a binding between the issuer of the token (myhealthdata), the presenter of the token (sleepwell) and the receiver of the token (pcp). If sleepwell signs the message sent to pcp, then pcp can verify that sleepwell is the sender of the message. Next, if the message contains a token signed by myhealth data, and that token includes a claim that the token is issued to sleepwell. PCP can "connect the dots" and know that this is a valid request. If the token is sent by another server, the "issued to" claim will not match the entity that signed the message and the PCP application will reject the request. > > If sleepwell has can retrive to Alice's data, and the protocol doesn't > mandate an invasive control of sleepwell's computation and outputs, > it's hopeless to prevent sleepwell from allowing apneacheck to > retrieve Alice's data. If all else fails, sleepwell could access > Alice's data itself and then allow apneacheck to access the data from > sleepwell. > So I'll concede that once sleepwell has the data, if sleepwell is not trustworthy, there is little Alice can do to protect her data. Maybe laws and other such mechanisms will be developed to deal with this scenario. This is one reason why it's so important for the PCP to only release data to the specific entity that was authorized. This is not possible with bearer tokens in a delegated use case like this one. > > For all I know, signatures might be a solution to some problem, but > they aren't a solution to this problem. > > Tim Freeman > Email: tim.freeman@hp.com <mailto:tim.freeman@hp.com> > Desk in Palo Alto: (650) 857-2581 > Home: (408) 774-1298 > Cell: (408) 348-7536 > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *George Fletcher > *Sent:* Monday, October 04, 2010 9:20 AM > *To:* Zeltsan, Zachary (Zachary) > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? > > Hi Zachary, > > Here is a use case for signed messages. I've tried to keep this in the > format of the other OAuth use cases. Please contact me off-list if > there are editorial changes required. I've include the list to see if > others have feed back on this use case. > > Thanks, > George > > Use case: Signed Messages > > Description: > > Alice manages all her personal health records in her personal health > data store (www.myhealth.example.com > <http://www.myhealth.example.com>). Alice's Primary Care Physician > (www.pcp.example.com <http://www.pcp.example.com>) recommends that > Alice see a sleep specialist (www.sleepwell.example.com > <http://www.sleepwell.example.com>). Alice arrives at the sleep > specialist's office and authorizes it to access her basic health data > from her PCP. The application at www.pcp.example.com > <http://www.pcp.example.com> verifies that Alice has authorized > www.sleepwell.example.com <http://www.sleepwell.example.com> to access > her health data as well as enforces that www.sleepwell.example.com > <http://www.sleepwell.example.com> is the only application that can > retrieve that data with that specific authorization. > > Pre-conditions: > > * Alice has a personal health data store that allows for discovery of > her participating health systems (e.g. psychiatrist, sleep specialist, > pcp, orthodontist, ophthalmologist, etc). > * The application at www.myhealth.example.com > <http://www.myhealth.example.com> manages authorization of access to > Alice's participating health systems > * The application at www.myhealth.example.com > <http://www.myhealth.example.com> can issues authorization tokens > understood by Alice's participating health systems > * The application at www.pcp.example.com <http://www.pcp.example.com> > stores Alice's basic health and prescription records > * The application at www.sleepwell.com <http://www.sleepwell.com> > stores results of Alice's sleep tests > > > Post-conditions: > * A successful procedure results in just the information that Alice > authorized being transferred from the Primary Care Physician > (www.pcp.example.com <http://www.pcp.example.com>) to the sleep > specialist (www.sleepwell.example.com <http://www.sleepwell.example.com>). > * The transfer of health data only occurs if the application at > www.pcp.example.com <http://www.pcp.example.com> can verify that > www.sleepwell.example.com <http://www.sleepwell.example.com> is the > party requesting access and that the authorization token presented by > www.sleepwell.example.com <http://www.sleepwell.example.com> is issued > by the application at www.myhealth.example.com > <http://www.myhealth.example.com> with a restricted audience of > www.sleepwell.example.com <http://www.sleepwell.example.com> > > Requirements: > 1. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> accesses www.myhealth.example.com > <http://www.myhealth.example.com> to discover the location of the PCP > system (XRD discovery) > 2. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> requests Alice to authorize access > to the application at www.pcp.example.com <http://www.pcp.example.com> > for the purpose of retrieving basic health data (e.g. date-of-birth, > weight, height, etc). The mechanism Alice uses to authorize this > access is out of scope for this use case. > 3. The application at www.myhealth.example.com > <http://www.myhealth.example.com> issues a token bound to > www.sleepwell.example.com <http://www.sleepwell.example.com> for > access to the application at www.pcp.example.com > <http://www.pcp.example.com>. Note that a signed token (JWT) can be > used to prove who issued the token. > 4. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> constructs a request (includes the > token issued by www.myhealth.example.com > <http://www.myhealth.example.com>) to the application at > www.pcp.example.com <http://www.pcp.example.com> > 5. The application at www.sleepwell.example.com > <http://www.sleepwell.example.com> signs the request before sending it > to www.pcp.example.com <http://www.pcp.example.com> > 6. The application at www.pcp.example.com <http://www.pcp.example.com> > receives the request and verifies the signature > 7. The application at www.pcp.example.com <http://www.pcp.example.com> > parses the message and finds the authorization token > 8. The application at www.pcp.example.com <http://www.pcp.example.com> > verifies the signature of the authorization token > 9. The application at www.pcp.example.com <http://www.pcp.example.com> > parses the authorization token and verifies that this token was issued > to the application at www.sleepwell.com <http://www.sleepwell.com> > 10. The application at www.pcp.example.com > <http://www.pcp.example.com> retrieves the requested data and returns > it to the application at www.sleepwell.example.com > <http://www.sleepwell.example.com> > > > > On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: > > These use cases are not in the draft > https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth. > > Could you write them up? > > Thanks, > > Zachary > > ------------------------------------------------------------------------ > > *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> > [mailto:oauth-bounces@ietf.org] *On Behalf Of *George Fletcher > *Sent:* Tuesday, September 28, 2010 11:39 AM > *To:* OAuth WG > *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? > > I think of the signature issues as falling into two classes... I think > they map to your classification as well... > > * *Signing tokens* is important for interoperability especially > looking forward to a time when tokens issued by multiple > Authorization Servers are accepted at a given host. > * *Signing messages* is important because it provides a mechanism > to ensure that the entity making the API call (and presenting an > access token) is really the entity that is allowed to make the > API call. > > Signing messages applies to the re-delegation use cases. I've heard > the need for this class of use cases from both the hData (health data) > community as well as the user managed access (UMA) community. > > Signing tokens covers both your second class of tokens as well as > another use case that Eran has mentioned as well. Namely, a protected > resource server honoring tokens from multiple Authorization Servers. > > These are the two classes of use cases that I'd like to see solved. > > Thanks, > George > > > On 9/28/10 12:58 AM, David Recordon wrote: > > If you know me then you'll know that I'm generally one of the last > people to talk about Alice and Bob. That said, there are a lot of > technical proposals flying across the list with very little shared > understanding of the problem(s) we're trying to solve. > > From what I've seen there are two distinct classes of signature use cases. > > 1) The first is where the HTTP request parameters must be part of the > signature. An example is any OAuth 1.0a style API where you want to > make sure that the HTTP POST your server just received isn't > masquerading itself as a GET. > > 2) The second is where the HTTP request is orthogonal. An example > is OpenSocial where the server is sending state information to the > client such as what user is currently logged in. > > The main practical example I have of the first use case is what > Twitter wants to do with redelegation. In this case TweetDeck can't > given TwitPic it's own bearer token, but needs to sign the POST > request and pass that signature to TwitPic for it to include in the > final API request to Twitter. > > In terms of signing protected resource requests, I haven't heard > anyone bring up specific and detailed needs for this recently. > > JSON tokens pretty clearly make sense for the second class of > signature use cases and it's actually a bit hard to argue why they > would be a part of OAuth. Facebook shipped this a bit over a month ago > for canvas applications. We include a `signed_request` parameter which > is signature.base64url(JSON). Parsing it is 18 lines of PHP. > http://developers.facebook.com/docs/authentication/canvas > > This second class of use case will also be required by OpenID Connect > where the server is signing identity information and sending it to the > client. I imagine that OpenSocial will also still have it and wish to > continue relying on public key algorithms. > > So a few questions: > > * Do we want to tackle both of these classes of signatures in OAuth? > > * Why do you consider the second class part of OAuth versus something > completely separate that might happen to include an OAuth access token? > > * Is the Twitter redelegation use case the right focus for the first > class? > > * Is there an example of an OAuth 2.0 server that can't use bearer > tokens for protected resource requests and thus requires signatures? > > Thanks, > > --David > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > -- Chief Architect AIM: gffletch Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. Home: gffletch@aol.com Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch --------------030008040104020909070507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Helvetica, Arial, sans-serif">Hi Tim,<br> <br> Thanks for the feedback. Some comments/questions inline...<br> </font><br> On 10/4/10 1:59 PM, Freeman, Tim wrote: <blockquote cite="mid:59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="Generator" content="Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"Times New\000D\000A Roman"; panose-1:0 0 0 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:blue; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle19 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1077285682; mso-list-template-ids:1441661176;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Putting the use cases on the table is good because it makes things much clearer.  Unfortunately, it's clear that this use case does not work.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">I'd like to number the steps under "Requirements" so I can refer to them unambiguously:<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"> <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">1. The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> accesses <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> 2. The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> requests Alice to authorize access to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> 3. The application at <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> issues a token bound to <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> for access to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<br> 4. The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a>) to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a><br> 5. The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> signs the request before sending it to <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a><br> 6. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> receives the request and verifies the signature<br> 7. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the message and finds the authorization token<br> 8. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> 9. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the application at <a moz-do-not-send="true" href="http://www.sleepwell.com">www.sleepwell.com</a><br> 10. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">The stated purpose of signatures is:<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">>The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies that Alice has authorized <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">><a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> to access her health data as well as enforces <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">>that <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the only application that can retrieve that <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">>data with that specific authorization.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">I'll abbreviate domain names like "<a class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>" to "sleepwell".<br> <br> <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Bearer tokens work fine when verifying that Alice has authorized  <a moz-do-not-send="true" href="http://www.sleepwell.example.com">sleepwell</a> to access her health data, so the claim is apparently that signatures give the added benefit of enforcing that <a moz-do-not-send="true" href="http://www.sleepwell.example.com">sleepwell</a> is the only application that can retrieve that data with that specific authorization.</span></p> </div> </blockquote> I suppose this depends on how you define "work fine". While the authorization token issued by myhealthdata and given to sleepwell to present to pcp can be passed as a bearer token (so in that sense it works fine) there is no security around the token. In the case of health data, just possession of an autorization token is NOT good enough to grant access. <br> <br> Instead the PCP site needs to ensure that the presenting entity is specifically authorized by the Authorization Server. I contend that to establish this "chain of trust" signatures are needed.<br> <br> Given that in most cases pcp will want to decode the token itself, it will need some form of signed structured token because pcp is the recipient of the token and not the issuer.<br> <br> <blockquote cite="mid:59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net" type="cite"> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Unfortunately, signatures do not do that.  Suppose sleepwell wanted to give Alice's data to apneacheck.  Sleepwell could follow the protocol up to step 4.  Then, instead of signing the request and sending the signed request to pcp, sleepwell could transmit the signed request to apneacheck.  apneacheck could then complete the protocol and get Alice's data from <a class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>.</span></p> </div> </blockquote> Maybe I wasn't clear in the use case. The point of signatures is not to enable authorization but to ensure that release of data only happens within the context that was authorized by the user. Let's take the flip side where signatures are not used. Any site with access to the bearer token issued to sleepwell has access to the Alice's data at the PCP. This is not acceptable with sensitive data.<br> <br> So the point of signatures in this use case is to create a binding between the issuer of the token (myhealthdata), the presenter of the token (sleepwell) and the receiver of the token (pcp).<br> <br> If sleepwell signs the message sent to pcp, then pcp can verify that sleepwell is the sender of the message. Next, if the message contains a token signed by myhealth data, and that token includes a claim that the token is issued to sleepwell. PCP can "connect the dots" and know that this is a valid request.<br> <br> If the token is sent by another server, the "issued to" claim will not match the entity that signed the message and the PCP application will reject the request.<br> <blockquote cite="mid:59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net" type="cite"> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">If sleepwell has can retrive to Alice's data, and the protocol doesn't mandate an invasive control of sleepwell's computation and outputs, it's hopeless to prevent sleepwell from allowing apneacheck to retrieve Alice's data.  If all else fails, sleepwell could access Alice's data itself and then allow apneacheck to access the data from sleepwell.</span></p> </div> </blockquote> So I'll concede that once sleepwell has the data, if sleepwell is not trustworthy, there is little Alice can do to protect her data. Maybe laws and other such mechanisms will be developed to deal with this scenario. This is one reason why it's so important for the PCP to only release data to the specific entity that was authorized. This is not possible with bearer tokens in a delegated use case like this one.<br> <blockquote cite="mid:59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net" type="cite"> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"> <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">For all I know, signatures might be a solution to some problem, but they aren't a solution to this problem.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <div> <p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">Tim Freeman<br> Email: <a moz-do-not-send="true" href="mailto:tim.freeman@hp.com">tim.freeman@hp.com</a><br> Desk in Palo Alto: (650) 857-2581<br> Home: (408) 774-1298<br> Cell: (408) 348-7536<o:p></o:p></span></p> </div> <p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p> <div> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> <p class="MsoNormal"><b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;">From:</span></b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"> <a class="moz-txt-link-abbreviated" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a class="moz-txt-link-freetext" href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Monday, October 04, 2010 9:20 AM<br> <b>To:</b> Zeltsan, Zachary (Zachary)<br> <b>Cc:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?<o:p></o:p></span></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><span style="font-family: "Helvetica","sans-serif";">Hi Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case.<br> <br> Thanks,<br> George<br> <br> Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data store (<a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a>) recommends that Alice see a sleep specialist (<a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies that Alice has authorized <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> to access her health data as well as enforces that <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the only application that can retrieve that data with that specific authorization.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> stores Alice's basic health and prescription records<br> * The application at <a moz-do-not-send="true" href="http://www.sleepwell.com">www.sleepwell.com</a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authorized being transferred from the Primary Care Physician (<a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>).<br> * The transfer of health data only occurs if the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> can verify that <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the party requesting access and that the authorization token presented by <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is issued by the application at <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> with a restricted audience of <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> Requirements:<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">1.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> accesses <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">2.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> requests Alice to authorize access to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">3.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a> issues a token bound to <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> for access to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">4.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a moz-do-not-send="true" href="http://www.myhealth.example.com">www.myhealth.example.com</a>) to the application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a><br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">5. </span><span style="font-family: "Helvetica","sans-serif";">The application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> signs the request before sending it to <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a><br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">6.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> receives the request and verifies the signature<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">7.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the message and finds the authorization token<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">8.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">9.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the application at <a moz-do-not-send="true" href="http://www.sleepwell.com">www.sleepwell.com</a><br> </span><span style="font-family: "Helvetica","sans-serif"; color: rgb(31, 73, 125);">10.</span><span style="font-family: "Helvetica","sans-serif";"> The application at <a moz-do-not-send="true" href="http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a moz-do-not-send="true" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </span><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;">These use cases are not in the draft <a moz-do-not-send="true" href="https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;">Could you write them up?</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;">Thanks,</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;">Zachary</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial","sans-serif"; color: navy;"> </span><o:p></o:p></p> <div> <div class="MsoNormal" style="text-align: center;" align="center"><span style="color: windowtext;"> <hr align="center" size="2" width="100%"> </span></div> <p class="MsoNormal"><b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;">From:</span></b><span style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"> <a moz-do-not-send="true" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a moz-do-not-send="true" href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Tuesday, September 28, 2010 11:39 AM<br> <b>To:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</span><o:p></o:p></p> </div> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal"><span style="font-family: "Helvetica","sans-serif";">I think of the signature issues as falling into two classes... I think they map to your classification as well...</span><o:p></o:p></p> <ul style="margin-top: 0in;" type="disc"> <li class="MsoNormal" style=""><b><span style="font-family: "Helvetica","sans-serif";">Signing tokens</span></b><span style="font-family: "Helvetica","sans-serif";"> is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span><o:p></o:p></li> <li class="MsoNormal" style=""><b><span style="font-family: "Helvetica","sans-serif";">Signing messages</span></b><span style="font-family: "Helvetica","sans-serif";"> is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.</span><o:p></o:p></li> </ul> <p class="MsoNormal"><span style="font-family: "Helvetica","sans-serif";">Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class="MsoNormal"><span style="">If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">From what I've seen there are two distinct classes of signature use cases.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a moz-do-not-send="true" href="http://developers.facebook.com/docs/authentication/canvas">http://developers.facebook.com/docs/authentication/canvas</a></span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms.</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">So a few questions:</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> * Do we want to tackle both of these classes of signatures in OAuth?</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token?</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> * Is the Twitter redelegation use case the right focus for the first class?</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style=""> </span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">Thanks,</span><o:p></o:p></p> </div> <div> <p class="MsoNormal"><span style="">--David</span><o:p></o:p></p> </div> <pre> <o:p></o:p></pre> <pre> <o:p></o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>OAuth mailing list<o:p></o:p></pre> <pre><a moz-do-not-send="true" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre> <pre><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></pre> <p class="MsoNormal" style="margin-bottom: 12pt;"> <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> </div> </blockquote> <br> <pre class="moz-signature" cols="72">-- Chief Architect AIM: gffletch Identity Services Engineering Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a> AOL Inc. Home: <a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a> Mobile: +1-703-462-3494 Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a> Office: +1-703-265-2544 Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a> </pre> </body> </html> --------------030008040104020909070507-- From igor.faynberg@alcatel-lucent.com Mon Oct 4 11:41:05 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7DB3A6E4A for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 11:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbQdH9dyLUQA for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 11:41:03 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 8CFEB3A7067 for <oauth@ietf.org>; Mon, 4 Oct 2010 11:40:42 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o94Ifb6v018132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 13:41:37 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o94IfYUW024357; Mon, 4 Oct 2010 13:41:34 -0500 (CDT) Message-ID: <4CAA1FDE.50804@alcatel-lucent.com> Date: Mon, 04 Oct 2010 14:41:34 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: George Fletcher <gffletch@aol.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> <4CAA1CBB.80001@aol.com> In-Reply-To: <4CAA1CBB.80001@aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Zeltsan, Zachary \(Zachary\)" <zachary.zeltsan@alcatel-lucent.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 18:41:05 -0000 YES!!! (I wish I could have made this point myself as clear as George did.) In fact, I think this ought to be a fundamental requirement for OAuth applicability within several domains, health services in particular. Igor George Fletcher wrote: > ... The point of signatures is not to enable authorization but to > ensure that release of data only happens within the context that was > authorized by the user. ... From zachary.zeltsan@alcatel-lucent.com Mon Oct 4 13:56:08 2010 Return-Path: <zachary.zeltsan@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2C83A70C4 for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 13:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATpyJnwo6Skl for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 13:55:50 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 4DCBF3A70C3 for <oauth@ietf.org>; Mon, 4 Oct 2010 13:55:50 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o94Kuf6u024707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Oct 2010 15:56:41 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o94Kufak013198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Oct 2010 15:56:41 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 4 Oct 2010 15:56:41 -0500 From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> To: "'George Fletcher'" <gffletch@aol.com>, "Freeman, Tim" <tim.freeman@hp.com> Date: Mon, 4 Oct 2010 15:56:40 -0500 Thread-Topic: Signatures don't solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?) Thread-Index: Actj8fXPRVcyPmrJRYWoAqNbEl5mTwADuYDA Message-ID: <5710F82C0E73B04FA559560098BF95B124FB23341D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> <4CAA1CBB.80001@aol.com> In-Reply-To: <4CAA1CBB.80001@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124FB23341DUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 20:56:08 -0000 --_000_5710F82C0E73B04FA559560098BF95B124FB23341DUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that George has presented a convincing use case for the need of s= ignatures for binding a resource request with the authorizing (myhelthdata = on Alice's behalf), requesting (sleepwell), and storing the resource (pcp) = entities. Such binding does not eliminate unauthorized access to the resour= ces, but makes it harder to get and also, allows creation of the proof of t= he participants' actions (e.g., a proof that sleepwell has requested access= to Alice's data at pcp). Zachary ________________________________ From: George Fletcher [mailto:gffletch@aol.com] Sent: Monday, October 04, 2010 2:28 PM To: Freeman, Tim Cc: Zeltsan, Zachary (Zachary); OAuth WG Subject: Re: Signatures don't solve that problem (was RE: [OAUTH-WG] Signat= ures...what are we trying to solve?) Hi Tim, Thanks for the feedback. Some comments/questions inline... On 10/4/10 1:59 PM, Freeman, Tim wrote: Putting the use cases on the table is good because it makes things much cle= arer. Unfortunately, it's clear that this use case does not work. I'd like to number the steps under "Requirements" so I can refer to them un= ambiguously: 1. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> t= o discover the location of the PCP system (XRD discovery) 2. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> requests Alice to authorize access to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> for the purpose of retrieving basic he= alth data (e.g. date-of-birth, weight, height, etc). The mechanism Alice us= es to authorize this access is out of scope for this use case. 3. The application at www.myhealth.example.com<http://www.myhealth.example.= com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell= .example.com> for access to the application at www.pcp.example.com<http://w= ww.pcp.example.com>. Note that a signed token (JWT) can be used to prove wh= o issued the token. 4. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> constructs a request (includes the token issued by www.myhealth.exam= ple.com<http://www.myhealth.example.com>) to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> 5. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> signs the request before sending it to www.pcp.example.com<http://ww= w.pcp.example.com> 6. The application at www.pcp.example.com<http://www.pcp.example.com> recei= ves the request and verifies the signature 7. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the message and finds the authorization token 8. The application at www.pcp.example.com<http://www.pcp.example.com> verif= ies the signature of the authorization token 9. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the authorization token and verifies that this token was issued to the ap= plication at www.sleepwell.com<http://www.sleepwell.com> 10. The application at www.pcp.example.com<http://www.pcp.example.com> retr= ieves the requested data and returns it to the application at www.sleepwell= .example.com<http://www.sleepwell.example.com> The stated purpose of signatures is: >The application at www.pcp.example.com<http://www.pcp.example.com> verifie= s that Alice has authorized >www.sleepwell.example.com<http://www.sleepwell.example.com> to access her = health data as well as enforces >that www.sleepwell.example.com<http://www.sleepwell.example.com> is the on= ly application that can retrieve that >data with that specific authorization. I'll abbreviate domain names like "www.sleepwell.example.com<http://www.sle= epwell.example.com>" to "sleepwell". Bearer tokens work fine when verifying that Alice has authorized sleepwell= <http://www.sleepwell.example.com> to access her health data, so the claim = is apparently that signatures give the added benefit of enforcing that slee= pwell<http://www.sleepwell.example.com> is the only application that can re= trieve that data with that specific authorization. I suppose this depends on how you define "work fine". While the authorizati= on token issued by myhealthdata and given to sleepwell to present to pcp ca= n be passed as a bearer token (so in that sense it works fine) there is no = security around the token. In the case of health data, just possession of a= n autorization token is NOT good enough to grant access. Instead the PCP site needs to ensure that the presenting entity is specific= ally authorized by the Authorization Server. I contend that to establish th= is "chain of trust" signatures are needed. Given that in most cases pcp will want to decode the token itself, it will = need some form of signed structured token because pcp is the recipient of t= he token and not the issuer. Unfortunately, signatures do not do that. Suppose sleepwell wanted to give= Alice's data to apneacheck. Sleepwell could follow the protocol up to ste= p 4. Then, instead of signing the request and sending the signed request t= o pcp, sleepwell could transmit the signed request to apneacheck. apneache= ck could then complete the protocol and get Alice's data from www.pcp.examp= le.com<http://www.pcp.example.com>. Maybe I wasn't clear in the use case. The point of signatures is not to ena= ble authorization but to ensure that release of data only happens within th= e context that was authorized by the user. Let's take the flip side where s= ignatures are not used. Any site with access to the bearer token issued to = sleepwell has access to the Alice's data at the PCP. This is not acceptable= with sensitive data. So the point of signatures in this use case is to create a binding between = the issuer of the token (myhealthdata), the presenter of the token (sleepwe= ll) and the receiver of the token (pcp). If sleepwell signs the message sent to pcp, then pcp can verify that sleepw= ell is the sender of the message. Next, if the message contains a token sig= ned by myhealth data, and that token includes a claim that the token is iss= ued to sleepwell. PCP can "connect the dots" and know that this is a valid = request. If the token is sent by another server, the "issued to" claim will not matc= h the entity that signed the message and the PCP application will reject th= e request. If sleepwell has can retrive to Alice's data, and the protocol doesn't mand= ate an invasive control of sleepwell's computation and outputs, it's hopele= ss to prevent sleepwell from allowing apneacheck to retrieve Alice's data. = If all else fails, sleepwell could access Alice's data itself and then all= ow apneacheck to access the data from sleepwell. So I'll concede that once sleepwell has the data, if sleepwell is not trust= worthy, there is little Alice can do to protect her data. Maybe laws and ot= her such mechanisms will be developed to deal with this scenario. This is o= ne reason why it's so important for the PCP to only release data to the spe= cific entity that was authorized. This is not possible with bearer tokens i= n a delegated use case like this one. For all I know, signatures might be a solution to some problem, but they ar= en't a solution to this problem. Tim Freeman Email: tim.freeman@hp.com<mailto:tim.freeman@hp.com> Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org] On Behalf Of George Fletcher Sent: Monday, October 04, 2010 9:20 AM To: Zeltsan, Zachary (Zachary) Cc: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? Hi Zachary, Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are ed= itorial changes required. I've include the list to see if others have feed = back on this use case. Thanks, George Use case: Signed Messages Description: Alice manages all her personal health records in her personal health data s= tore (www.myhealth.example.com<http://www.myhealth.example.com>). Alice's P= rimary Care Physician (www.pcp.example.com<http://www.pcp.example.com>) rec= ommends that Alice see a sleep specialist (www.sleepwell.example.com<http:/= /www.sleepwell.example.com>). Alice arrives at the sleep specialist's offic= e and authorizes it to access her basic health data from her PCP. The appli= cation at www.pcp.example.com<http://www.pcp.example.com> verifies that Ali= ce has authorized www.sleepwell.example.com<http://www.sleepwell.example.co= m> to access her health data as well as enforces that www.sleepwell.example= .com<http://www.sleepwell.example.com> is the only application that can ret= rieve that data with that specific authorization. Pre-conditions: * Alice has a personal health data store that allows for discovery of her p= articipating health systems (e.g. psychiatrist, sleep specialist, pcp, orth= odontist, ophthalmologist, etc). * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> manages authorization of access to Alice's participating health systems * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> can issues authorization tokens understood by Alice's participating hea= lth systems * The application at www.pcp.example.com<http://www.pcp.example.com> stores= Alice's basic health and prescription records * The application at www.sleepwell.com<http://www.sleepwell.com> stores res= ults of Alice's sleep tests Post-conditions: * A successful procedure results in just the information that Alice authori= zed being transferred from the Primary Care Physician (www.pcp.example.com<= http://www.pcp.example.com>) to the sleep specialist (www.sleepwell.example= .com<http://www.sleepwell.example.com>). * The transfer of health data only occurs if the application at www.pcp.exa= mple.com<http://www.pcp.example.com> can verify that www.sleepwell.example.= com<http://www.sleepwell.example.com> is the party requesting access and th= at the authorization token presented by www.sleepwell.example.com<http://ww= w.sleepwell.example.com> is issued by the application at www.myhealth.examp= le.com<http://www.myhealth.example.com> with a restricted audience of www.s= leepwell.example.com<http://www.sleepwell.example.com> Requirements: 1. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> t= o discover the location of the PCP system (XRD discovery) 2. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> requests Alice to authorize access to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> for the purpose of retrieving basic he= alth data (e.g. date-of-birth, weight, height, etc). The mechanism Alice us= es to authorize this access is out of scope for this use case. 3. The application at www.myhealth.example.com<http://www.myhealth.example.= com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell= .example.com> for access to the application at www.pcp.example.com<http://w= ww.pcp.example.com>. Note that a signed token (JWT) can be used to prove wh= o issued the token. 4. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> constructs a request (includes the token issued by www.myhealth.exam= ple.com<http://www.myhealth.example.com>) to the application at www.pcp.exa= mple.com<http://www.pcp.example.com> 5. The application at www.sleepwell.example.com<http://www.sleepwell.exampl= e.com> signs the request before sending it to www.pcp.example.com<http://ww= w.pcp.example.com> 6. The application at www.pcp.example.com<http://www.pcp.example.com> recei= ves the request and verifies the signature 7. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the message and finds the authorization token 8. The application at www.pcp.example.com<http://www.pcp.example.com> verif= ies the signature of the authorization token 9. The application at www.pcp.example.com<http://www.pcp.example.com> parse= s the authorization token and verifies that this token was issued to the ap= plication at www.sleepwell.com<http://www.sleepwell.com> 10. The application at www.pcp.example.com<http://www.pcp.example.com> retr= ieves the requested data and returns it to the application at www.sleepwell= .example.com<http://www.sleepwell.example.com> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: These use cases are not in the draft https://datatracker.ietf.org/doc/draft= -zeltsan-use-cases-oauth. Could you write them up? Thanks, Zachary ________________________________ From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org] On Behalf Of George Fletcher Sent: Tuesday, September 28, 2010 11:39 AM To: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? I think of the signature issues as falling into two classes... I think they= map to your classification as well... * Signing tokens is important for interoperability especially looking fo= rward to a time when tokens issued by multiple Authorization Servers are ac= cepted at a given host. * Signing messages is important because it provides a mechanism to ensur= e that the entity making the API call (and presenting an access token) is r= eally the entity that is allowed to make the API call. Signing messages applies to the re-delegation use cases. I've heard the nee= d for this class of use cases from both the hData (health data) community a= s well as the user managed access (UMA) community. Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource serve= r honoring tokens from multiple Authorization Servers. These are the two classes of use cases that I'd like to see solved. Thanks, George On 9/28/10 12:58 AM, David Recordon wrote: If you know me then you'll know that I'm generally one of the last people t= o talk about Alice and Bob. That said, there are a lot of technical proposa= ls flying across the list with very little shared understanding of the prob= lem(s) we're trying to solve. >From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signa= ture. An example is any OAuth 1.0a style API where you want to make sure th= at the HTTP POST your server just received isn't masquerading itself as a G= ET. 2) The second is where the HTTP request is orthogonal. An example is OpenSo= cial where the server is sending state information to the client such as wh= at user is currently logged in. The main practical example I have of the first use case is what Twitter wan= ts to do with redelegation. In this case TweetDeck can't given TwitPic it's= own bearer token, but needs to sign the POST request and pass that signatu= re to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bri= ng up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use= cases and it's actually a bit hard to argue why they would be a part of OA= uth. Facebook shipped this a bit over a month ago for canvas applications. = We include a `signed_request` parameter which is signature.base64url(JSON).= Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authent= ication/canvas This second class of use case will also be required by OpenID Connect where= the server is signing identity information and sending it to the client. I= imagine that OpenSocial will also still have it and wish to continue relyi= ng on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something comp= letely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class= ? * Is there an example of an OAuth 2.0 server that can't use bearer tokens = for protected resource requests and thus requires signatures? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect AIM: gffletch Identity Services Engineering Work: george.fletcher@teamaol.com<mailto:= george.fletcher@teamaol.com> AOL Inc. Home: gffletch@aol.com<mailto:gffletch@ao= l.com> Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch --_000_5710F82C0E73B04FA559560098BF95B124FB23341DUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"= /> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} pre {mso-style-priority:99;} span.HTMLPREFORMATTEDCHAR {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman"; color:black;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.HTMLPreformattedChar {font-family:Consolas; color:black;} span.EmailStyle19 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle20 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:637998615; mso-list-template-ids:1618256028;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>I believe that George has presented a convincing use case for the need of signatures for binding a resource reque= st with the authorizing (myhelthdata on <st1:City w:st=3D"on"><st1:place w:st= =3D"on">Alice</st1:place></st1:City>’s behalf), requesting (sleepwell), and storing the resource (pcp) entities. S= uch binding does not eliminate unauthorized access to the resources, but makes = it harder to get and also, allows creation of the proof of the participants= 217; actions (e.g., a proof that sleepwell has requested access to <st1:City w:s= t=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City>’s data at pcp).<o:p></o:p><= /span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Zachary<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 color=3Dblack face=3D"Times New Roman"><span style=3D'font-size:12.0pt;colo= r:windowtext'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:b= old'>From:</span></font></b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-f= amily:Tahoma; color:windowtext'> George Fletcher [mailto:gffletch@aol.com] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 04, 20= 10 2:28 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Freeman, Tim<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> Zeltsan, Zachary (Zachar= y); OAuth WG<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Signatures don'= t solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?)</span></font><font color=3Dblack><span style=3D'color:windowtext'><= o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-family:Helvetica'>Hi Tim,<br> <br> Thanks for the feedback. Some comments/questions inline...<br> </span></font><br> On 10/4/10 1:59 PM, Freeman, Tim wrote: <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'><!--[if gte mso 9]><xml> <u1:shapedefaults u2:ext=3D"edit" spidmax=3D"1026"/> </xml><![endif]--><!--[if gte mso 9]><xml> <u3:shapelayout u4:ext=3D"edit"> <u3:idmap u4:ext=3D"edit" data=3D"1"/> </u3:shapelayout> </xml><![endif]-->Putting the use cases on the table is good because it mak= es things much clearer.  Unfortunately, it's clear that this use case doe= s not work.<u5:p></u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> </u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>I'd like to number the steps under "Requirements" so I can refer to t= hem unambiguously:<u5:p></u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> <u5:p></u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>1. The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> accesses <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealt= h.example.com</a> to discover the location of the PCP system (XRD discovery)<br> 2. The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> requests <st1:City w:s= t=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City> to authorize access to the applic= ation at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.ex= ample.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight= , height, etc). The mechanism <st1:City w:st=3D"on"><st1:place w:st=3D"on">Al= ice</st1:place></st1:City> uses to authorize this access is out of scope for this use case.<br> 3. The application at <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealth.example.com</a> issues a token bound to= <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a> for access to the application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a>. Note that a signed token (J= WT) can be used to prove who issued the token.<br> 4. The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> constructs a request (includes the token issued by <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealth.example.com</a>) to the application at = <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.= com</a><br> 5. The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> signs the request befo= re sending it to <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue= >www.pcp.example.com</a><br> 6. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> receives the request and ver= ifies the signature<br> 7. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> parses the message and finds= the authorization token<br> 8. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> verifies the signature of th= e authorization token<br> 9. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> parses the authorization tok= en and verifies that this token was issued to the application at <a href=3D"http://www.sleepwell.com" moz-do-not-send=3Dtrue>www.sleepwell.com<= /a><br> 10. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> retrieves the requested data= and returns it to the application at <a href=3D"http://www.sleepwell.example.co= m" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a><br> <br> <br> </span></font><o:p></o:p></p> <u5:p></u5:p></span> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>The stated purpose of signatures is:<u5:p></u5:p></span></span></font><o:p></o:= p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> </u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>>The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> verifies that <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place= ></st1:City> has authorized <u5:p></u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>><a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a> to access her health data as well as enforces <u5:p></u5:p></span></span></= font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>>that <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sle= epwell.example.com</a> is the only application that can retrieve that <u5:p></u5:p></span></span><= /font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>>data with that specific authorization.<u5:p></u5:p></span></span></font><o:p></o= :p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> </u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>I'll abbreviate domain names like "<a href=3D"http://www.sleepwell.example.= com">www.sleepwell.example.com</a>" to "sleepwell".<br> <br> <br> </span></font><o:p></o:p></p> <u5:p></u5:p></span> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>Bearer tokens work fine when verifying that <st1:City w:st=3D"on"><st1:place w:st= =3D"on">Alice</st1:place></st1:City> has authorized  <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>sleepwell</a> to access her health data, so the clai= m is apparently that signatures give the added benefit of enforcing that <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>sleepwell<= /a> is the only application that can retrieve that data with that specific authorization.</span></span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>I suppose this depends on how you define "w= ork fine". While the authorization token issued by myhealthdata and given = to sleepwell to present to pcp can be passed as a bearer token (so in that sen= se it works fine) there is no security around the token. In the case of health data, just possession of an autorization token is NOT good enough to grant access. <br> <br> Instead the PCP site needs to ensure that the presenting entity is specific= ally authorized by the Authorization Server. I contend that to establish this "chain of trust" signatures are needed.<br> <br> Given that in most cases pcp will want to decode the token itself, it will = need some form of signed structured token because pcp is the recipient of the to= ken and not the issuer.<br> <br> <br> <o:p></o:p></span></font></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p></u5:p></span><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'><u5:p><span style=3D'color:rgb(31, 73, 125)'> </u5:p></span><= /span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>Unfortunately, signatures do not do that.  Suppose sleepwell wanted to give <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City>'s data to apneacheck.  Sleepwell could follow the protocol up to step 4.  T= hen, instead of signing the request and sending the signed request to pcp, sleep= well could transmit the signed request to apneacheck.  apneacheck could the= n complete the protocol and get <st1:City w:st=3D"on"><st1:place w:st=3D"on">= Alice</st1:place></st1:City>'s data from <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a>.</= span></span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>Maybe I wasn't clear in the use case. The point = of signatures is not to enable authorization but to ensure that release of dat= a only happens within the context that was authorized by the user. Let's take= the flip side where signatures are not used. Any site with access to the bearer token issued to sleepwell has access to the <st1:City w:st=3D"on"><st1:plac= e w:st=3D"on">Alice</st1:place></st1:City>'s data at the PCP. This is not acceptable with sensitive data.<br> <br> So the point of signatures in this use case is to create a binding between = the issuer of the token (myhealthdata), the presenter of the token (sleepwell) = and the receiver of the token (pcp).<br> <br> If sleepwell signs the message sent to pcp, then pcp can verify that sleepw= ell is the sender of the message. Next, if the message contains a token signed = by myhealth data, and that token includes a claim that the token is issued to sleepwell. PCP can "connect the dots" and know that this is a val= id request.<br> <br> If the token is sent by another server, the "issued to" claim wil= l not match the entity that signed the message and the PCP application will r= eject the request.<br> <br> <o:p></o:p></span></font></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p></u5:p></span><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'><u5:p><span style=3D'color:rgb(31, 73, 125)'> </u5:p></span><= /span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>If sleepwell has can retrive to <st1:City w:st=3D"on">Alice</st1:City>'s data,= and the protocol doesn't mandate an invasive control of sleepwell's computation= and outputs, it's hopeless to prevent sleepwell from allowing apneacheck to retrieve <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st= 1:City>'s data.  If all else fails, sleepwell could access <st1:City w:st=3D"on"= ><st1:place w:st=3D"on">Alice</st1:place></st1:City>'s data itself and then allow apne= acheck to access the data from sleepwell.</span></span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>So I'll concede that once sleepwell has the data= , if sleepwell is not trustworthy, there is little <st1:City w:st=3D"on"><st1:pl= ace w:st=3D"on">Alice</st1:place></st1:City> can do to protect her data. Maybe= laws and other such mechanisms will be developed to deal with this scenario. Thi= s is one reason why it's so important for the PCP to only release data to the specific entity that was authorized. This is not possible with bearer token= s in a delegated use case like this one.<br> <br> <o:p></o:p></span></font></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p></u5:p></span><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'><span style=3D'color:rgb(31, 73, 125)'> <u5:p></u5:p></= span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'>For all I know, signatures might be a solution to some problem, but they aren't= a solution to this problem.<u5:p></u5:p></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> </u5:p></span></span></font><o:p></o:p></p> <div> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Times New Rom= an"><span style=3D'font-size:10.0pt;color:#1F497D'>Tim Freeman<br> Email: <a href=3D"mailto:tim.freeman@hp.com" moz-do-not-send=3Dtrue>tim.fre= eman@hp.com</a><br> Desk in <st1:City w:st=3D"on"><st1:place w:st=3D"on">Palo Alto</st1:place><= /st1:City>: (650) 857-2581<br> Home: (408) 774-1298<br> Cell: (408) 348-7536<u5:p></u5:p></span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><span style=3D'color:rgb(31, 73, = 125)'><u5:p><font size=3D2 color=3Dblack face=3DCalibri><span style=3D'font-size:11.0pt;font-= family:Calibri'> </u5:p></span></span></font><o:p></o:p></p> <div> <div style=3D'border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0= in 0in 0in; border-color:-moz-use-text-color -moz-use-text-color'> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:b= old'>From:</span></font></b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-f= amily:Tahoma; color:windowtext'> <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@= ietf.org</a> [<a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a= >] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>George Fletcher<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 04, 20= 10 9:20 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Zeltsan, Zachary (Zachar= y)<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> OAuth WG<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [OAUTH-WG] Signatures...what are we trying to solve?<u5:p></u5:p></span></font><o:p></= o:p></p> </div> </div> <p class=3DMsoNormal><u5:p><font size=3D3 color=3Dblack face=3D"Times New R= oman"><span style=3D'font-size:12.0pt'> <o:p></o:p></span></font></u5:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-family:Helvetica'>Hi Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are edito= rial changes required. I've include the list to see if others have feed back on = this use case.<br> <br> Thanks,<br> George<br> <br> Use case: Signed Messages<br> <br> Description:<br> <br> <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City> m= anages all her personal health records in her personal health data store (<a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealt= h.example.com</a>). <st1:City w:st=3D"on">Alice</st1:City>'s Primary Care Physician (<a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.= com</a>) recommends that <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:pla= ce></st1:City> see a sleep specialist (<a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a>). <st1:City w:st=3D"on= "><st1:place w:st=3D"on">Alice</st1:place></st1:City> arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> verifies that <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place= ></st1:City> has authorized <a href=3D"http://www.sleepwell.example.com" moz-do-not-send= =3Dtrue>www.sleepwell.example.com</a> to access her health data as well as enforces that <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a> is the only application that can retrieve that data with that specific authorization.<br> <br> Pre-conditions:<br> <br> * <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City>= has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealth.example.com</a> manages authorization o= f access to <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></s= t1:City>'s participating health systems<br> * The application at <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealth.example.com</a> can issues authorizatio= n tokens understood by <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st= 1:place></st1:City>'s participating health systems<br> * The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send= =3Dtrue>www.pcp.example.com</a> stores <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:= City>'s basic health and prescription records<br> * The application at <a href=3D"http://www.sleepwell.com" moz-do-not-send= =3Dtrue>www.sleepwell.com</a> stores results of <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:p= lace></st1:City>'s sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that <st1:City w:s= t=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City> authorized being transferred from= the Primary Care Physician (<a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a>) to the sleep specialist (<a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a>).<br> * The transfer of health data only occurs if the application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.= com</a> can verify that <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> is the party requestin= g access and that the authorization token presented by <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a> is issued by the application at <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealth.example.com</a> with a restricted audie= nce of <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sle= epwell.example.com</a><br> <br> Requirements:<br> <span style=3D'color:rgb(31, 73, 125)'>1.</span> The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send= =3Dtrue>www.sleepwell.example.com</a> accesses <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue= >www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> <span style=3D'color:rgb(31, 73, 125)'>2.</span> The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send= =3Dtrue>www.sleepwell.example.com</a> requests <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st= 1:City> to authorize access to the application at <a href=3D"http://www.pcp.example= .com" moz-do-not-send=3Dtrue>www.pcp.example.com</a> for the purpose of retrievin= g basic health data (e.g. date-of-birth, weight, height, etc). The mechanism = <st1:City w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City> uses to aut= horize this access is out of scope for this use case.<br> <span style=3D'color:rgb(31, 73, 125)'>3.</span> The application at <a href=3D"http://www.myhealth.example.com" moz-do-not-send= =3Dtrue>www.myhealth.example.com</a> issues a token bound to <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepwell.example.com</a> for access to the application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<b= r> <span style=3D'color:rgb(31, 73, 125)'>4.</span> The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send= =3Dtrue>www.sleepwell.example.com</a> constructs a request (includes the token issued by <a href=3D"http://www.myhealth.example.com" moz-do-not-send=3Dtrue>www.myhealt= h.example.com</a>) to the application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.example.com</a><br> <span style=3D'color:rgb(31, 73, 125)'>5. </span>The application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send= =3Dtrue>www.sleepwell.example.com</a> signs the request before sending it to <a href=3D"http://www.pcp.example.co= m" moz-do-not-send=3Dtrue>www.pcp.example.com</a><br> <span style=3D'color:rgb(31, 73, 125)'>6.</span> The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> receives the request and verifies the signature<br> <span style=3D'color:rgb(31, 73, 125)'>7.</span> The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> parses the message and finds the authorization token<br> <span style=3D'color:rgb(31, 73, 125)'>8.</span> The a= pplication at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtrue>www.pcp.ex= ample.com</a> verifies the signature of the authorization token<br> <span style=3D'color:rgb(31, 73, 125)'>9.</span> The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to t= he application at <a href=3D"http://www.sleepwell.com" moz-do-not-send=3Dtrue>= www.sleepwell.com</a><br> <span style=3D'color:rgb(31, 73, 125)'>10.</span> The application at <a href=3D"http://www.pcp.example.com" moz-do-not-send=3Dtru= e>www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a href=3D"http://www.sleepwell.example.com" moz-do-not-send=3Dtrue>www.sleepw= ell.example.com</a><br> <br> </span></font><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <u5:p></u5:p><o:p></= o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>These use cases are not in the draft <= a href=3D"https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth" moz-do-not-send=3Dtrue>https://datatracker.ietf.org/doc/draft-zeltsan-use-c= ases-oauth</a>.</span></font><u5:p></u5:p><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Could you write them up?</span></font>= <u5:p></u5:p><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'> </span></font><u5:p></u5:p><o:p>= </o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks,</span></font><u5:p></u5:p><o:p= ></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Zachary</span></font><u5:p></u5:p><o:p= ></o:p></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'> </span></font><u5:p></u5:p><o:p>= </o:p></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 color=3Dblack face=3D"Times New Roman"><span style=3D'font-size:12.0pt;colo= r:windowtext'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:b= old'>From:</span></font></b><font size=3D2 color=3Dblack face=3DTahoma><span style=3D'font-size:10.0pt;font-f= amily:Tahoma; color:windowtext'> <a href=3D"mailto:oauth-bounces@ietf.org" moz-do-not-send=3Dtrue>oauth-bounces@ietf.org</a> [<a href=3D"mailto:oauth-bounces@ietf.org" moz-do-not-send=3Dtrue>mailto:oauth-= bounces@ietf.org</a>] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>George Fletcher= <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September 28,= 2010 11:39 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> OAuth WG<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</span></font><u5:p></u5:p><o:p></= o:p></p> </div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-family:Helvetica'>I think of the signature i= ssues as falling into two classes... I think they map to your classification as well...</span></font><u5:p></u5:p><o:p></o:p></p> <ul style=3D'margin-top:0in' type=3Ddisc> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-fa= mily:Helvetica; font-weight:bold'>Signing tokens</span></font></b><font face=3DHelveti= ca><span style=3D'font-family:Helvetica'> is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span></font><u5:p= ></u5:p><o:p></o:p></li> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-fa= mily:Helvetica; font-weight:bold'>Signing messages</span></font></b><font face=3DHelve= tica><span style=3D'font-family:Helvetica'> is important because it provides a mechanism to ensure that the entity making the API call (and presentin= g an access token) is really the entity that is allowed to make the API cal= l.</span></font><u5:p></u5:p><o:p></o:p></li> </ul> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3DHelvetica><span style=3D'font-size:12.0pt;font-family:Helvetica'>Signing messages applies t= o the re-delegation use cases. I've heard the need for this class of use cases fr= om both the hData (health data) community as well as the user managed access (= UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource server h= onoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span></font>n 9/28/10 12:58 AM, David Recordon wrote: <u5:p></u5:p><o:p>= </o:p></p> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>If you know me then you'll know that I'm general= ly one of the last people to talk about Alice and Bob. That said, there are a lot = of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.<o:p></o:p></span></f= ont><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>From what I've seen there are two distinct class= es of signature use cases.<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>1) The first is where the HTTP request parameter= s must be part of the signature. An example is any OAuth 1.0a style API where you = want to make sure that the HTTP POST your server just received isn't masqueradin= g itself as a GET.<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.<o:p></o= :p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>The main practical example I have of the first u= se case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST reque= st and pass that signature to TwitPic for it to include in the final API reque= st to Twitter.<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>In terms of signing protected resource requests,= I haven't heard anyone bring up specific and detailed needs for this recently= .<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>JSON tokens pretty clearly make sense for the se= cond class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a href=3D"http://developers.facebook.com/docs/authentication/canvas" moz-do-not-send=3Dtrue>http://developers.facebook.com/docs/authentication/c= anvas</a><o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>This second class of use case will also be requi= red by OpenID Connect where the server is signing identity information and sending= it to the client. I imagine that OpenSocial will also still have it and wish t= o continue relying on public key algorithms.<o:p></o:p></span></font><u5:p></= u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>So a few questions:<o:p></o:p></span></font><u5:= p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> * Do we want to tackle both of these class= es of signatures in OAuth?<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> * Why do you consider the second class par= t of OAuth versus something completely separate that might happen to include an OAuth access token?<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> * Is the Twitter redelegation use case the= right focus for the first class?<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> * Is there an example of an OAuth 2.0 serv= er that can't use bearer tokens for protected resource requests and thus requi= res signatures?<o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'> <o:p></o:p></span></font><u5:p></u5:p></p> </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>Thanks,<o:p></o:p></span></font><u5:p></u5:p></p= > </div> <div> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'>--David<o:p></o:p></span></font><u5:p></u5:p></p= > </div> <pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-= size:10.0pt'> <o:p></o:p></span></font><u5:p></u5:p></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '> <o:p></o:p></span></font><u5:p></u5:p></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>_______________________________________________<o:p></o:p></span></font><= u5:p></u5:p></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>OAuth mailing list<o:p></o:p></span></font><u5:p></u5:p></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '><a href=3D"mailto:OAuth@ietf.org" moz-do-not-send=3Dtrue>OAuth@ietf.org</a><o:= p></o:p></span></font><u5:p></u5:p></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '><a href=3D"https://www.ietf.org/mailman/listinfo/oauth" moz-do-not-send=3Dtrue= >https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></span></font><u= 5:p></u5:p></pre> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 color=3D= black face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <o:p></o:p>= </span></font><u5:p></u5:p></p> <p class=3DMsoNormal><u5:p><font size=3D3 color=3Dblack face=3D"Times New R= oman"><span style=3D'font-size:12.0pt'> <o:p></o:p></span></font></u5:p></p> <p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New Roman">= <span style=3D'font-size:12.0pt'><br> <br> <o:p></o:p></span></font></p> <pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-= size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>Chief Architect         &nbs= p;         AIM:  gffletch<o:p>= </o:p></span></font></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>Identity Services Engineering     Work: <a href=3D"mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>= <o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>AOL Inc.           = ;            &n= bsp;  Home: <a href=3D"mailto:gffletch@aol.com">gffletch@aol.com</a><o:p></o:p></span></fo= nt></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>Mobile: +1-703-462-3494         &= nbsp; Blog: <a href=3D"http://practicalid.blogspot.com">http://practicalid.blogspot.com</a= ><o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt= '>Office: +1-703-265-2544        &n= bsp;  Twitter: <a href=3D"http://twitter.com/gffletch">http://twitter.com/gffletch</a><o:p></= o:p></span></font></pre></div> </body> </html> --_000_5710F82C0E73B04FA559560098BF95B124FB23341DUSNAVSXCHMBSA_-- From tim.freeman@hp.com Mon Oct 4 14:09:56 2010 Return-Path: <tim.freeman@hp.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3EB3A70BB for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 14:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.397 X-Spam-Level: X-Spam-Status: No, score=-106.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U06QMdUPdyDl for <oauth@core3.amsl.com>; Mon, 4 Oct 2010 14:09:42 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 69A853A70C7 for <oauth@ietf.org>; Mon, 4 Oct 2010 14:09:42 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id ED291248BC; Mon, 4 Oct 2010 21:10:35 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Oct 2010 21:09:51 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Mon, 4 Oct 2010 21:09:50 +0000 From: "Freeman, Tim" <tim.freeman@hp.com> To: George Fletcher <gffletch@aol.com> Date: Mon, 4 Oct 2010 21:09:49 +0000 Thread-Topic: Signatures don't solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?) Thread-Index: Actj8gF6SeycqNPwS2GpS0U6oOfvhAABLkSw Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AF70@GVW0432EXB.americas.hpqcorp.net> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653964AD76@GVW0432EXB.americas.hpqcorp.net> <4CAA1CBB.80001@aol.com> In-Reply-To: <4CAA1CBB.80001@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AF70GVW0432EXBame_" MIME-Version: 1.0 Cc: OAuth, "Zeltsan, Zachary \(Zachary\)" <zachary.zeltsan@alcatel-lucent.com>, WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 04 Oct 2010 21:09:57 -0000 --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AF70GVW0432EXBame_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogR2VvcmdlIEZsZXRjaGVyIFttYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbV0NCj5NYXliZSBJ IHdhc24ndCBjbGVhciBpbiB0aGUgdXNlIGNhc2UuIFRoZSBwb2ludCBvZiBzaWduYXR1cmVzIGlz IG5vdCB0byBlbmFibGUgYXV0aG9yaXphdGlvbiBidXQgdG8NCj5lbnN1cmUgdGhhdCByZWxlYXNl IG9mIGRhdGEgb25seSBoYXBwZW5zIHdpdGhpbiB0aGUgY29udGV4dCB0aGF0IHdhcyBhdXRob3Jp emVkIGJ5IHRoZSB1c2VyLiBMZXQncw0KPnRha2UgdGhlIGZsaXAgc2lkZSB3aGVyZSBzaWduYXR1 cmVzIGFyZSBub3QgdXNlZC4NCg0KSSBhZ3JlZSB0aGF0IHRha2luZyB0aGUgZmxpcCBzaWRlIHRo ZXJlIGlzIGltcG9ydGFudC4gIEluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIGNsYWltICJYIGlzIGlt cG9ydGFudCBmb3Igc2VjdXJpdHkiIHdpdGggdXNlIGNhc2VzLCB5b3UgbmVlZCBvbmUgdXNlIGNh c2Ugd2hlcmUgWCBpcyBhYnNlbnQgYW5kIHNvbWVvbmUgZ2V0cyBzb21lIGluZm9ybWF0aW9uIHRo ZXkgc2hvdWxkbid0LCBhbmQgYW5vdGhlciB1c2UgY2FzZSB3aGVyZSBYIGlzIHByZXNlbnQgYW5k IGV2ZXJ5dGhpbmcgZWxzZSBpcyBzaW1pbGFyIGFuZCB0aGUgaW5mb3JtYXRpb24gZG9lc24ndCBs ZWFrDQoNCj5Bbnkgc2l0ZSB3aXRoIGFjY2VzcyB0byB0aGUgYmVhcmVyIHRva2VuIGlzc3VlZCB0 bw0KPnNsZWVwd2VsbCBoYXMgYWNjZXNzIHRvIHRoZSBBbGljZSdzIGRhdGEgYXQgdGhlIFBDUC4N Cg0KUGFydCBvZiB0aGUgc3RvcnkgaXMgbWlzc2luZyBoZXJlLiAgSG93IGRpZCB0aGUgc2l0ZSBv dGhlciB0aGFuIHNsZWVwd2VsbCBnZXQgdGhlIGJlYXJlciB0b2tlbiBpc3N1ZWQgdG8gc2xlZXB3 ZWxsPyAgVGhlIG5lZ2F0aXZlIHVzZSBjYXNlIHNob3dpbmcgdGhhdCBiZWFyZXIgdG9rZW5zIGxl YWsgd291bGQgYW5zd2VyIHRoYXQgcXVlc3Rpb24gaW1tZWRpYXRlbHkuDQoNCklmIHRoZSBiZWFy ZXIgdG9rZW4gbGVha3MsIHdoeSBjb3VsZG4ndCBBbGljZSdzIGRhdGEgaGF2ZSBsZWFrZWQgYnkg dGhlIHNhbWUgcGF0aCBpbiBhIHNjaGVtZSB3aXRoIHNpZ25hdHVyZXM/DQoNCihxdW90aW5nIG91 dCBvZiBvcmRlcikNCj5JbiB0aGUgY2FzZSBvZiBoZWFsdGggZGF0YSwganVzdCBwb3NzZXNzaW9u IG9mIGFuIGF1dG9yaXphdGlvbiB0b2tlbiBpcyBOT1QgZ29vZCBlbm91Z2ggdG8gZ3JhbnQgYWNj ZXNzLiAuLi4NCj5UaGlzIGlzIG5vdCBhY2NlcHRhYmxlIHdpdGggc2Vuc2l0aXZlIGRhdGEuDQoN CkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSB5b3UncmUgY29taW5nIGZyb20uICBBcmUgdGhlc2Ug bWVhbnQgdG8gYmUgdGVjaG5pY2FsIHN0YXRlbWVudHMgKHdoaWNoIHdvdWxkIG5lZWQgc29tZSBz b3J0IG9mIGV4cGxhbmF0aW9uIG9yIGV4YW1wbGUpLCBzdGF0ZW1lbnRzIGFib3V0IGxhd3MgbGlr ZSBISVBQQSAod2hpY2ggd291bGQgbmVlZCBjaXRhdGlvbiBvZiB0aGUgcmVsZXZhbnQgbGF3KSwg b3IgaW50dWl0aXZlIHByZWRpY3Rpb25zIGFib3V0IHNvbWUgZnV0dXJlIGNvbnNlbnN1cz8gICBZ b3UgbWlnaHQgYmUgcmlnaHQgYWJvdXQgdGhlIGZ1dHVyZSBjb25zZW5zdXMuICBJIHdhcyBob3Bp bmcgdG8gc2VlIGEgdGVjaG5pY2FsIGp1c3RpZmljYXRpb24gZm9yIGl0LCBidXQgdGhhdCBtaWdo dCBub3QgaGFwcGVuLg0KDQpTaWduYXR1cmVzIGRvIGRlY3JlYXNlIHRoZSBhbW91bnQgdGhhdCBz bGVlcHdlbGwgaGFzIHRvIHRydXN0IHBjcC4gIFdpdGhvdXQgc2lnbmF0dXJlcywgYSBkaXNob25l c3QgcGNwIGNvdWxkIGdpdmUgYSBiZWFyZXIgdG9rZW4gdG8gc2xlZXB3ZWxsLCBwdWJsaXNoIHRo ZSBiZWFyZXIgdG9rZW4gYW5vbnltb3VzbHkgdG8gdGhpcmQgcGFydGllcyB3aG8gbWFrZSB1bmF1 dGhvcml6ZWQgdXNlIG9mIEFsaWNlJ3MgbWVkaWNhbCByZWNvcmRzLCBhbmQgdGhlbiBhdCB0aGUg ZW5kIHdlIGRvbid0IGtub3cgd2hldGhlciB0byBibGFtZSB0aGUgYmVhcmVyIHRva2VuIGxlYWsg b24gc2xlZXB3ZWxsIG9yIHBjcC4gIChUaGF0J3MgdGhlIG5lZ2F0aXZlIHVzZSBjYXNlLikgIFdp dGggc2lnbmF0dXJlcywgcGNwIGlzIHN1cHBvc2VkIHRvIGNoZWNrIHRoYXQgdGhlIGluY29taW5n IHRva2VuIGlzIHNpZ25lZCBieSBzbGVlcHdlbGwsIGFuZCBpZiBpdCByZWNlaXZlcyB0aGUgcHJv cGVybHkgc2lnbmVkIHRva2VuIHdoZW4gc29tZW9uZSBpcyBhY2Nlc3NpbmcgQWxpY2UncyBtZWRp Y2FsIHJlY29yZHMsIGFuZCB0aG9zZSByZWNvcmRzIGxlYWssIHRoZW4gZWl0aGVyIHNsZWVwd2Vs bCBsZWFrZWQgdGhlbSBkaXJlY3RseSBvciBzbGVlcHdlbGwgYWxsb3dlZCBhIHNpZ25lZCB0b2tl biB0byBsZWFrIG9yIHNsZWVwd2VsbCBhbGxvd2VkIGl0cyBwcml2YXRlIGtleSB0byBsZWFrLCBz byB3ZSBrbm93IHdobyB0byAgYmxhbWUuICAoVGhhdCdzIHRoZSBwb3NpdGl2ZSB1c2UgY2FzZS4p ICBJZiB0aGUgcHVycG9zZSBvZiBzaWduYXR1cmVzIGlzIHRvIGFsbG93IGF1ZGl0aW5nIGFuZCBj b3JyZWN0bHkgYXNzaWduaW5nIGJsYW1lIGFmdGVyd2FyZCwgcmF0aGVyIHRoYW4gZGVjcmVhc2lu ZyB0aGUgcmlzayBvZiBBbGljZSdzIHJlY29yZHMgbGVha2luZywgaXQgbWFrZXMgc2Vuc2UgdG8g bWUuDQoNCklmIHRoaXMgaXMgdGhlIHJpZ2h0IHN0b3J5LCB3ZSBkb24ndCBuZWVkIGRpc2NvdmVy eSBpbiBzdGVwIDEsIGFuZCB3ZSBkb24ndCBuZWVkIHRvIHByb3ZlIHdobyBpc3N1ZWQgdGhlIHRv a2VuIGF0IHN0ZXAgMywgYW5kIHdlIGRvIG5lZWQgdG8gYWRkIHRoZSB1c2UgY2FzZSB3aGVyZSBw Y3AgZGlkbid0IGRvIGl0cyBqb2IuICBXZSBhbHNvIGhhdmUgdGhlIGlycml0YXRpbmcgcHJvYmxl bSBvZiBkaXN0cmlidXRpbmcgYSBidW5jaCBvZiBwdWJsaWMga2V5cyBhdCB0aGUgYmVnaW5uaW5n Lg0KDQpUaW0gRnJlZW1hbg0KRW1haWw6IHRpbS5mcmVlbWFuQGhwLmNvbTxtYWlsdG86dGltLmZy ZWVtYW5AaHAuY29tPg0KRGVzayBpbiBQYWxvIEFsdG86ICg2NTApIDg1Ny0yNTgxDQpIb21lOiAo NDA4KSA3NzQtMTI5OA0KQ2VsbDogKDQwOCkgMzQ4LTc1MzYNCg0KRnJvbTogR2VvcmdlIEZsZXRj aGVyIFttYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwNCwg MjAxMCAxMToyOCBBTQ0KVG86IEZyZWVtYW4sIFRpbQ0KQ2M6IFplbHRzYW4sIFphY2hhcnkgKFph Y2hhcnkpOyBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFNpZ25hdHVyZXMgZG9uJ3Qgc29sdmUgdGhh dCBwcm9ibGVtICh3YXMgUkU6IFtPQVVUSC1XR10gU2lnbmF0dXJlcy4uLndoYXQgYXJlIHdlIHRy eWluZyB0byBzb2x2ZT8pDQoNCkhpIFRpbSwNCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suIFNv bWUgY29tbWVudHMvcXVlc3Rpb25zIGlubGluZS4uLg0KDQpPbiAxMC80LzEwIDE6NTkgUE0sIEZy ZWVtYW4sIFRpbSB3cm90ZToNClB1dHRpbmcgdGhlIHVzZSBjYXNlcyBvbiB0aGUgdGFibGUgaXMg Z29vZCBiZWNhdXNlIGl0IG1ha2VzIHRoaW5ncyBtdWNoIGNsZWFyZXIuICBVbmZvcnR1bmF0ZWx5 LCBpdCdzIGNsZWFyIHRoYXQgdGhpcyB1c2UgY2FzZSBkb2VzIG5vdCB3b3JrLg0KDQpJJ2QgbGlr ZSB0byBudW1iZXIgdGhlIHN0ZXBzIHVuZGVyICJSZXF1aXJlbWVudHMiIHNvIEkgY2FuIHJlZmVy IHRvIHRoZW0gdW5hbWJpZ3VvdXNseToNCg0KMS4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5zbGVl cHdlbGwuZXhhbXBsZS5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IGFjY2Vz c2VzIHd3dy5teWhlYWx0aC5leGFtcGxlLmNvbTxodHRwOi8vd3d3Lm15aGVhbHRoLmV4YW1wbGUu Y29tPiB0byBkaXNjb3ZlciB0aGUgbG9jYXRpb24gb2YgdGhlIFBDUCBzeXN0ZW0gKFhSRCBkaXNj b3ZlcnkpDQoyLiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTxo dHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbT4gcmVxdWVzdHMgQWxpY2UgdG8gYXV0aG9y aXplIGFjY2VzcyB0byB0aGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRw Oi8vd3d3LnBjcC5leGFtcGxlLmNvbT4gZm9yIHRoZSBwdXJwb3NlIG9mIHJldHJpZXZpbmcgYmFz aWMgaGVhbHRoIGRhdGEgKGUuZy4gZGF0ZS1vZi1iaXJ0aCwgd2VpZ2h0LCBoZWlnaHQsIGV0Yyku IFRoZSBtZWNoYW5pc20gQWxpY2UgdXNlcyB0byBhdXRob3JpemUgdGhpcyBhY2Nlc3MgaXMgb3V0 IG9mIHNjb3BlIGZvciB0aGlzIHVzZSBjYXNlLg0KMy4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5t eWhlYWx0aC5leGFtcGxlLmNvbTxodHRwOi8vd3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tPiBpc3N1 ZXMgYSB0b2tlbiBib3VuZCB0byB3d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tPiBmb3IgYWNjZXNzIHRvIHRoZSBhcHBsaWNhdGlvbiBhdCB3 d3cucGNwLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tPi4gTm90ZSB0aGF0 IGEgc2lnbmVkIHRva2VuIChKV1QpIGNhbiBiZSB1c2VkIHRvIHByb3ZlIHdobyBpc3N1ZWQgdGhl IHRva2VuLg0KNC4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208 aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IGNvbnN0cnVjdHMgYSByZXF1ZXN0IChp bmNsdWRlcyB0aGUgdG9rZW4gaXNzdWVkIGJ5IHd3dy5teWhlYWx0aC5leGFtcGxlLmNvbTxodHRw Oi8vd3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tPikgdG8gdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5w Y3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20+DQo1LiBUaGUgYXBwbGlj YXRpb24gYXQgd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnNsZWVwd2VsbC5l eGFtcGxlLmNvbT4gc2lnbnMgdGhlIHJlcXVlc3QgYmVmb3JlIHNlbmRpbmcgaXQgdG8gd3d3LnBj cC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbT4NCjYuIFRoZSBhcHBsaWNh dGlvbiBhdCB3d3cucGNwLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tPiBy ZWNlaXZlcyB0aGUgcmVxdWVzdCBhbmQgdmVyaWZpZXMgdGhlIHNpZ25hdHVyZQ0KNy4gVGhlIGFw cGxpY2F0aW9uIGF0IHd3dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBsZS5j b20+IHBhcnNlcyB0aGUgbWVzc2FnZSBhbmQgZmluZHMgdGhlIGF1dGhvcml6YXRpb24gdG9rZW4N CjguIFRoZSBhcHBsaWNhdGlvbiBhdCB3d3cucGNwLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cucGNw LmV4YW1wbGUuY29tPiB2ZXJpZmllcyB0aGUgc2lnbmF0dXJlIG9mIHRoZSBhdXRob3JpemF0aW9u IHRva2VuDQo5LiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8v d3d3LnBjcC5leGFtcGxlLmNvbT4gcGFyc2VzIHRoZSBhdXRob3JpemF0aW9uIHRva2VuIGFuZCB2 ZXJpZmllcyB0aGF0IHRoaXMgdG9rZW4gd2FzIGlzc3VlZCB0byB0aGUgYXBwbGljYXRpb24gYXQg d3d3LnNsZWVwd2VsbC5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuY29tPg0KMTAuIFRoZSBhcHBs aWNhdGlvbiBhdCB3d3cucGNwLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cucGNwLmV4YW1wbGUuY29t PiByZXRyaWV2ZXMgdGhlIHJlcXVlc3RlZCBkYXRhIGFuZCByZXR1cm5zIGl0IHRvIHRoZSBhcHBs aWNhdGlvbiBhdCB3d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxs LmV4YW1wbGUuY29tPg0KDQoNClRoZSBzdGF0ZWQgcHVycG9zZSBvZiBzaWduYXR1cmVzIGlzOg0K DQo+VGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3Au ZXhhbXBsZS5jb20+IHZlcmlmaWVzIHRoYXQgQWxpY2UgaGFzIGF1dGhvcml6ZWQNCj53d3cuc2xl ZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPiB0byBh Y2Nlc3MgaGVyIGhlYWx0aCBkYXRhIGFzIHdlbGwgYXMgZW5mb3JjZXMNCj50aGF0IHd3dy5zbGVl cHdlbGwuZXhhbXBsZS5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IGlzIHRo ZSBvbmx5IGFwcGxpY2F0aW9uIHRoYXQgY2FuIHJldHJpZXZlIHRoYXQNCj5kYXRhIHdpdGggdGhh dCBzcGVjaWZpYyBhdXRob3JpemF0aW9uLg0KDQpJJ2xsIGFiYnJldmlhdGUgZG9tYWluIG5hbWVz IGxpa2UgInd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhh bXBsZS5jb20+IiB0byAic2xlZXB3ZWxsIi4NCg0KDQpCZWFyZXIgdG9rZW5zIHdvcmsgZmluZSB3 aGVuIHZlcmlmeWluZyB0aGF0IEFsaWNlIGhhcyBhdXRob3JpemVkICBzbGVlcHdlbGw8aHR0cDov L3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IHRvIGFjY2VzcyBoZXIgaGVhbHRoIGRhdGEsIHNv IHRoZSBjbGFpbSBpcyBhcHBhcmVudGx5IHRoYXQgc2lnbmF0dXJlcyBnaXZlIHRoZSBhZGRlZCBi ZW5lZml0IG9mIGVuZm9yY2luZyB0aGF0IHNsZWVwd2VsbDxodHRwOi8vd3d3LnNsZWVwd2VsbC5l eGFtcGxlLmNvbT4gaXMgdGhlIG9ubHkgYXBwbGljYXRpb24gdGhhdCBjYW4gcmV0cmlldmUgdGhh dCBkYXRhIHdpdGggdGhhdCBzcGVjaWZpYyBhdXRob3JpemF0aW9uLg0KSSBzdXBwb3NlIHRoaXMg ZGVwZW5kcyBvbiBob3cgeW91IGRlZmluZSAid29yayBmaW5lIi4gV2hpbGUgdGhlIGF1dGhvcml6 YXRpb24gdG9rZW4gaXNzdWVkIGJ5IG15aGVhbHRoZGF0YSBhbmQgZ2l2ZW4gdG8gc2xlZXB3ZWxs IHRvIHByZXNlbnQgdG8gcGNwIGNhbiBiZSBwYXNzZWQgYXMgYSBiZWFyZXIgdG9rZW4gKHNvIGlu IHRoYXQgc2Vuc2UgaXQgd29ya3MgZmluZSkgdGhlcmUgaXMgbm8gc2VjdXJpdHkgYXJvdW5kIHRo ZSB0b2tlbi4gSW4gdGhlIGNhc2Ugb2YgaGVhbHRoIGRhdGEsIGp1c3QgcG9zc2Vzc2lvbiBvZiBh biBhdXRvcml6YXRpb24gdG9rZW4gaXMgTk9UIGdvb2QgZW5vdWdoIHRvIGdyYW50IGFjY2Vzcy4N Cg0KSW5zdGVhZCB0aGUgUENQIHNpdGUgbmVlZHMgdG8gZW5zdXJlIHRoYXQgdGhlIHByZXNlbnRp bmcgZW50aXR5IGlzIHNwZWNpZmljYWxseSBhdXRob3JpemVkIGJ5IHRoZSBBdXRob3JpemF0aW9u IFNlcnZlci4gSSBjb250ZW5kIHRoYXQgdG8gZXN0YWJsaXNoIHRoaXMgImNoYWluIG9mIHRydXN0 IiBzaWduYXR1cmVzIGFyZSBuZWVkZWQuDQoNCkdpdmVuIHRoYXQgaW4gbW9zdCBjYXNlcyBwY3Ag d2lsbCB3YW50IHRvIGRlY29kZSB0aGUgdG9rZW4gaXRzZWxmLCBpdCB3aWxsIG5lZWQgc29tZSBm b3JtIG9mIHNpZ25lZCBzdHJ1Y3R1cmVkIHRva2VuIGJlY2F1c2UgcGNwIGlzIHRoZSByZWNpcGll bnQgb2YgdGhlIHRva2VuIGFuZCBub3QgdGhlIGlzc3Vlci4NCg0KDQoNClVuZm9ydHVuYXRlbHks IHNpZ25hdHVyZXMgZG8gbm90IGRvIHRoYXQuICBTdXBwb3NlIHNsZWVwd2VsbCB3YW50ZWQgdG8g Z2l2ZSBBbGljZSdzIGRhdGEgdG8gYXBuZWFjaGVjay4gIFNsZWVwd2VsbCBjb3VsZCBmb2xsb3cg dGhlIHByb3RvY29sIHVwIHRvIHN0ZXAgNC4gIFRoZW4sIGluc3RlYWQgb2Ygc2lnbmluZyB0aGUg cmVxdWVzdCBhbmQgc2VuZGluZyB0aGUgc2lnbmVkIHJlcXVlc3QgdG8gcGNwLCBzbGVlcHdlbGwg Y291bGQgdHJhbnNtaXQgdGhlIHNpZ25lZCByZXF1ZXN0IHRvIGFwbmVhY2hlY2suICBhcG5lYWNo ZWNrIGNvdWxkIHRoZW4gY29tcGxldGUgdGhlIHByb3RvY29sIGFuZCBnZXQgQWxpY2UncyBkYXRh IGZyb20gd3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbT4uDQpN YXliZSBJIHdhc24ndCBjbGVhciBpbiB0aGUgdXNlIGNhc2UuIFRoZSBwb2ludCBvZiBzaWduYXR1 cmVzIGlzIG5vdCB0byBlbmFibGUgYXV0aG9yaXphdGlvbiBidXQgdG8gZW5zdXJlIHRoYXQgcmVs ZWFzZSBvZiBkYXRhIG9ubHkgaGFwcGVucyB3aXRoaW4gdGhlIGNvbnRleHQgdGhhdCB3YXMgYXV0 aG9yaXplZCBieSB0aGUgdXNlci4gTGV0J3MgdGFrZSB0aGUgZmxpcCBzaWRlIHdoZXJlIHNpZ25h dHVyZXMgYXJlIG5vdCB1c2VkLiBBbnkgc2l0ZSB3aXRoIGFjY2VzcyB0byB0aGUgYmVhcmVyIHRv a2VuIGlzc3VlZCB0byBzbGVlcHdlbGwgaGFzIGFjY2VzcyB0byB0aGUgQWxpY2UncyBkYXRhIGF0 IHRoZSBQQ1AuIFRoaXMgaXMgbm90IGFjY2VwdGFibGUgd2l0aCBzZW5zaXRpdmUgZGF0YS4NCg0K U28gdGhlIHBvaW50IG9mIHNpZ25hdHVyZXMgaW4gdGhpcyB1c2UgY2FzZSBpcyB0byBjcmVhdGUg YSBiaW5kaW5nIGJldHdlZW4gdGhlIGlzc3VlciBvZiB0aGUgdG9rZW4gKG15aGVhbHRoZGF0YSks IHRoZSBwcmVzZW50ZXIgb2YgdGhlIHRva2VuIChzbGVlcHdlbGwpIGFuZCB0aGUgcmVjZWl2ZXIg b2YgdGhlIHRva2VuIChwY3ApLg0KDQpJZiBzbGVlcHdlbGwgc2lnbnMgdGhlIG1lc3NhZ2Ugc2Vu dCB0byBwY3AsIHRoZW4gcGNwIGNhbiB2ZXJpZnkgdGhhdCBzbGVlcHdlbGwgaXMgdGhlIHNlbmRl ciBvZiB0aGUgbWVzc2FnZS4gTmV4dCwgaWYgdGhlIG1lc3NhZ2UgY29udGFpbnMgYSB0b2tlbiBz aWduZWQgYnkgbXloZWFsdGggZGF0YSwgYW5kIHRoYXQgdG9rZW4gaW5jbHVkZXMgYSBjbGFpbSB0 aGF0IHRoZSB0b2tlbiBpcyBpc3N1ZWQgdG8gc2xlZXB3ZWxsLiBQQ1AgY2FuICJjb25uZWN0IHRo ZSBkb3RzIiBhbmQga25vdyB0aGF0IHRoaXMgaXMgYSB2YWxpZCByZXF1ZXN0Lg0KDQpJZiB0aGUg dG9rZW4gaXMgc2VudCBieSBhbm90aGVyIHNlcnZlciwgdGhlICJpc3N1ZWQgdG8iIGNsYWltIHdp bGwgbm90IG1hdGNoIHRoZSBlbnRpdHkgdGhhdCBzaWduZWQgdGhlIG1lc3NhZ2UgYW5kIHRoZSBQ Q1AgYXBwbGljYXRpb24gd2lsbCByZWplY3QgdGhlIHJlcXVlc3QuDQoNCg0KSWYgc2xlZXB3ZWxs IGhhcyBjYW4gcmV0cml2ZSB0byBBbGljZSdzIGRhdGEsIGFuZCB0aGUgcHJvdG9jb2wgZG9lc24n dCBtYW5kYXRlIGFuIGludmFzaXZlIGNvbnRyb2wgb2Ygc2xlZXB3ZWxsJ3MgY29tcHV0YXRpb24g YW5kIG91dHB1dHMsIGl0J3MgaG9wZWxlc3MgdG8gcHJldmVudCBzbGVlcHdlbGwgZnJvbSBhbGxv d2luZyBhcG5lYWNoZWNrIHRvIHJldHJpZXZlIEFsaWNlJ3MgZGF0YS4gIElmIGFsbCBlbHNlIGZh aWxzLCBzbGVlcHdlbGwgY291bGQgYWNjZXNzIEFsaWNlJ3MgZGF0YSBpdHNlbGYgYW5kIHRoZW4g YWxsb3cgYXBuZWFjaGVjayB0byBhY2Nlc3MgdGhlIGRhdGEgZnJvbSBzbGVlcHdlbGwuDQpTbyBJ J2xsIGNvbmNlZGUgdGhhdCBvbmNlIHNsZWVwd2VsbCBoYXMgdGhlIGRhdGEsIGlmIHNsZWVwd2Vs bCBpcyBub3QgdHJ1c3R3b3J0aHksIHRoZXJlIGlzIGxpdHRsZSBBbGljZSBjYW4gZG8gdG8gcHJv dGVjdCBoZXIgZGF0YS4gTWF5YmUgbGF3cyBhbmQgb3RoZXIgc3VjaCBtZWNoYW5pc21zIHdpbGwg YmUgZGV2ZWxvcGVkIHRvIGRlYWwgd2l0aCB0aGlzIHNjZW5hcmlvLiBUaGlzIGlzIG9uZSByZWFz b24gd2h5IGl0J3Mgc28gaW1wb3J0YW50IGZvciB0aGUgUENQIHRvIG9ubHkgcmVsZWFzZSBkYXRh IHRvIHRoZSBzcGVjaWZpYyBlbnRpdHkgdGhhdCB3YXMgYXV0aG9yaXplZC4gVGhpcyBpcyBub3Qg cG9zc2libGUgd2l0aCBiZWFyZXIgdG9rZW5zIGluIGEgZGVsZWdhdGVkIHVzZSBjYXNlIGxpa2Ug dGhpcyBvbmUuDQoNCg0KRm9yIGFsbCBJIGtub3csIHNpZ25hdHVyZXMgbWlnaHQgYmUgYSBzb2x1 dGlvbiB0byBzb21lIHByb2JsZW0sIGJ1dCB0aGV5IGFyZW4ndCBhIHNvbHV0aW9uIHRvIHRoaXMg cHJvYmxlbS4NCg0KVGltIEZyZWVtYW4NCkVtYWlsOiB0aW0uZnJlZW1hbkBocC5jb208bWFpbHRv OnRpbS5mcmVlbWFuQGhwLmNvbT4NCkRlc2sgaW4gUGFsbyBBbHRvOiAoNjUwKSA4NTctMjU4MQ0K SG9tZTogKDQwOCkgNzc0LTEyOTgNCkNlbGw6ICg0MDgpIDM0OC03NTM2DQoNCkZyb206IG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnZSBGbGV0Y2hlcg0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDA0LCAyMDEwIDk6MjAgQU0NClRvOiBaZWx0c2FuLCBaYWNoYXJ5 IChaYWNoYXJ5KQ0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaWduYXR1 cmVzLi4ud2hhdCBhcmUgd2UgdHJ5aW5nIHRvIHNvbHZlPw0KDQpIaSBaYWNoYXJ5LA0KDQpIZXJl IGlzIGEgdXNlIGNhc2UgZm9yIHNpZ25lZCBtZXNzYWdlcy4gSSd2ZSB0cmllZCB0byBrZWVwIHRo aXMgaW4gdGhlIGZvcm1hdCBvZiB0aGUgb3RoZXIgT0F1dGggdXNlIGNhc2VzLiBQbGVhc2UgY29u dGFjdCBtZSBvZmYtbGlzdCBpZiB0aGVyZSBhcmUgZWRpdG9yaWFsIGNoYW5nZXMgcmVxdWlyZWQu IEkndmUgaW5jbHVkZSB0aGUgbGlzdCB0byBzZWUgaWYgb3RoZXJzIGhhdmUgZmVlZCBiYWNrIG9u IHRoaXMgdXNlIGNhc2UuDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpVc2UgY2FzZTogU2lnbmVkIE1l c3NhZ2VzDQoNCkRlc2NyaXB0aW9uOg0KDQpBbGljZSBtYW5hZ2VzIGFsbCBoZXIgcGVyc29uYWwg aGVhbHRoIHJlY29yZHMgaW4gaGVyIHBlcnNvbmFsIGhlYWx0aCBkYXRhIHN0b3JlICh3d3cubXlo ZWFsdGguZXhhbXBsZS5jb208aHR0cDovL3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbT4pLiBBbGlj ZSdzIFByaW1hcnkgQ2FyZSBQaHlzaWNpYW4gKHd3dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3 dy5wY3AuZXhhbXBsZS5jb20+KSByZWNvbW1lbmRzIHRoYXQgQWxpY2Ugc2VlIGEgc2xlZXAgc3Bl Y2lhbGlzdCAod3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnNsZWVwd2VsbC5l eGFtcGxlLmNvbT4pLiBBbGljZSBhcnJpdmVzIGF0IHRoZSBzbGVlcCBzcGVjaWFsaXN0J3Mgb2Zm aWNlIGFuZCBhdXRob3JpemVzIGl0IHRvIGFjY2VzcyBoZXIgYmFzaWMgaGVhbHRoIGRhdGEgZnJv bSBoZXIgUENQLiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8v d3d3LnBjcC5leGFtcGxlLmNvbT4gdmVyaWZpZXMgdGhhdCBBbGljZSBoYXMgYXV0aG9yaXplZCB3 d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29t PiB0byBhY2Nlc3MgaGVyIGhlYWx0aCBkYXRhIGFzIHdlbGwgYXMgZW5mb3JjZXMgdGhhdCB3d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPiBp cyB0aGUgb25seSBhcHBsaWNhdGlvbiB0aGF0IGNhbiByZXRyaWV2ZSB0aGF0IGRhdGEgd2l0aCB0 aGF0IHNwZWNpZmljIGF1dGhvcml6YXRpb24uDQoNClByZS1jb25kaXRpb25zOg0KDQoqIEFsaWNl IGhhcyBhIHBlcnNvbmFsIGhlYWx0aCBkYXRhIHN0b3JlIHRoYXQgYWxsb3dzIGZvciBkaXNjb3Zl cnkgb2YgaGVyIHBhcnRpY2lwYXRpbmcgaGVhbHRoIHN5c3RlbXMgKGUuZy4gcHN5Y2hpYXRyaXN0 LCBzbGVlcCBzcGVjaWFsaXN0LCBwY3AsIG9ydGhvZG9udGlzdCwgb3BodGhhbG1vbG9naXN0LCBl dGMpLg0KKiBUaGUgYXBwbGljYXRpb24gYXQgd3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tPGh0dHA6 Ly93d3cubXloZWFsdGguZXhhbXBsZS5jb20+IG1hbmFnZXMgYXV0aG9yaXphdGlvbiBvZiBhY2Nl c3MgdG8gQWxpY2UncyBwYXJ0aWNpcGF0aW5nIGhlYWx0aCBzeXN0ZW1zDQoqIFRoZSBhcHBsaWNh dGlvbiBhdCB3d3cubXloZWFsdGguZXhhbXBsZS5jb208aHR0cDovL3d3dy5teWhlYWx0aC5leGFt cGxlLmNvbT4gY2FuIGlzc3VlcyBhdXRob3JpemF0aW9uIHRva2VucyB1bmRlcnN0b29kIGJ5IEFs aWNlJ3MgcGFydGljaXBhdGluZyBoZWFsdGggc3lzdGVtcw0KKiBUaGUgYXBwbGljYXRpb24gYXQg d3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbT4gc3RvcmVzIEFs aWNlJ3MgYmFzaWMgaGVhbHRoIGFuZCBwcmVzY3JpcHRpb24gcmVjb3Jkcw0KKiBUaGUgYXBwbGlj YXRpb24gYXQgd3d3LnNsZWVwd2VsbC5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuY29tPiBzdG9y ZXMgcmVzdWx0cyBvZiBBbGljZSdzIHNsZWVwIHRlc3RzDQoNCg0KUG9zdC1jb25kaXRpb25zOg0K KiBBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlIHJlc3VsdHMgaW4ganVzdCB0aGUgaW5mb3JtYXRpb24g dGhhdCBBbGljZSBhdXRob3JpemVkIGJlaW5nIHRyYW5zZmVycmVkIGZyb20gdGhlIFByaW1hcnkg Q2FyZSBQaHlzaWNpYW4gKHd3dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBs ZS5jb20+KSB0byB0aGUgc2xlZXAgc3BlY2lhbGlzdCAod3d3LnNsZWVwd2VsbC5leGFtcGxlLmNv bTxodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbT4pLg0KKiBUaGUgdHJhbnNmZXIgb2Yg aGVhbHRoIGRhdGEgb25seSBvY2N1cnMgaWYgdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5wY3AuZXhh bXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20+IGNhbiB2ZXJpZnkgdGhhdCB3d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPiBp cyB0aGUgcGFydHkgcmVxdWVzdGluZyBhY2Nlc3MgYW5kIHRoYXQgdGhlIGF1dGhvcml6YXRpb24g dG9rZW4gcHJlc2VudGVkIGJ5IHd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208aHR0cDovL3d3dy5z bGVlcHdlbGwuZXhhbXBsZS5jb20+IGlzIGlzc3VlZCBieSB0aGUgYXBwbGljYXRpb24gYXQgd3d3 Lm15aGVhbHRoLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cubXloZWFsdGguZXhhbXBsZS5jb20+IHdp dGggYSByZXN0cmljdGVkIGF1ZGllbmNlIG9mIHd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208aHR0 cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+DQoNClJlcXVpcmVtZW50czoNCjEuIFRoZSBh cHBsaWNhdGlvbiBhdCB3d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3 ZWxsLmV4YW1wbGUuY29tPiBhY2Nlc3NlcyB3d3cubXloZWFsdGguZXhhbXBsZS5jb208aHR0cDov L3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbT4gdG8gZGlzY292ZXIgdGhlIGxvY2F0aW9uIG9mIHRo ZSBQQ1Agc3lzdGVtIChYUkQgZGlzY292ZXJ5KQ0KMi4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5z bGVlcHdlbGwuZXhhbXBsZS5jb208aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IHJl cXVlc3RzIEFsaWNlIHRvIGF1dGhvcml6ZSBhY2Nlc3MgdG8gdGhlIGFwcGxpY2F0aW9uIGF0IHd3 dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20+IGZvciB0aGUgcHVy cG9zZSBvZiByZXRyaWV2aW5nIGJhc2ljIGhlYWx0aCBkYXRhIChlLmcuIGRhdGUtb2YtYmlydGgs IHdlaWdodCwgaGVpZ2h0LCBldGMpLiBUaGUgbWVjaGFuaXNtIEFsaWNlIHVzZXMgdG8gYXV0aG9y aXplIHRoaXMgYWNjZXNzIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyB1c2UgY2FzZS4NCjMuIFRo ZSBhcHBsaWNhdGlvbiBhdCB3d3cubXloZWFsdGguZXhhbXBsZS5jb208aHR0cDovL3d3dy5teWhl YWx0aC5leGFtcGxlLmNvbT4gaXNzdWVzIGEgdG9rZW4gYm91bmQgdG8gd3d3LnNsZWVwd2VsbC5l eGFtcGxlLmNvbTxodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbT4gZm9yIGFjY2VzcyB0 byB0aGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8vd3d3LnBjcC5l eGFtcGxlLmNvbT4uIE5vdGUgdGhhdCBhIHNpZ25lZCB0b2tlbiAoSldUKSBjYW4gYmUgdXNlZCB0 byBwcm92ZSB3aG8gaXNzdWVkIHRoZSB0b2tlbi4NCjQuIFRoZSBhcHBsaWNhdGlvbiBhdCB3d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPiBj b25zdHJ1Y3RzIGEgcmVxdWVzdCAoaW5jbHVkZXMgdGhlIHRva2VuIGlzc3VlZCBieSB3d3cubXlo ZWFsdGguZXhhbXBsZS5jb208aHR0cDovL3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbT4pIHRvIHRo ZSBhcHBsaWNhdGlvbiBhdCB3d3cucGNwLmV4YW1wbGUuY29tPGh0dHA6Ly93d3cucGNwLmV4YW1w bGUuY29tPg0KNS4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208 aHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20+IHNpZ25zIHRoZSByZXF1ZXN0IGJlZm9y ZSBzZW5kaW5nIGl0IHRvIHd3dy5wY3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBs ZS5jb20+DQo2LiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRwOi8v d3d3LnBjcC5leGFtcGxlLmNvbT4gcmVjZWl2ZXMgdGhlIHJlcXVlc3QgYW5kIHZlcmlmaWVzIHRo ZSBzaWduYXR1cmUNCjcuIFRoZSBhcHBsaWNhdGlvbiBhdCB3d3cucGNwLmV4YW1wbGUuY29tPGh0 dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tPiBwYXJzZXMgdGhlIG1lc3NhZ2UgYW5kIGZpbmRzIHRo ZSBhdXRob3JpemF0aW9uIHRva2VuDQo4LiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFt cGxlLmNvbTxodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbT4gdmVyaWZpZXMgdGhlIHNpZ25hdHVy ZSBvZiB0aGUgYXV0aG9yaXphdGlvbiB0b2tlbg0KOS4gVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5w Y3AuZXhhbXBsZS5jb208aHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20+IHBhcnNlcyB0aGUgYXV0 aG9yaXphdGlvbiB0b2tlbiBhbmQgdmVyaWZpZXMgdGhhdCB0aGlzIHRva2VuIHdhcyBpc3N1ZWQg dG8gdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5zbGVlcHdlbGwuY29tPGh0dHA6Ly93d3cuc2xlZXB3 ZWxsLmNvbT4NCjEwLiBUaGUgYXBwbGljYXRpb24gYXQgd3d3LnBjcC5leGFtcGxlLmNvbTxodHRw Oi8vd3d3LnBjcC5leGFtcGxlLmNvbT4gcmV0cmlldmVzIHRoZSByZXF1ZXN0ZWQgZGF0YSBhbmQg cmV0dXJucyBpdCB0byB0aGUgYXBwbGljYXRpb24gYXQgd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNv bTxodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbT4NCg0KDQoNCk9uIDkvMjgvMTAgMTI6 MjcgUE0sIFplbHRzYW4sIFphY2hhcnkgKFphY2hhcnkpIHdyb3RlOg0KVGhlc2UgdXNlIGNhc2Vz IGFyZSBub3QgaW4gdGhlIGRyYWZ0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXplbHRzYW4tdXNlLWNhc2VzLW9hdXRoLg0KQ291bGQgeW91IHdyaXRlIHRoZW0gdXA/DQoN ClRoYW5rcywNClphY2hhcnkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnZSBGbGV0 Y2hlcg0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI4LCAyMDEwIDExOjM5IEFNDQpUbzogT0F1 dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNpZ25hdHVyZXMuLi53aGF0IGFyZSB3ZSB0 cnlpbmcgdG8gc29sdmU/DQoNCkkgdGhpbmsgb2YgdGhlIHNpZ25hdHVyZSBpc3N1ZXMgYXMgZmFs bGluZyBpbnRvIHR3byBjbGFzc2VzLi4uIEkgdGhpbmsgdGhleSBtYXAgdG8geW91ciBjbGFzc2lm aWNhdGlvbiBhcyB3ZWxsLi4uDQoNCiAqICAgU2lnbmluZyB0b2tlbnMgaXMgaW1wb3J0YW50IGZv ciBpbnRlcm9wZXJhYmlsaXR5IGVzcGVjaWFsbHkgbG9va2luZyBmb3J3YXJkIHRvIGEgdGltZSB3 aGVuIHRva2VucyBpc3N1ZWQgYnkgbXVsdGlwbGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIGFyZSBh Y2NlcHRlZCBhdCBhIGdpdmVuIGhvc3QuDQogKiAgIFNpZ25pbmcgbWVzc2FnZXMgaXMgaW1wb3J0 YW50IGJlY2F1c2UgaXQgcHJvdmlkZXMgYSBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQgdGhlIGVu dGl0eSBtYWtpbmcgdGhlIEFQSSBjYWxsIChhbmQgcHJlc2VudGluZyBhbiBhY2Nlc3MgdG9rZW4p IGlzIHJlYWxseSB0aGUgZW50aXR5IHRoYXQgaXMgYWxsb3dlZCB0byBtYWtlIHRoZSBBUEkgY2Fs bC4NClNpZ25pbmcgbWVzc2FnZXMgYXBwbGllcyB0byB0aGUgcmUtZGVsZWdhdGlvbiB1c2UgY2Fz ZXMuIEkndmUgaGVhcmQgdGhlIG5lZWQgZm9yIHRoaXMgY2xhc3Mgb2YgdXNlIGNhc2VzIGZyb20g Ym90aCB0aGUgaERhdGEgKGhlYWx0aCBkYXRhKSBjb21tdW5pdHkgYXMgd2VsbCBhcyB0aGUgdXNl ciBtYW5hZ2VkIGFjY2VzcyAoVU1BKSBjb21tdW5pdHkuDQoNClNpZ25pbmcgdG9rZW5zIGNvdmVy cyBib3RoIHlvdXIgc2Vjb25kIGNsYXNzIG9mIHRva2VucyBhcyB3ZWxsIGFzIGFub3RoZXIgdXNl IGNhc2UgdGhhdCBFcmFuIGhhcyBtZW50aW9uZWQgYXMgd2VsbC4gTmFtZWx5LCBhIHByb3RlY3Rl ZCByZXNvdXJjZSBzZXJ2ZXIgaG9ub3JpbmcgdG9rZW5zIGZyb20gbXVsdGlwbGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXJzLg0KDQpUaGVzZSBhcmUgdGhlIHR3byBjbGFzc2VzIG9mIHVzZSBjYXNlcyB0 aGF0IEknZCBsaWtlIHRvIHNlZSBzb2x2ZWQuDQoNClRoYW5rcywNCkdlb3JnZQ0KDQoNCk9uIDkv MjgvMTAgMTI6NTggQU0sIERhdmlkIFJlY29yZG9uIHdyb3RlOg0KSWYgeW91IGtub3cgbWUgdGhl biB5b3UnbGwga25vdyB0aGF0IEknbSBnZW5lcmFsbHkgb25lIG9mIHRoZSBsYXN0IHBlb3BsZSB0 byB0YWxrIGFib3V0IEFsaWNlIGFuZCBCb2IuIFRoYXQgc2FpZCwgdGhlcmUgYXJlIGEgbG90IG9m IHRlY2huaWNhbCBwcm9wb3NhbHMgZmx5aW5nIGFjcm9zcyB0aGUgbGlzdCB3aXRoIHZlcnkgbGl0 dGxlIHNoYXJlZCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9ibGVtKHMpIHdlJ3JlIHRyeWluZyB0 byBzb2x2ZS4NCg0KRnJvbSB3aGF0IEkndmUgc2VlbiB0aGVyZSBhcmUgdHdvIGRpc3RpbmN0IGNs YXNzZXMgb2Ygc2lnbmF0dXJlIHVzZSBjYXNlcy4NCjEpIFRoZSBmaXJzdCBpcyB3aGVyZSB0aGUg SFRUUCByZXF1ZXN0IHBhcmFtZXRlcnMgbXVzdCBiZSBwYXJ0IG9mIHRoZSBzaWduYXR1cmUuIEFu IGV4YW1wbGUgaXMgYW55IE9BdXRoIDEuMGEgc3R5bGUgQVBJIHdoZXJlIHlvdSB3YW50IHRvIG1h a2Ugc3VyZSB0aGF0IHRoZSBIVFRQIFBPU1QgeW91ciBzZXJ2ZXIganVzdCByZWNlaXZlZCBpc24n dCBtYXNxdWVyYWRpbmcgaXRzZWxmIGFzIGEgR0VULg0KMikgVGhlIHNlY29uZCBpcyB3aGVyZSB0 aGUgSFRUUCByZXF1ZXN0IGlzIG9ydGhvZ29uYWwuIEFuIGV4YW1wbGUgaXMgT3BlblNvY2lhbCB3 aGVyZSB0aGUgc2VydmVyIGlzIHNlbmRpbmcgc3RhdGUgaW5mb3JtYXRpb24gdG8gdGhlIGNsaWVu dCBzdWNoIGFzIHdoYXQgdXNlciBpcyBjdXJyZW50bHkgbG9nZ2VkIGluLg0KDQpUaGUgbWFpbiBw cmFjdGljYWwgZXhhbXBsZSBJIGhhdmUgb2YgdGhlIGZpcnN0IHVzZSBjYXNlIGlzIHdoYXQgVHdp dHRlciB3YW50cyB0byBkbyB3aXRoIHJlZGVsZWdhdGlvbi4gSW4gdGhpcyBjYXNlIFR3ZWV0RGVj ayBjYW4ndCBnaXZlbiBUd2l0UGljIGl0J3Mgb3duIGJlYXJlciB0b2tlbiwgYnV0IG5lZWRzIHRv IHNpZ24gdGhlIFBPU1QgcmVxdWVzdCBhbmQgcGFzcyB0aGF0IHNpZ25hdHVyZSB0byBUd2l0UGlj IGZvciBpdCB0byBpbmNsdWRlIGluIHRoZSBmaW5hbCBBUEkgcmVxdWVzdCB0byBUd2l0dGVyLg0K DQpJbiB0ZXJtcyBvZiBzaWduaW5nIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cywgSSBoYXZl bid0IGhlYXJkIGFueW9uZSBicmluZyB1cCBzcGVjaWZpYyBhbmQgZGV0YWlsZWQgbmVlZHMgZm9y IHRoaXMgcmVjZW50bHkuDQoNCkpTT04gdG9rZW5zIHByZXR0eSBjbGVhcmx5IG1ha2Ugc2Vuc2Ug Zm9yIHRoZSBzZWNvbmQgY2xhc3Mgb2Ygc2lnbmF0dXJlIHVzZSBjYXNlcyBhbmQgaXQncyBhY3R1 YWxseSBhIGJpdCBoYXJkIHRvIGFyZ3VlIHdoeSB0aGV5IHdvdWxkIGJlIGEgcGFydCBvZiBPQXV0 aC4gRmFjZWJvb2sgc2hpcHBlZCB0aGlzIGEgYml0IG92ZXIgYSBtb250aCBhZ28gZm9yIGNhbnZh cyBhcHBsaWNhdGlvbnMuIFdlIGluY2x1ZGUgYSBgc2lnbmVkX3JlcXVlc3RgIHBhcmFtZXRlciB3 aGljaCBpcyBzaWduYXR1cmUuYmFzZTY0dXJsKEpTT04pLiBQYXJzaW5nIGl0IGlzIDE4IGxpbmVz IG9mIFBIUC4gaHR0cDovL2RldmVsb3BlcnMuZmFjZWJvb2suY29tL2RvY3MvYXV0aGVudGljYXRp b24vY2FudmFzDQoNClRoaXMgc2Vjb25kIGNsYXNzIG9mIHVzZSBjYXNlIHdpbGwgYWxzbyBiZSBy ZXF1aXJlZCBieSBPcGVuSUQgQ29ubmVjdCB3aGVyZSB0aGUgc2VydmVyIGlzIHNpZ25pbmcgaWRl bnRpdHkgaW5mb3JtYXRpb24gYW5kIHNlbmRpbmcgaXQgdG8gdGhlIGNsaWVudC4gSSBpbWFnaW5l IHRoYXQgT3BlblNvY2lhbCB3aWxsIGFsc28gc3RpbGwgaGF2ZSBpdCBhbmQgd2lzaCB0byBjb250 aW51ZSByZWx5aW5nIG9uIHB1YmxpYyBrZXkgYWxnb3JpdGhtcy4NCg0KU28gYSBmZXcgcXVlc3Rp b25zOg0KICogRG8gd2Ugd2FudCB0byB0YWNrbGUgYm90aCBvZiB0aGVzZSBjbGFzc2VzIG9mIHNp Z25hdHVyZXMgaW4gT0F1dGg/DQogKiBXaHkgZG8geW91IGNvbnNpZGVyIHRoZSBzZWNvbmQgY2xh c3MgcGFydCBvZiBPQXV0aCB2ZXJzdXMgc29tZXRoaW5nIGNvbXBsZXRlbHkgc2VwYXJhdGUgdGhh dCBtaWdodCBoYXBwZW4gdG8gaW5jbHVkZSBhbiBPQXV0aCBhY2Nlc3MgdG9rZW4/DQogKiBJcyB0 aGUgVHdpdHRlciByZWRlbGVnYXRpb24gdXNlIGNhc2UgdGhlIHJpZ2h0IGZvY3VzIGZvciB0aGUg Zmlyc3QgY2xhc3M/DQogKiBJcyB0aGVyZSBhbiBleGFtcGxlIG9mIGFuIE9BdXRoIDIuMCBzZXJ2 ZXIgdGhhdCBjYW4ndCB1c2UgYmVhcmVyIHRva2VucyBmb3IgcHJvdGVjdGVkIHJlc291cmNlIHJl cXVlc3RzIGFuZCB0aHVzIHJlcXVpcmVzIHNpZ25hdHVyZXM/DQoNClRoYW5rcywNCi0tRGF2aWQN Cg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg0KDQoNCg0KLS0NCg0KQ2hpZWYgQXJjaGl0ZWN0ICAgICAgICAgICAgICAgICAgIEFJTTogIGdm ZmxldGNoDQoNCklkZW50aXR5IFNlcnZpY2VzIEVuZ2luZWVyaW5nICAgICBXb3JrOiBnZW9yZ2Uu ZmxldGNoZXJAdGVhbWFvbC5jb208bWFpbHRvOmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbT4N Cg0KQU9MIEluYy4gICAgICAgICAgICAgICAgICAgICAgICAgIEhvbWU6IGdmZmxldGNoQGFvbC5j b208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+DQoNCk1vYmlsZTogKzEtNzAzLTQ2Mi0zNDk0ICAg ICAgICAgICBCbG9nOiBodHRwOi8vcHJhY3RpY2FsaWQuYmxvZ3Nwb3QuY29tDQoNCk9mZmljZTog KzEtNzAzLTI2NS0yNTQ0ICAgICAgICAgICBUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vZ2Zm bGV0Y2gNCg== --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AF70GVW0432EXBame_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPg0K PHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZp b3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7 fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5k aWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOm5hdnk7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46MS4waW4gMS4yNWluIDEu MGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCiAv KiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzEyNTY1OTk4 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkyMjI0Mjk2MDt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj13 aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1ibHVlPg0KDQo8ZGl2IGNsYXNzPVdvcmRT ZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5G cm9tOiBHZW9yZ2UgRmxldGNoZXIgW21haWx0bzpnZmZsZXRjaEBhb2wuY29tXSA8YnI+DQomZ3Q7 TWF5YmUgSSB3YXNuJ3QgY2xlYXIgaW4gdGhlIHVzZSBjYXNlLiBUaGUgcG9pbnQgb2Ygc2lnbmF0 dXJlcyBpcyBub3QgdG8NCmVuYWJsZSBhdXRob3JpemF0aW9uIGJ1dCB0byA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ Jmd0O2Vuc3VyZSB0aGF0IHJlbGVhc2Ugb2YgZGF0YSBvbmx5IGhhcHBlbnMgd2l0aGluIHRoZSBj b250ZXh0DQp0aGF0IHdhcyBhdXRob3JpemVkIGJ5IHRoZSB1c2VyLiBMZXQncyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+Jmd0O3Rha2UgdGhlIGZsaXAgc2lkZSB3aGVyZSBzaWduYXR1cmVzIGFyZSBub3QgdXNlZC4g PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5JIGFncmVlIHRoYXQgdGFraW5nIHRoZSBm bGlwIHNpZGUgdGhlcmUgaXMgaW1wb3J0YW50LsKgIEluIG9yZGVyIHRvDQpzdXBwb3J0IHRoZSBj bGFpbSAmcXVvdDtYIGlzIGltcG9ydGFudCBmb3Igc2VjdXJpdHkmcXVvdDsgd2l0aCB1c2UgY2Fz ZXMsIHlvdQ0KbmVlZCBvbmUgdXNlIGNhc2Ugd2hlcmUgWCBpcyBhYnNlbnQgYW5kIHNvbWVvbmUg Z2V0cyBzb21lIGluZm9ybWF0aW9uIHRoZXkNCnNob3VsZG4ndCwgYW5kIGFub3RoZXIgdXNlIGNh c2Ugd2hlcmUgWCBpcyBwcmVzZW50IGFuZCBldmVyeXRoaW5nIGVsc2UgaXMNCnNpbWlsYXIgYW5k IHRoZSBpbmZvcm1hdGlvbiBkb2Vzbid0IGxlYWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPiZndDtBbnkgc2l0ZSB3aXRoIGFjY2VzcyB0byB0aGUgYmVhcmVyIHRva2VuIGlzc3VlZCB0 byA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+Jmd0O3NsZWVwd2VsbCBoYXMgYWNjZXNzIHRvIHRoZSBBbGljZSdzIGRh dGEgYXQgdGhlIFBDUC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5QYXJ0IG9mIHRo ZSBzdG9yeSBpcyBtaXNzaW5nIGhlcmUuwqAgSG93IGRpZCB0aGUgc2l0ZSBvdGhlciB0aGFuDQpz bGVlcHdlbGwgZ2V0IHRoZSBiZWFyZXIgdG9rZW4gaXNzdWVkIHRvIHNsZWVwd2VsbD8gwqBUaGUg bmVnYXRpdmUgdXNlIGNhc2Ugc2hvd2luZw0KdGhhdCBiZWFyZXIgdG9rZW5zIGxlYWsgd291bGQg YW5zd2VyIHRoYXQgcXVlc3Rpb24gaW1tZWRpYXRlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz5JZiB0aGUgYmVhcmVyIHRva2VuIGxlYWtzLCB3aHkgY291bGRuJ3QgQWxpY2UncyBk YXRhIGhhdmUgbGVha2VkDQpieSB0aGUgc2FtZSBwYXRoIGluIGEgc2NoZW1lIHdpdGggc2lnbmF0 dXJlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPihxdW90aW5nIG91dCBvZiBvcmRl cik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+Jmd0O0luIHRoZSBjYXNlIG9mIGhlYWx0aCBkYXRhLCBqdXN0IHBvc3Nl c3Npb24gb2YgYW4NCmF1dG9yaXphdGlvbiB0b2tlbiBpcyBOT1QgZ29vZCBlbm91Z2ggdG8gZ3Jh bnQgYWNjZXNzLiAuLi48YnI+DQomZ3Q7VGhpcyBpcyBub3QgYWNjZXB0YWJsZSB3aXRoIHNlbnNp dGl2ZSBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SSBkb24ndCB1bmRlcnN0 YW5kIHdoZXJlIHlvdSdyZSBjb21pbmcgZnJvbS7CoCBBcmUgdGhlc2UgbWVhbnQgdG8NCmJlIHRl Y2huaWNhbCBzdGF0ZW1lbnRzICh3aGljaCB3b3VsZCBuZWVkIHNvbWUgc29ydCBvZiBleHBsYW5h dGlvbiBvciBleGFtcGxlKSwNCnN0YXRlbWVudHMgYWJvdXQgbGF3cyBsaWtlIEhJUFBBICh3aGlj aCB3b3VsZCBuZWVkIGNpdGF0aW9uIG9mIHRoZSByZWxldmFudA0KbGF3KSwgb3IgaW50dWl0aXZl IHByZWRpY3Rpb25zIGFib3V0IHNvbWUgZnV0dXJlIGNvbnNlbnN1cz/CoCDCoFlvdSBtaWdodCBi ZQ0KcmlnaHQgYWJvdXQgdGhlIGZ1dHVyZSBjb25zZW5zdXMuwqAgSSB3YXMgaG9waW5nIHRvIHNl ZSBhIHRlY2huaWNhbA0KanVzdGlmaWNhdGlvbiBmb3IgaXQsIGJ1dCB0aGF0IG1pZ2h0IG5vdCBo YXBwZW4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+U2lnbmF0dXJlcyBkbyBkZWNy ZWFzZSB0aGUgYW1vdW50IHRoYXQgc2xlZXB3ZWxsIGhhcyB0byB0cnVzdA0KcGNwLsKgIFdpdGhv dXQgc2lnbmF0dXJlcywgYSBkaXNob25lc3QgcGNwIGNvdWxkIGdpdmUgYSBiZWFyZXIgdG9rZW4g dG8NCnNsZWVwd2VsbCwgcHVibGlzaCB0aGUgYmVhcmVyIHRva2VuIGFub255bW91c2x5IHRvIHRo aXJkIHBhcnRpZXMgd2hvIG1ha2UNCnVuYXV0aG9yaXplZCB1c2Ugb2YgQWxpY2UncyBtZWRpY2Fs IHJlY29yZHMsIGFuZCB0aGVuIGF0IHRoZSBlbmQgd2UgZG9uJ3Qga25vdw0Kd2hldGhlciB0byBi bGFtZSB0aGUgYmVhcmVyIHRva2VuIGxlYWsgb24gc2xlZXB3ZWxsIG9yIHBjcC7CoCAoVGhhdCdz IHRoZQ0KbmVnYXRpdmUgdXNlIGNhc2UuKcKgIFdpdGggc2lnbmF0dXJlcywgcGNwIGlzIHN1cHBv c2VkIHRvIGNoZWNrIHRoYXQgdGhlDQppbmNvbWluZyB0b2tlbiBpcyBzaWduZWQgYnkgc2xlZXB3 ZWxsLCBhbmQgaWYgaXQgcmVjZWl2ZXMgdGhlIHByb3Blcmx5IHNpZ25lZA0KdG9rZW4gd2hlbiBz b21lb25lIGlzIGFjY2Vzc2luZyBBbGljZSdzIG1lZGljYWwgcmVjb3JkcywgYW5kIHRob3NlIHJl Y29yZHMNCmxlYWssIHRoZW4gZWl0aGVyIHNsZWVwd2VsbCBsZWFrZWQgdGhlbSBkaXJlY3RseSBv ciBzbGVlcHdlbGwgYWxsb3dlZCBhIHNpZ25lZA0KdG9rZW4gdG8gbGVhayBvciBzbGVlcHdlbGwg YWxsb3dlZCBpdHMgcHJpdmF0ZSBrZXkgdG8gbGVhaywgc28gd2Uga25vdyB3aG8gdG8gwqBibGFt ZS7CoA0KKFRoYXQncyB0aGUgcG9zaXRpdmUgdXNlIGNhc2UuKcKgIElmIHRoZSBwdXJwb3NlIG9m IHNpZ25hdHVyZXMgaXMgdG8gYWxsb3cgYXVkaXRpbmcNCmFuZCBjb3JyZWN0bHkgYXNzaWduaW5n IGJsYW1lIGFmdGVyd2FyZCwgcmF0aGVyIHRoYW4gZGVjcmVhc2luZyB0aGUgcmlzayBvZg0KQWxp Y2UncyByZWNvcmRzIGxlYWtpbmcsIGl0IG1ha2VzIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+SWYgdGhpcyBpcyB0aGUgcmlnaHQgc3RvcnksIHdlIGRvbid0IG5l ZWQgZGlzY292ZXJ5IGluIHN0ZXAgMSwNCmFuZCB3ZSBkb24ndCBuZWVkIHRvIHByb3ZlIHdobyBp c3N1ZWQgdGhlIHRva2VuIGF0IHN0ZXAgMywgYW5kIHdlIGRvIG5lZWQgdG8NCmFkZCB0aGUgdXNl IGNhc2Ugd2hlcmUgcGNwIGRpZG4ndCBkbyBpdHMgam9iLsKgIFdlIGFsc28gaGF2ZSB0aGUgaXJy aXRhdGluZw0KcHJvYmxlbSBvZiBkaXN0cmlidXRpbmcgYSBidW5jaCBvZiBwdWJsaWMga2V5cyBh dCB0aGUgYmVnaW5uaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtjb2xvcjojMUY0OTdEJz5UaW0gRnJlZW1hbjxicj4NCkVtYWlsOiA8YSBocmVmPSJtYWls dG86dGltLmZyZWVtYW5AaHAuY29tIj50aW0uZnJlZW1hbkBocC5jb208L2E+PGJyPg0KRGVzayBp biBQYWxvIEFsdG86ICg2NTApIDg1Ny0yNTgxPGJyPg0KSG9tZTogKDQwOCkgNzc0LTEyOTg8YnI+ DQpDZWxsOiAoNDA4KSAzNDgtNzUzNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQpjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFo b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IEdlb3JnZSBGbGV0Y2hlcg0KW21h aWx0bzpnZmZsZXRjaEBhb2wuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVy IDA0LCAyMDEwIDExOjI4IEFNPGJyPg0KPGI+VG86PC9iPiBGcmVlbWFuLCBUaW08YnI+DQo8Yj5D Yzo8L2I+IFplbHRzYW4sIFphY2hhcnkgKFphY2hhcnkpOyBPQXV0aCBXRzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogU2lnbmF0dXJlcyBkb24ndCBzb2x2ZSB0aGF0IHByb2JsZW0gKHdhcyBSRTog W09BVVRILVdHXQ0KU2lnbmF0dXJlcy4uLndoYXQgYXJlIHdlIHRyeWluZyB0byBzb2x2ZT8pPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPkhpIFRpbSw8YnI+DQo8 YnI+DQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gU29tZSBjb21tZW50cy9xdWVzdGlvbnMgaW5s aW5lLi4uPGJyPg0KPC9zcGFuPjxicj4NCk9uIDEwLzQvMTAgMTo1OSBQTSwgRnJlZW1hbiwgVGlt IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlB1 dHRpbmcNCnRoZSB1c2UgY2FzZXMgb24gdGhlIHRhYmxlIGlzIGdvb2QgYmVjYXVzZSBpdCBtYWtl cyB0aGluZ3MgbXVjaCBjbGVhcmVyLiZuYnNwOw0KVW5mb3J0dW5hdGVseSwgaXQncyBjbGVhciB0 aGF0IHRoaXMgdXNlIGNhc2UgZG9lcyBub3Qgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5JJ2QNCmxpa2UgdG8gbnVtYmVyIHRoZSBz dGVwcyB1bmRlciAmcXVvdDtSZXF1aXJlbWVudHMmcXVvdDsgc28gSSBjYW4gcmVmZXIgdG8gdGhl bQ0KdW5hbWJpZ3VvdXNseTo8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4xLg0KVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93 d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPg0K YWNjZXNzZXMgPGEgaHJlZj0iaHR0cDovL3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbSI+d3d3Lm15 aGVhbHRoLmV4YW1wbGUuY29tPC9hPg0KdG8gZGlzY292ZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBQ Q1Agc3lzdGVtIChYUkQgZGlzY292ZXJ5KTxicj4NCjIuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBo cmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5leGFt cGxlLmNvbTwvYT4NCnJlcXVlc3RzIEFsaWNlIHRvIGF1dGhvcml6ZSBhY2Nlc3MgdG8gdGhlIGFw cGxpY2F0aW9uIGF0IDxhDQpocmVmPSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBj cC5leGFtcGxlLmNvbTwvYT4gZm9yIHRoZSBwdXJwb3NlIG9mDQpyZXRyaWV2aW5nIGJhc2ljIGhl YWx0aCBkYXRhIChlLmcuIGRhdGUtb2YtYmlydGgsIHdlaWdodCwgaGVpZ2h0LCBldGMpLiBUaGUN Cm1lY2hhbmlzbSBBbGljZSB1c2VzIHRvIGF1dGhvcml6ZSB0aGlzIGFjY2VzcyBpcyBvdXQgb2Yg c2NvcGUgZm9yIHRoaXMgdXNlDQpjYXNlLjxicj4NCjMuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBo cmVmPSJodHRwOi8vd3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tIj53d3cubXloZWFsdGguZXhhbXBs ZS5jb208L2E+DQppc3N1ZXMgYSB0b2tlbiBib3VuZCB0byA8YSBocmVmPSJodHRwOi8vd3d3LnNs ZWVwd2VsbC5leGFtcGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTwvYT4NCmZvciBh Y2Nlc3MgdG8gdGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cucGNwLmV4YW1w bGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPi4NCk5vdGUgdGhhdCBhIHNpZ25lZCB0b2tl biAoSldUKSBjYW4gYmUgdXNlZCB0byBwcm92ZSB3aG8gaXNzdWVkIHRoZSB0b2tlbi48YnI+DQo0 LiBUaGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBs ZS5jb20iPnd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208L2E+DQpjb25zdHJ1Y3RzIGEgcmVxdWVz dCAoaW5jbHVkZXMgdGhlIHRva2VuIGlzc3VlZCBieSA8YQ0KaHJlZj0iaHR0cDovL3d3dy5teWhl YWx0aC5leGFtcGxlLmNvbSI+d3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tPC9hPikgdG8gdGhlDQph cHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBj cC5leGFtcGxlLmNvbTwvYT48YnI+DQo1LiBUaGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0 cDovL3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20iPnd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208 L2E+DQpzaWducyB0aGUgcmVxdWVzdCBiZWZvcmUgc2VuZGluZyBpdCB0byA8YSBocmVmPSJodHRw Oi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBjcC5leGFtcGxlLmNvbTwvYT48YnI+DQo2LiBU aGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20iPnd3 dy5wY3AuZXhhbXBsZS5jb208L2E+DQpyZWNlaXZlcyB0aGUgcmVxdWVzdCBhbmQgdmVyaWZpZXMg dGhlIHNpZ25hdHVyZTxicj4NCjcuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8v d3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBjcC5leGFtcGxlLmNvbTwvYT4NCnBhcnNlcyB0aGUg bWVzc2FnZSBhbmQgZmluZHMgdGhlIGF1dGhvcml6YXRpb24gdG9rZW48YnI+DQo4LiBUaGUgYXBw bGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20iPnd3dy5wY3Au ZXhhbXBsZS5jb208L2E+DQp2ZXJpZmllcyB0aGUgc2lnbmF0dXJlIG9mIHRoZSBhdXRob3JpemF0 aW9uIHRva2VuPGJyPg0KOS4gVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cu cGNwLmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPg0KcGFyc2VzIHRoZSBhdXRo b3JpemF0aW9uIHRva2VuIGFuZCB2ZXJpZmllcyB0aGF0IHRoaXMgdG9rZW4gd2FzIGlzc3VlZCB0 byB0aGUNCmFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmNvbSI+ d3d3LnNsZWVwd2VsbC5jb208L2E+PGJyPg0KMTAuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVm PSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBjcC5leGFtcGxlLmNvbTwvYT4NCnJl dHJpZXZlcyB0aGUgcmVxdWVzdGVkIGRhdGEgYW5kIHJldHVybnMgaXQgdG8gdGhlIGFwcGxpY2F0 aW9uIGF0IDxhDQpocmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+d3d3LnNs ZWVwd2VsbC5leGFtcGxlLmNvbTwvYT48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUNCnN0YXRlZCBwdXJwb3Nl IG9mIHNpZ25hdHVyZXMgaXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+Jmd0O1RoZQ0KYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDov L3d3dy5wY3AuZXhhbXBsZS5jb20iPnd3dy5wY3AuZXhhbXBsZS5jb208L2E+DQp2ZXJpZmllcyB0 aGF0IEFsaWNlIGhhcyBhdXRob3JpemVkIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPiZndDs8YQ0KaHJlZj0iaHR0cDovL3d3dy5zbGVlcHdlbGwu ZXhhbXBsZS5jb20iPnd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208L2E+IHRvIGFjY2Vzcw0KaGVy IGhlYWx0aCBkYXRhIGFzIHdlbGwgYXMgZW5mb3JjZXMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0O3RoYXQNCjxhIGhyZWY9Imh0dHA6Ly93 d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPiBp cyB0aGUNCm9ubHkgYXBwbGljYXRpb24gdGhhdCBjYW4gcmV0cmlldmUgdGhhdCA8L3NwYW4+PG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mZ3Q7ZGF0YQ0Kd2l0 aCB0aGF0IHNwZWNpZmljIGF1dGhvcml6YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SSdsbA0KYWJicmV2aWF0ZSBkb21haW4gbmFt ZXMgbGlrZSAmcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+ d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTwvYT4mcXVvdDsNCnRvICZxdW90O3NsZWVwd2VsbCZx dW90Oy48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiJz5CZWFyZXINCnRva2VucyB3b3JrIGZpbmUgd2hlbiB2ZXJpZnlp bmcgdGhhdCBBbGljZSBoYXMgYXV0aG9yaXplZCAmbmJzcDs8YQ0KaHJlZj0iaHR0cDovL3d3dy5z bGVlcHdlbGwuZXhhbXBsZS5jb20iPnNsZWVwd2VsbDwvYT4gdG8gYWNjZXNzIGhlciBoZWFsdGgN CmRhdGEsIHNvIHRoZSBjbGFpbSBpcyBhcHBhcmVudGx5IHRoYXQgc2lnbmF0dXJlcyBnaXZlIHRo ZSBhZGRlZCBiZW5lZml0IG9mDQplbmZvcmNpbmcgdGhhdCA8YSBocmVmPSJodHRwOi8vd3d3LnNs ZWVwd2VsbC5leGFtcGxlLmNvbSI+c2xlZXB3ZWxsPC9hPiBpcyB0aGUNCm9ubHkgYXBwbGljYXRp b24gdGhhdCBjYW4gcmV0cmlldmUgdGhhdCBkYXRhIHdpdGggdGhhdCBzcGVjaWZpYyBhdXRob3Jp emF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkkgc3Vw cG9zZSB0aGlzIGRlcGVuZHMgb24gaG93IHlvdSBkZWZpbmUgJnF1b3Q7d29yaw0KZmluZSZxdW90 Oy4gV2hpbGUgdGhlIGF1dGhvcml6YXRpb24gdG9rZW4gaXNzdWVkIGJ5IG15aGVhbHRoZGF0YSBh bmQgZ2l2ZW4gdG8NCnNsZWVwd2VsbCB0byBwcmVzZW50IHRvIHBjcCBjYW4gYmUgcGFzc2VkIGFz IGEgYmVhcmVyIHRva2VuIChzbyBpbiB0aGF0IHNlbnNlDQppdCB3b3JrcyBmaW5lKSB0aGVyZSBp cyBubyBzZWN1cml0eSBhcm91bmQgdGhlIHRva2VuLiBJbiB0aGUgY2FzZSBvZiBoZWFsdGgNCmRh dGEsIGp1c3QgcG9zc2Vzc2lvbiBvZiBhbiBhdXRvcml6YXRpb24gdG9rZW4gaXMgTk9UIGdvb2Qg ZW5vdWdoIHRvIGdyYW50DQphY2Nlc3MuIDxicj4NCjxicj4NCkluc3RlYWQgdGhlIFBDUCBzaXRl IG5lZWRzIHRvIGVuc3VyZSB0aGF0IHRoZSBwcmVzZW50aW5nIGVudGl0eSBpcyBzcGVjaWZpY2Fs bHkNCmF1dGhvcml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiBJIGNvbnRlbmQgdGhh dCB0byBlc3RhYmxpc2ggdGhpcw0KJnF1b3Q7Y2hhaW4gb2YgdHJ1c3QmcXVvdDsgc2lnbmF0dXJl cyBhcmUgbmVlZGVkLjxicj4NCjxicj4NCkdpdmVuIHRoYXQgaW4gbW9zdCBjYXNlcyBwY3Agd2ls bCB3YW50IHRvIGRlY29kZSB0aGUgdG9rZW4gaXRzZWxmLCBpdCB3aWxsIG5lZWQNCnNvbWUgZm9y bSBvZiBzaWduZWQgc3RydWN0dXJlZCB0b2tlbiBiZWNhdXNlIHBjcCBpcyB0aGUgcmVjaXBpZW50 IG9mIHRoZSB0b2tlbg0KYW5kIG5vdCB0aGUgaXNzdWVyLjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VW5mb3J0dW5hdGVs eSwNCnNpZ25hdHVyZXMgZG8gbm90IGRvIHRoYXQuJm5ic3A7IFN1cHBvc2Ugc2xlZXB3ZWxsIHdh bnRlZCB0byBnaXZlIEFsaWNlJ3MgZGF0YQ0KdG8gYXBuZWFjaGVjay4mbmJzcDsgU2xlZXB3ZWxs IGNvdWxkIGZvbGxvdyB0aGUgcHJvdG9jb2wgdXAgdG8gc3RlcCA0LiZuYnNwOw0KVGhlbiwgaW5z dGVhZCBvZiBzaWduaW5nIHRoZSByZXF1ZXN0IGFuZCBzZW5kaW5nIHRoZSBzaWduZWQgcmVxdWVz dCB0byBwY3AsDQpzbGVlcHdlbGwgY291bGQgdHJhbnNtaXQgdGhlIHNpZ25lZCByZXF1ZXN0IHRv IGFwbmVhY2hlY2suJm5ic3A7IGFwbmVhY2hlY2sNCmNvdWxkIHRoZW4gY29tcGxldGUgdGhlIHBy b3RvY29sIGFuZCBnZXQgQWxpY2UncyBkYXRhIGZyb20gPGENCmhyZWY9Imh0dHA6Ly93d3cucGNw LmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPi48L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5NYXliZSBJIHdhc24ndCBjbGVhciBpbiB0aGUgdXNl IGNhc2UuIFRoZSBwb2ludCBvZg0Kc2lnbmF0dXJlcyBpcyBub3QgdG8gZW5hYmxlIGF1dGhvcml6 YXRpb24gYnV0IHRvIGVuc3VyZSB0aGF0IHJlbGVhc2Ugb2YgZGF0YQ0Kb25seSBoYXBwZW5zIHdp dGhpbiB0aGUgY29udGV4dCB0aGF0IHdhcyBhdXRob3JpemVkIGJ5IHRoZSB1c2VyLiBMZXQncyB0 YWtlIHRoZQ0KZmxpcCBzaWRlIHdoZXJlIHNpZ25hdHVyZXMgYXJlIG5vdCB1c2VkLiBBbnkgc2l0 ZSB3aXRoIGFjY2VzcyB0byB0aGUgYmVhcmVyDQp0b2tlbiBpc3N1ZWQgdG8gc2xlZXB3ZWxsIGhh cyBhY2Nlc3MgdG8gdGhlIEFsaWNlJ3MgZGF0YSBhdCB0aGUgUENQLiBUaGlzIGlzDQpub3QgYWNj ZXB0YWJsZSB3aXRoIHNlbnNpdGl2ZSBkYXRhLjxicj4NCjxicj4NClNvIHRoZSBwb2ludCBvZiBz aWduYXR1cmVzIGluIHRoaXMgdXNlIGNhc2UgaXMgdG8gY3JlYXRlIGEgYmluZGluZyBiZXR3ZWVu IHRoZQ0KaXNzdWVyIG9mIHRoZSB0b2tlbiAobXloZWFsdGhkYXRhKSwgdGhlIHByZXNlbnRlciBv ZiB0aGUgdG9rZW4gKHNsZWVwd2VsbCkgYW5kDQp0aGUgcmVjZWl2ZXIgb2YgdGhlIHRva2VuIChw Y3ApLjxicj4NCjxicj4NCklmIHNsZWVwd2VsbCBzaWducyB0aGUgbWVzc2FnZSBzZW50IHRvIHBj cCwgdGhlbiBwY3AgY2FuIHZlcmlmeSB0aGF0IHNsZWVwd2VsbA0KaXMgdGhlIHNlbmRlciBvZiB0 aGUgbWVzc2FnZS4gTmV4dCwgaWYgdGhlIG1lc3NhZ2UgY29udGFpbnMgYSB0b2tlbiBzaWduZWQg YnkNCm15aGVhbHRoIGRhdGEsIGFuZCB0aGF0IHRva2VuIGluY2x1ZGVzIGEgY2xhaW0gdGhhdCB0 aGUgdG9rZW4gaXMgaXNzdWVkIHRvDQpzbGVlcHdlbGwuIFBDUCBjYW4gJnF1b3Q7Y29ubmVjdCB0 aGUgZG90cyZxdW90OyBhbmQga25vdyB0aGF0IHRoaXMgaXMgYSB2YWxpZA0KcmVxdWVzdC48YnI+ DQo8YnI+DQpJZiB0aGUgdG9rZW4gaXMgc2VudCBieSBhbm90aGVyIHNlcnZlciwgdGhlICZxdW90 O2lzc3VlZCB0byZxdW90OyBjbGFpbSB3aWxsDQpub3QgbWF0Y2ggdGhlIGVudGl0eSB0aGF0IHNp Z25lZCB0aGUgbWVzc2FnZSBhbmQgdGhlIFBDUCBhcHBsaWNhdGlvbiB3aWxsDQpyZWplY3QgdGhl IHJlcXVlc3QuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz5JZg0Kc2xlZXB3ZWxsIGhhcyBjYW4gcmV0cml2ZSB0byBBbGljZSdzIGRh dGEsIGFuZCB0aGUgcHJvdG9jb2wgZG9lc24ndCBtYW5kYXRlIGFuDQppbnZhc2l2ZSBjb250cm9s IG9mIHNsZWVwd2VsbCdzIGNvbXB1dGF0aW9uIGFuZCBvdXRwdXRzLCBpdCdzIGhvcGVsZXNzIHRv DQpwcmV2ZW50IHNsZWVwd2VsbCBmcm9tIGFsbG93aW5nIGFwbmVhY2hlY2sgdG8gcmV0cmlldmUg QWxpY2UncyBkYXRhLiZuYnNwOyBJZg0KYWxsIGVsc2UgZmFpbHMsIHNsZWVwd2VsbCBjb3VsZCBh Y2Nlc3MgQWxpY2UncyBkYXRhIGl0c2VsZiBhbmQgdGhlbiBhbGxvdw0KYXBuZWFjaGVjayB0byBh Y2Nlc3MgdGhlIGRhdGEgZnJvbSBzbGVlcHdlbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+U28gSSdsbCBjb25jZWRlIHRoYXQgb25jZSBzbGVlcHdlbGwgaGFz IHRoZSBkYXRhLCBpZg0Kc2xlZXB3ZWxsIGlzIG5vdCB0cnVzdHdvcnRoeSwgdGhlcmUgaXMgbGl0 dGxlIEFsaWNlIGNhbiBkbyB0byBwcm90ZWN0IGhlciBkYXRhLg0KTWF5YmUgbGF3cyBhbmQgb3Ro ZXIgc3VjaCBtZWNoYW5pc21zIHdpbGwgYmUgZGV2ZWxvcGVkIHRvIGRlYWwgd2l0aCB0aGlzDQpz Y2VuYXJpby4gVGhpcyBpcyBvbmUgcmVhc29uIHdoeSBpdCdzIHNvIGltcG9ydGFudCBmb3IgdGhl IFBDUCB0byBvbmx5IHJlbGVhc2UNCmRhdGEgdG8gdGhlIHNwZWNpZmljIGVudGl0eSB0aGF0IHdh cyBhdXRob3JpemVkLiBUaGlzIGlzIG5vdCBwb3NzaWJsZSB3aXRoDQpiZWFyZXIgdG9rZW5zIGlu IGEgZGVsZWdhdGVkIHVzZSBjYXNlIGxpa2UgdGhpcyBvbmUuPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Gb3INCmFsbCBJIGtub3cs IHNpZ25hdHVyZXMgbWlnaHQgYmUgYSBzb2x1dGlvbiB0byBzb21lIHByb2JsZW0sIGJ1dCB0aGV5 IGFyZW4ndCBhIHNvbHV0aW9uDQp0byB0aGlzIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCc+VGltIEZyZWVtYW48YnI+DQpFbWFpbDogPGEgaHJlZj0i bWFpbHRvOnRpbS5mcmVlbWFuQGhwLmNvbSI+dGltLmZyZWVtYW5AaHAuY29tPC9hPjxicj4NCkRl c2sgaW4gUGFsbyBBbHRvOiAoNjUwKSA4NTctMjU4MTxicj4NCkhvbWU6ICg0MDgpIDc3NC0xMjk4 PGJyPg0KQ2VsbDogKDQwOCkgMzQ4LTc1MzY8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjsNCmJvcmRlci1jb2xv cjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3InPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiOw0KY29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMt c2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4NCls8YSBocmVmPSJtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8 Yj5Pbg0KQmVoYWxmIE9mIDwvYj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBPY3RvYmVyIDA0LCAyMDEwIDk6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+IFplbHRzYW4sIFph Y2hhcnkgKFphY2hhcnkpPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW09BVVRILVdHXSBTaWduYXR1cmVzLi4ud2hhdCBhcmUgd2UgdHJ5aW5nIHRvIHNv bHZlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5IaQ0KWmFj aGFyeSw8YnI+DQo8YnI+DQpIZXJlIGlzIGEgdXNlIGNhc2UgZm9yIHNpZ25lZCBtZXNzYWdlcy4g SSd2ZSB0cmllZCB0byBrZWVwIHRoaXMgaW4gdGhlIGZvcm1hdA0Kb2YgdGhlIG90aGVyIE9BdXRo IHVzZSBjYXNlcy4gUGxlYXNlIGNvbnRhY3QgbWUgb2ZmLWxpc3QgaWYgdGhlcmUgYXJlIGVkaXRv cmlhbA0KY2hhbmdlcyByZXF1aXJlZC4gSSd2ZSBpbmNsdWRlIHRoZSBsaXN0IHRvIHNlZSBpZiBv dGhlcnMgaGF2ZSBmZWVkIGJhY2sgb24gdGhpcw0KdXNlIGNhc2UuPGJyPg0KPGJyPg0KVGhhbmtz LDxicj4NCkdlb3JnZTxicj4NCjxicj4NClVzZSBjYXNlOiBTaWduZWQgTWVzc2FnZXM8YnI+DQo8 YnI+DQpEZXNjcmlwdGlvbjo8YnI+DQo8YnI+DQpBbGljZSBtYW5hZ2VzIGFsbCBoZXIgcGVyc29u YWwgaGVhbHRoIHJlY29yZHMgaW4gaGVyIHBlcnNvbmFsIGhlYWx0aCBkYXRhIHN0b3JlDQooPGEg aHJlZj0iaHR0cDovL3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbSI+d3d3Lm15aGVhbHRoLmV4YW1w bGUuY29tPC9hPikuDQpBbGljZSdzIFByaW1hcnkgQ2FyZSBQaHlzaWNpYW4gKDxhIGhyZWY9Imh0 dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPikNCnJlY29t bWVuZHMgdGhhdCBBbGljZSBzZWUgYSBzbGVlcCBzcGVjaWFsaXN0ICg8YQ0KaHJlZj0iaHR0cDov L3d3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb20iPnd3dy5zbGVlcHdlbGwuZXhhbXBsZS5jb208L2E+ KS4gQWxpY2UgYXJyaXZlcw0KYXQgdGhlIHNsZWVwIHNwZWNpYWxpc3QncyBvZmZpY2UgYW5kIGF1 dGhvcml6ZXMgaXQgdG8gYWNjZXNzIGhlciBiYXNpYyBoZWFsdGgNCmRhdGEgZnJvbSBoZXIgUENQ LiBUaGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5wY3AuZXhhbXBsZS5jb20i Pnd3dy5wY3AuZXhhbXBsZS5jb208L2E+DQp2ZXJpZmllcyB0aGF0IEFsaWNlIGhhcyBhdXRob3Jp emVkIDxhIGhyZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3 ZWxsLmV4YW1wbGUuY29tPC9hPg0KdG8gYWNjZXNzIGhlciBoZWFsdGggZGF0YSBhcyB3ZWxsIGFz IGVuZm9yY2VzIHRoYXQgPGENCmhyZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29t Ij53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPiBpcyB0aGUNCm9ubHkgYXBwbGljYXRpb24g dGhhdCBjYW4gcmV0cmlldmUgdGhhdCBkYXRhIHdpdGggdGhhdCBzcGVjaWZpYyBhdXRob3JpemF0 aW9uLjxicj4NCjxicj4NClByZS1jb25kaXRpb25zOjxicj4NCjxicj4NCiogQWxpY2UgaGFzIGEg cGVyc29uYWwgaGVhbHRoIGRhdGEgc3RvcmUgdGhhdCBhbGxvd3MgZm9yIGRpc2NvdmVyeSBvZiBo ZXINCnBhcnRpY2lwYXRpbmcgaGVhbHRoIHN5c3RlbXMgKGUuZy4gcHN5Y2hpYXRyaXN0LCBzbGVl cCBzcGVjaWFsaXN0LCBwY3AsDQpvcnRob2RvbnRpc3QsIG9waHRoYWxtb2xvZ2lzdCwgZXRjKS48 YnI+DQoqIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8vd3d3Lm15aGVhbHRoLmV4 YW1wbGUuY29tIj53d3cubXloZWFsdGguZXhhbXBsZS5jb208L2E+DQptYW5hZ2VzIGF1dGhvcml6 YXRpb24gb2YgYWNjZXNzIHRvIEFsaWNlJ3MgcGFydGljaXBhdGluZyBoZWFsdGggc3lzdGVtczxi cj4NCiogVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cubXloZWFsdGguZXhh bXBsZS5jb20iPnd3dy5teWhlYWx0aC5leGFtcGxlLmNvbTwvYT4NCmNhbiBpc3N1ZXMgYXV0aG9y aXphdGlvbiB0b2tlbnMgdW5kZXJzdG9vZCBieSBBbGljZSdzIHBhcnRpY2lwYXRpbmcgaGVhbHRo DQpzeXN0ZW1zPGJyPg0KKiBUaGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5w Y3AuZXhhbXBsZS5jb20iPnd3dy5wY3AuZXhhbXBsZS5jb208L2E+DQpzdG9yZXMgQWxpY2UncyBi YXNpYyBoZWFsdGggYW5kIHByZXNjcmlwdGlvbiByZWNvcmRzPGJyPg0KKiBUaGUgYXBwbGljYXRp b24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5zbGVlcHdlbGwuY29tIj53d3cuc2xlZXB3ZWxsLmNv bTwvYT4NCnN0b3JlcyByZXN1bHRzIG9mIEFsaWNlJ3Mgc2xlZXAgdGVzdHM8YnI+DQo8YnI+DQo8 YnI+DQpQb3N0LWNvbmRpdGlvbnM6PGJyPg0KKiBBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlIHJlc3Vs dHMgaW4ganVzdCB0aGUgaW5mb3JtYXRpb24gdGhhdCBBbGljZSBhdXRob3JpemVkDQpiZWluZyB0 cmFuc2ZlcnJlZCBmcm9tIHRoZSBQcmltYXJ5IENhcmUgUGh5c2ljaWFuICg8YQ0KaHJlZj0iaHR0 cDovL3d3dy5wY3AuZXhhbXBsZS5jb20iPnd3dy5wY3AuZXhhbXBsZS5jb208L2E+KSB0byB0aGUg c2xlZXAgc3BlY2lhbGlzdA0KKDxhIGhyZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUu Y29tIj53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPikuPGJyPg0KKiBUaGUgdHJhbnNmZXIg b2YgaGVhbHRoIGRhdGEgb25seSBvY2N1cnMgaWYgdGhlIGFwcGxpY2F0aW9uIGF0IDxhDQpocmVm PSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBjcC5leGFtcGxlLmNvbTwvYT4gY2Fu IHZlcmlmeSB0aGF0IDxhDQpocmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+ d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTwvYT4gaXMgdGhlDQpwYXJ0eSByZXF1ZXN0aW5nIGFj Y2VzcyBhbmQgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiB0b2tlbiBwcmVzZW50ZWQgYnkgPGENCmhy ZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3ZWxsLmV4YW1w bGUuY29tPC9hPiBpcyBpc3N1ZWQNCmJ5IHRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRw Oi8vd3d3Lm15aGVhbHRoLmV4YW1wbGUuY29tIj53d3cubXloZWFsdGguZXhhbXBsZS5jb208L2E+ DQp3aXRoIGEgcmVzdHJpY3RlZCBhdWRpZW5jZSBvZiA8YSBocmVmPSJodHRwOi8vd3d3LnNsZWVw d2VsbC5leGFtcGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTwvYT48YnI+DQo8YnI+ DQpSZXF1aXJlbWVudHM6PGJyPg0KMS4gVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6 Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9h Pg0KYWNjZXNzZXMgPGEgaHJlZj0iaHR0cDovL3d3dy5teWhlYWx0aC5leGFtcGxlLmNvbSI+d3d3 Lm15aGVhbHRoLmV4YW1wbGUuY29tPC9hPg0KdG8gZGlzY292ZXIgdGhlIGxvY2F0aW9uIG9mIHRo ZSBQQ1Agc3lzdGVtIChYUkQgZGlzY292ZXJ5KTxicj4NCjIuIFRoZSBhcHBsaWNhdGlvbiBhdCA8 YSBocmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5l eGFtcGxlLmNvbTwvYT4NCnJlcXVlc3RzIEFsaWNlIHRvIGF1dGhvcml6ZSBhY2Nlc3MgdG8gdGhl IGFwcGxpY2F0aW9uIGF0IDxhDQpocmVmPSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3 LnBjcC5leGFtcGxlLmNvbTwvYT4gZm9yIHRoZSBwdXJwb3NlIG9mDQpyZXRyaWV2aW5nIGJhc2lj IGhlYWx0aCBkYXRhIChlLmcuIGRhdGUtb2YtYmlydGgsIHdlaWdodCwgaGVpZ2h0LCBldGMpLiBU aGUgbWVjaGFuaXNtDQpBbGljZSB1c2VzIHRvIGF1dGhvcml6ZSB0aGlzIGFjY2VzcyBpcyBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgdXNlIGNhc2UuPGJyPg0KMy4gVGhlIGFwcGxpY2F0aW9uIGF0IDxh IGhyZWY9Imh0dHA6Ly93d3cubXloZWFsdGguZXhhbXBsZS5jb20iPnd3dy5teWhlYWx0aC5leGFt cGxlLmNvbTwvYT4NCmlzc3VlcyBhIHRva2VuIGJvdW5kIHRvIDxhIGhyZWY9Imh0dHA6Ly93d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPg0KZm9y IGFjY2VzcyB0byB0aGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5wY3AuZXhh bXBsZS5jb20iPnd3dy5wY3AuZXhhbXBsZS5jb208L2E+Lg0KTm90ZSB0aGF0IGEgc2lnbmVkIHRv a2VuIChKV1QpIGNhbiBiZSB1c2VkIHRvIHByb3ZlIHdobyBpc3N1ZWQgdGhlIHRva2VuLjxicj4N CjQuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8vd3d3LnNsZWVwd2VsbC5leGFt cGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbTwvYT4NCmNvbnN0cnVjdHMgYSByZXF1 ZXN0IChpbmNsdWRlcyB0aGUgdG9rZW4gaXNzdWVkIGJ5IDxhDQpocmVmPSJodHRwOi8vd3d3Lm15 aGVhbHRoLmV4YW1wbGUuY29tIj53d3cubXloZWFsdGguZXhhbXBsZS5jb208L2E+KSB0byB0aGUN CmFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tIj53d3cu cGNwLmV4YW1wbGUuY29tPC9hPjxicj4NCjUuIFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJo dHRwOi8vd3d3LnNsZWVwd2VsbC5leGFtcGxlLmNvbSI+d3d3LnNsZWVwd2VsbC5leGFtcGxlLmNv bTwvYT4NCnNpZ25zIHRoZSByZXF1ZXN0IGJlZm9yZSBzZW5kaW5nIGl0IHRvIDxhIGhyZWY9Imh0 dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPjxicj4NCjYu IFRoZSBhcHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+ d3d3LnBjcC5leGFtcGxlLmNvbTwvYT4NCnJlY2VpdmVzIHRoZSByZXF1ZXN0IGFuZCB2ZXJpZmll cyB0aGUgc2lnbmF0dXJlPGJyPg0KNy4gVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhyZWY9Imh0dHA6 Ly93d3cucGNwLmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPg0KcGFyc2VzIHRo ZSBtZXNzYWdlIGFuZCBmaW5kcyB0aGUgYXV0aG9yaXphdGlvbiB0b2tlbjxicj4NCjguIFRoZSBh cHBsaWNhdGlvbiBhdCA8YSBocmVmPSJodHRwOi8vd3d3LnBjcC5leGFtcGxlLmNvbSI+d3d3LnBj cC5leGFtcGxlLmNvbTwvYT4NCnZlcmlmaWVzIHRoZSBzaWduYXR1cmUgb2YgdGhlIGF1dGhvcml6 YXRpb24gdG9rZW48YnI+DQo5LiBUaGUgYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3 dy5wY3AuZXhhbXBsZS5jb20iPnd3dy5wY3AuZXhhbXBsZS5jb208L2E+DQpwYXJzZXMgdGhlIGF1 dGhvcml6YXRpb24gdG9rZW4gYW5kIHZlcmlmaWVzIHRoYXQgdGhpcyB0b2tlbiB3YXMgaXNzdWVk IHRvIHRoZQ0KYXBwbGljYXRpb24gYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5zbGVlcHdlbGwuY29t Ij53d3cuc2xlZXB3ZWxsLmNvbTwvYT48YnI+DQoxMC4gVGhlIGFwcGxpY2F0aW9uIGF0IDxhIGhy ZWY9Imh0dHA6Ly93d3cucGNwLmV4YW1wbGUuY29tIj53d3cucGNwLmV4YW1wbGUuY29tPC9hPg0K cmV0cmlldmVzIHRoZSByZXF1ZXN0ZWQgZGF0YSBhbmQgcmV0dXJucyBpdCB0byB0aGUgYXBwbGlj YXRpb24gYXQgPGENCmhyZWY9Imh0dHA6Ly93d3cuc2xlZXB3ZWxsLmV4YW1wbGUuY29tIj53d3cu c2xlZXB3ZWxsLmV4YW1wbGUuY29tPC9hPjxicj4NCjxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQpP biA5LzI4LzEwIDEyOjI3IFBNLCBaZWx0c2FuLCBaYWNoYXJ5IChaYWNoYXJ5KSB3cm90ZTogPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOm5hdnknPlRo ZXNlIHVzZSBjYXNlcyBhcmUgbm90IGluIHRoZSBkcmFmdCA8YQ0KaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemVsdHNhbi11c2UtY2FzZXMtb2F1dGgiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXplbHRzYW4tdXNlLWNhc2VzLW9hdXRo PC9hPi48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOm5hdnknPkNvdWxkIHlvdSB3cml0ZSB0aGVtIHVwPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpuYXZ5 Jz5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjpuYXZ5Jz5aYWNoYXJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuDQpzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+DQoNCjxo ciBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KY29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9t YSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiA8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4NCls8YSBocmVmPSJt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSA8Yj5Pbg0KQmVoYWxmIE9mIDwvYj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVyIDI4LCAyMDEwIDExOjM5IEFNPGJyPg0KPGI+VG86PC9i PiBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaWduYXR1cmVz Li4ud2hhdCBhcmUgd2UgdHJ5aW5nIHRvIHNvbHZlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fu cy1zZXJpZiInPkkgdGhpbmsNCm9mIHRoZSBzaWduYXR1cmUgaXNzdWVzIGFzIGZhbGxpbmcgaW50 byB0d28gY2xhc3Nlcy4uLiBJIHRoaW5rIHRoZXkgbWFwIHRvIHlvdXINCmNsYXNzaWZpY2F0aW9u IGFzIHdlbGwuLi48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjx1bCBzdHlsZT0nbWFyZ2luLXRv cDowaW4nIHR5cGU9ZGlzYz4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDps MCBsZXZlbDEgbGZvMSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5Og0KICAgICAiSGVsdmV0 aWNhIiwic2Fucy1zZXJpZiInPlNpZ25pbmcgdG9rZW5zPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6DQogICAgICJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+IGlzIGltcG9ydGFu dCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBlc3BlY2lhbGx5DQogICAgIGxvb2tpbmcgZm9yd2FyZCB0 byBhIHRpbWUgd2hlbiB0b2tlbnMgaXNzdWVkIGJ5IG11bHRpcGxlIEF1dGhvcml6YXRpb24NCiAg ICAgU2VydmVycyBhcmUgYWNjZXB0ZWQgYXQgYSBnaXZlbiBob3N0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvbGk+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEnPjxiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToNCiAgICAgIkhlbHZldGljYSIsInNhbnMt c2VyaWYiJz5TaWduaW5nIG1lc3NhZ2VzPC9zcGFuPjwvYj48c3Bhbg0KICAgICBzdHlsZT0nZm9u dC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz4gaXMgaW1wb3J0YW50IGJlY2F1c2Ug aXQNCiAgICAgcHJvdmlkZXMgYSBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQgdGhlIGVudGl0eSBt YWtpbmcgdGhlIEFQSSBjYWxsIChhbmQNCiAgICAgcHJlc2VudGluZyBhbiBhY2Nlc3MgdG9rZW4p IGlzIHJlYWxseSB0aGUgZW50aXR5IHRoYXQgaXMgYWxsb3dlZCB0byBtYWtlDQogICAgIHRoZSBB UEkgY2FsbC48L3NwYW4+PG86cD48L286cD48L2xpPg0KPC91bD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPlNp Z25pbmcNCm1lc3NhZ2VzIGFwcGxpZXMgdG8gdGhlIHJlLWRlbGVnYXRpb24gdXNlIGNhc2VzLiBJ J3ZlIGhlYXJkIHRoZSBuZWVkIGZvciB0aGlzDQpjbGFzcyBvZiB1c2UgY2FzZXMgZnJvbSBib3Ro IHRoZSBoRGF0YSAoaGVhbHRoIGRhdGEpIGNvbW11bml0eSBhcyB3ZWxsIGFzIHRoZQ0KdXNlciBt YW5hZ2VkIGFjY2VzcyAoVU1BKSBjb21tdW5pdHkuPGJyPg0KPGJyPg0KU2lnbmluZyB0b2tlbnMg Y292ZXJzIGJvdGggeW91ciBzZWNvbmQgY2xhc3Mgb2YgdG9rZW5zIGFzIHdlbGwgYXMgYW5vdGhl ciB1c2UNCmNhc2UgdGhhdCBFcmFuIGhhcyBtZW50aW9uZWQgYXMgd2VsbC4gTmFtZWx5LCBhIHBy b3RlY3RlZCByZXNvdXJjZSBzZXJ2ZXINCmhvbm9yaW5nIHRva2VucyBmcm9tIG11bHRpcGxlIEF1 dGhvcml6YXRpb24gU2VydmVycy48YnI+DQo8YnI+DQpUaGVzZSBhcmUgdGhlIHR3byBjbGFzc2Vz IG9mIHVzZSBjYXNlcyB0aGF0IEknZCBsaWtlIHRvIHNlZSBzb2x2ZWQuPGJyPg0KPGJyPg0KVGhh bmtzLDxicj4NCkdlb3JnZTxicj4NCjxicj4NCjxicj4NCk88L3NwYW4+biA5LzI4LzEwIDEyOjU4 IEFNLCBEYXZpZCBSZWNvcmRvbiB3cm90ZTogPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5JZiB5b3Uga25vdyBtZSB0aGVuIHlvdSdsbCBrbm93IHRoYXQgSSdt IGdlbmVyYWxseSBvbmUgb2YNCnRoZSBsYXN0IHBlb3BsZSB0byB0YWxrIGFib3V0IEFsaWNlIGFu ZCBCb2IuIFRoYXQgc2FpZCwgdGhlcmUgYXJlIGEgbG90IG9mDQp0ZWNobmljYWwgcHJvcG9zYWxz IGZseWluZyBhY3Jvc3MgdGhlIGxpc3Qgd2l0aCB2ZXJ5IGxpdHRsZSBzaGFyZWQNCnVuZGVyc3Rh bmRpbmcgb2YgdGhlIHByb2JsZW0ocykgd2UncmUgdHJ5aW5nIHRvIHNvbHZlLjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkZyb20g d2hhdCBJJ3ZlIHNlZW4gdGhlcmUgYXJlIHR3byBkaXN0aW5jdCBjbGFzc2VzIG9mDQpzaWduYXR1 cmUgdXNlIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjEpIFRoZSBmaXJzdCBpcyB3aGVyZSB0aGUgSFRUUCByZXF1ZXN0IHBhcmFt ZXRlcnMgbXVzdCBiZQ0KcGFydCBvZiB0aGUgc2lnbmF0dXJlLiBBbiBleGFtcGxlIGlzIGFueSBP QXV0aCAxLjBhIHN0eWxlIEFQSSB3aGVyZSB5b3Ugd2FudCB0bw0KbWFrZSBzdXJlIHRoYXQgdGhl IEhUVFAgUE9TVCB5b3VyIHNlcnZlciBqdXN0IHJlY2VpdmVkIGlzbid0IG1hc3F1ZXJhZGluZw0K aXRzZWxmIGFzIGEgR0VULjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjIpIFRoZSBzZWNvbmQgaXMmbmJzcDt3aGVyZSB0aGUgSFRUUCByZXF1 ZXN0IGlzIG9ydGhvZ29uYWwuDQpBbiBleGFtcGxlIGlzJm5ic3A7T3BlblNvY2lhbCB3aGVyZSB0 aGUgc2VydmVyIGlzIHNlbmRpbmcgc3RhdGUgaW5mb3JtYXRpb24gdG8NCnRoZSBjbGllbnQgc3Vj aCBhcyB3aGF0IHVzZXIgaXMgY3VycmVudGx5IGxvZ2dlZCBpbi48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgbWFpbiBwcmFj dGljYWwgZXhhbXBsZSBJIGhhdmUgb2YgdGhlIGZpcnN0IHVzZSBjYXNlIGlzDQp3aGF0IFR3aXR0 ZXIgd2FudHMgdG8gZG8gd2l0aCByZWRlbGVnYXRpb24uIEluIHRoaXMgY2FzZSBUd2VldERlY2sg Y2FuJ3QgZ2l2ZW4NClR3aXRQaWMgaXQncyBvd24gYmVhcmVyIHRva2VuLCBidXQgbmVlZHMgdG8g c2lnbiB0aGUgUE9TVCByZXF1ZXN0IGFuZCBwYXNzIHRoYXQNCnNpZ25hdHVyZSB0byBUd2l0UGlj IGZvciBpdCB0byBpbmNsdWRlIGluIHRoZSBmaW5hbCBBUEkgcmVxdWVzdCB0byBUd2l0dGVyLjxv OnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPkluIHRlcm1zIG9mIHNpZ25pbmcgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzLCBJIGhh dmVuJ3QNCmhlYXJkIGFueW9uZSBicmluZyB1cCBzcGVjaWZpYyBhbmQgZGV0YWlsZWQgbmVlZHMg Zm9yIHRoaXMgcmVjZW50bHkuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+SlNPTiB0b2tlbnMgcHJldHR5IGNsZWFybHkgbWFrZSBz ZW5zZSBmb3IgdGhlIHNlY29uZCBjbGFzcw0Kb2Ygc2lnbmF0dXJlIHVzZSBjYXNlcyBhbmQgaXQn cyBhY3R1YWxseSBhIGJpdCBoYXJkIHRvIGFyZ3VlIHdoeSB0aGV5IHdvdWxkIGJlDQphIHBhcnQg b2YgT0F1dGguIEZhY2Vib29rIHNoaXBwZWQgdGhpcyBhIGJpdCBvdmVyIGEgbW9udGggYWdvIGZv ciBjYW52YXMNCmFwcGxpY2F0aW9ucy4gV2UgaW5jbHVkZSBhIGBzaWduZWRfcmVxdWVzdGAgcGFy YW1ldGVyIHdoaWNoIGlzDQpzaWduYXR1cmUuYmFzZTY0dXJsKEpTT04pLiBQYXJzaW5nIGl0IGlz IDE4IGxpbmVzIG9mIFBIUC4gPGENCmhyZWY9Imh0dHA6Ly9kZXZlbG9wZXJzLmZhY2Vib29rLmNv bS9kb2NzL2F1dGhlbnRpY2F0aW9uL2NhbnZhcyI+aHR0cDovL2RldmVsb3BlcnMuZmFjZWJvb2su Y29tL2RvY3MvYXV0aGVudGljYXRpb24vY2FudmFzPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgc2Vjb25kIGNsYXNz IG9mIHVzZSBjYXNlIHdpbGwgYWxzbyBiZSByZXF1aXJlZCBieQ0KT3BlbklEIENvbm5lY3Qgd2hl cmUgdGhlIHNlcnZlciBpcyBzaWduaW5nIGlkZW50aXR5IGluZm9ybWF0aW9uIGFuZCBzZW5kaW5n IGl0DQp0byB0aGUgY2xpZW50LiBJIGltYWdpbmUgdGhhdCBPcGVuU29jaWFsIHdpbGwgYWxzbyBz dGlsbCBoYXZlIGl0IGFuZCB3aXNoIHRvDQpjb250aW51ZSByZWx5aW5nIG9uIHB1YmxpYyBrZXkg YWxnb3JpdGhtcy48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5TbyBhIGZldyBxdWVzdGlvbnM6PG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7KiBEbyB3ZSB3YW50IHRv IHRhY2tsZSBib3RoIG9mIHRoZXNlIGNsYXNzZXMgb2YNCnNpZ25hdHVyZXMgaW4gT0F1dGg/PG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7KiBXaHkgZG8geW91IGNvbnNpZGVyIHRoZSBzZWNvbmQgY2xhc3MgcGFydCBvZiBPQXV0aA0K dmVyc3VzIHNvbWV0aGluZyBjb21wbGV0ZWx5IHNlcGFyYXRlIHRoYXQgbWlnaHQgaGFwcGVuIHRv IGluY2x1ZGUgYW4gT0F1dGgNCmFjY2VzcyB0b2tlbj88bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsqIElzIHRoZSBUd2l0dGVyIHJl ZGVsZWdhdGlvbiB1c2UgY2FzZSB0aGUgcmlnaHQgZm9jdXMNCmZvciB0aGUgZmlyc3QgY2xhc3M/ PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7KiBJcyB0aGVyZSBhbiBleGFtcGxlIG9mIGFuIE9BdXRoIDIuMCBzZXJ2ZXIgdGhhdA0K Y2FuJ3QgdXNlIGJlYXJlciB0b2tlbnMgZm9yIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBh bmQgdGh1cyByZXF1aXJlcw0Kc2lnbmF0dXJlcz88bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MsPG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+LS1EYXZpZDxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5i c3A7PG86cD48L286cD48L3ByZT48cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT48cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9wcmU+PHByZT48YQ0KaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0 aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGENCmhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KDQo8cHJlPi0tIDxvOnA+PC9v OnA+PC9wcmU+PHByZT5DaGllZiBBcmNoaXRlY3TCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgQUlNOsKgIGdmZmxldGNoPG86cD48L286cD48L3ByZT48cHJlPklkZW50aXR5IFNl cnZpY2VzIEVuZ2luZWVyaW5nwqDCoMKgwqAgV29yazogPGENCmhyZWY9Im1haWx0bzpnZW9yZ2Uu ZmxldGNoZXJAdGVhbWFvbC5jb20iPmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbTwvYT48bzpw PjwvbzpwPjwvcHJlPjxwcmU+QU9MIEluYy7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBIb21lOiA8YQ0KaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5j b20iPmdmZmxldGNoQGFvbC5jb208L2E+PG86cD48L286cD48L3ByZT48cHJlPk1vYmlsZTogKzEt NzAzLTQ2Mi0zNDk0wqDCoMKgwqDCoMKgwqDCoMKgwqAgQmxvZzogPGENCmhyZWY9Imh0dHA6Ly9w cmFjdGljYWxpZC5ibG9nc3BvdC5jb20iPmh0dHA6Ly9wcmFjdGljYWxpZC5ibG9nc3BvdC5jb208 L2E+PG86cD48L286cD48L3ByZT48cHJlPk9mZmljZTogKzEtNzAzLTI2NS0yNTQ0wqDCoMKgwqDC oMKgwqDCoMKgwqAgVHdpdHRlcjogPGENCmhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRj aCI+aHR0cDovL3R3aXR0ZXIuY29tL2dmZmxldGNoPC9hPjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+ DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A653964AF70GVW0432EXBame_-- From balfanz@google.com Wed Oct 6 14:25:53 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2923A71E2 for <oauth@core3.amsl.com>; Wed, 6 Oct 2010 14:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.913 X-Spam-Level: X-Spam-Status: No, score=-105.913 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3xLbOCXyzkn for <oauth@core3.amsl.com>; Wed, 6 Oct 2010 14:25:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7B6FD3A71E0 for <oauth@ietf.org>; Wed, 6 Oct 2010 14:25:50 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o96LQnOH009284 for <oauth@ietf.org>; Wed, 6 Oct 2010 14:26:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286400411; bh=4rjHLO2S/nL3YPNsUphq6NyyTSs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=B8BWYVzGPy2NYhM5gqsg+VfrEAQZMXV2CAX/q9JAoiIVTAS+F5Oo/sFd1GY52yzpQ 9PxpSqasSWCyHtJykroiA== Received: from iwn1 (iwn1.prod.google.com [10.241.68.65]) by kpbe17.cbf.corp.google.com with ESMTP id o96LPk8G014548 for <oauth@ietf.org>; Wed, 6 Oct 2010 14:26:03 -0700 Received: by iwn1 with SMTP id 1so32342iwn.8 for <oauth@ietf.org>; Wed, 06 Oct 2010 14:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=z+OT4nwvAR+ZVcqD6E4Bac+Qaw++ZWP1MdJqaPYvssg=; b=ZK4fFYnUw+SgI0XSRUKeUGCMALCaORpANVcwIcG126Ld6tGjJMpa8CI6BeabmdS/Aj JPkd7oNCub1mL7bA4hlg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rbU8R9rv6m1pGpbOAn9oC/iiQE5tMR7KSjoUNItvrIA1Gx4FwDDBQ97Q56/W6DYbiJ ujYHK8VSjcPSS/ucWpJA== MIME-Version: 1.0 Received: by 10.231.157.135 with SMTP id b7mr14565498ibx.164.1286400362647; Wed, 06 Oct 2010 14:26:02 -0700 (PDT) Received: by 10.231.36.133 with HTTP; Wed, 6 Oct 2010 14:26:02 -0700 (PDT) In-Reply-To: <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> Date: Wed, 6 Oct 2010 14:26:02 -0700 Message-ID: <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: Anthony Nadalin <tonynad@microsoft.com> Content-Type: multipart/alternative; boundary=005045014273a791860491f96c69 X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 21:25:53 -0000 --005045014273a791860491f96c69 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So what's the proposal, then? That OAuth service providers document what crypto mechanisms they support? And developers will just have to know which alg to use with which service provider? I guess I could live with that... Dirk. On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <tonynad@microsoft.com>wro= te: > I don=92t believe that negotiation (policy) has to be part of this > proposal, so in the spec if one of the claims is not supported then the > token MUST not be processed. We have this today in the web services secur= ity > stack and there are really no issues. > > > > *From:* Dirk Balfanz [mailto:balfanz@google.com] > *Sent:* Friday, October 01, 2010 8:45 PM > *To:* Yaron Goland > *Cc:* Anthony Nadalin; Mike Jones; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com> wrote= : > > No matter what algorithm or key size we pick the choice will prove > unsupportable for any number of implementers due to everything from secur= ity > issues (no matter what key size we pick, someone will have a real need fo= r > something larger) to legal issues (various countries have their own opini= ons > about what to use where, a la the NSA suite list). > > > > So we are going to have to support multiple algorithms and we are going t= o > have to deal with algorithm negotiation. I literally can see no way aroun= d > that. > > > > I agree that over time, what will be considered secure will change. I als= o > agree that usually this means that there is some sort of negotiation > happening on what the two parties support. How would that happen here? > Remember that - as one datapoint - Google won't be able to support the EC= C > algorithm. What happens when you can't support one of the proposed > algorithms, and there is no provision in the protocol to signal this to > other parties? > > > > Dirk. > > > > > > Yaron > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Anthony Nadalin > *Sent:* Wednesday, September 29, 2010 8:34 AM > *To:* Dirk Balfanz; Mike Jones > > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > > So this one I do feel more strongly about: We should only include crypt= o > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, > please use ABC". Let's not do that. > > > > >As just one datapoint, Google would have a hard time supporting ECC, sin= ce > it's not in the Java core library. We don't use bouncycastle. > > > > I agree that there can be license issues that one could encounter with EC= C > (as we all did with RSA), there are already customers that require ECC, a= nd > so there is a need to have alternative algorithms that you don=92t have t= o > support. We already have the issue of =93do you support=94 with claims an= d token > types, etc > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Dirk Balfanz > *Sent:* Tuesday, September 28, 2010 10:23 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > Dirk and I both posted JSON Token drafts on Thursday. They are at > http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html(= which I=92ll refer to as Dirk=92s draft) and > http://self-issued.info/docs/draft-goland-json-web-token-00.html (which > I=92ll refer to as JWT). This note points out some of the differences (a= nd > commonalities) in the interest of building consensus towards a unified > approach. > > > > Commonalities: > > =B7 Both have ways of expressing the signature algorithm, token > issuer, token expiration time, and intended audience. > > =B7 Both use a form of base64url encoding of the JSON claim data. > > =B7 Both require support for the HMAC SHA-256 signature algorithm= , > and describe how to sign with RSA SHA-256 as well. > > > > Differences: > > =B7 Dirk=92s draft uses a base64url encoding that may include one= or > two =91=3D=92 pad characters. The JWT draft uses base64url encoding with= out > padding. > > =B7 JWT uses shorter claim names in the interest of brevity (=93i= ss=94, > =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93au= dience=94). > > =B7 JWT also describes how to sign with ECDSA SHA-256, plus HMAC, > RSA, and ECDSA with longer key lengths. > > =B7 Dirk=92s tokens must be signed, whereas signing JWTs is optio= nal. > > =B7 Dirk=92s draft provides for a key_id parameter and a means of > serializing keys. > > =B7 Dirk=92s draft utilizes a Magic Signatures envelope, whereas = the > only =93envelope=94 component of a JWT is the encoded signature. > > =B7 Dirk=92s draft proposes that a particular discovery mechanism= be > used with JSON tokens. > > > > Let me tackle the differences one at a time, in hopes of driving towards = a > consensus position. > > > > Hi there - thanks for writhing this up. Comments below: > > =B7 *To pad or not to pad:* The =91=3D=92 pad characters add le= ngth, are > not URL-safe (and therefore must be escaped when used in URLs, adding mor= e > length), and add no information. Therefore, I would propose that we agre= e > not to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf= .org/html/rfc4648#section-5>), > especially since a no-padding implementation is trivial, as shown in JWT > Section 13<http://self-issued.info/docs/draft-goland-json-web-token-00.ht= ml#base64urlnotes> > . > > > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, padding-less encoding is not well-supported in so= me > frameworks, which can lead to confusion. > > > > =B7 *Claim name length:* Given that a core goal of both specs is > short tokens, I would propose that we use the shorter reserved claim name= s. > Having short tokens is especially important when used with mobile browser= s, > where URL length restrictions may be severe. (People are always free to = use > longer ones in any particular application context if they have a reason t= o > do so.) > > > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > > > =B7 *Elliptic curve crypto and longer key lengths:* The JWT spe= c > defines how to use ECC as well as HMAC and RSA. Given ECC=92s inclusion = in NSA > Suite B <http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml>a= nd that it has engineering advantages over RSA (shorter key lengths and > more efficient computations), it makes sense that any modern spec > incorporating cryptography allow its use as an option. Likewise, it make= s > sense for the spec to define how to use longer key lengths on an optional > basis. > > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > > > As just one datapoint, Google would have a hard time supporting ECC, sinc= e > it's not in the Java core library. We don't use bouncycastle. > > > > =B7 *Unsigned tokens:* In some application contexts, it may mak= e > sense to send unsigned tokens if carried in a signed and/or encrypted > container or channel. Allowing for unsigned tokens means that double > signing need not occur. > > That one just confuses me :-) What's the difference between OAuth withou= t > signatures and unsigned tokens? Is the latter not just a more complicated > way of doing the former? > > > > =B7 *Key identification:* I agree that having means of identify= ing > and distributing keys are critical for to end-to-end security of signed > tokens. That=92s a separate point from whether the key identification an= d > distribution mechanisms should be part of the token format specification,= or > treated separately. I would advocate that it be treated separately (as w= as > done with SWTs as well), but am open to discussion on this point. > > =B7 *Discovery:* Like key distribution, I believe that an agreem= ent > on discovery mechanisms is critical to many use cases. But like key > distribution, I=92d like us to take that up in a separate specification, > rather than tightly binding the use of JSON tokens to a particular discov= ery > mechanism. > > > > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, k= ey > rotation, etc. To actually reap the benefits of key rotation, though, we > need to say how to find out what the currently-used key is. If we don't, > then a lot of the potential advantage of using public keys evaporates. I'= m > concerned that, lacking the discovery spec, developers will start > hard-coding keys into their servers, and we'll end up in a situation wher= e > we can't rotate keys when Something Bad happens. > > > > =B7 *Envelope structure:* Dirk=92s draft proposes that the sign= ed > content be wrapped in a particular kind of envelope. Among other things, > this envelope can help prevent a token from being repurposed from one > context to another, by having a clear (and cryptographically verified) > declaration that =93This is a JSON token=94. I understand this motivatio= n and > am open to discussions on how to best achieve it, while still providing a= s > little mechanism as possible (but no less J). > > Well, you've seen my proposal on how to achieve it :-), but I'm also ope= n > to better ways, if someone comes up with one... > > > > Dirk. > > > > > > Dirk, and others, please jump in! > > > > -- Mike > > > > > > > --005045014273a791860491f96c69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So what's the proposal, then? That OAuth service providers document wha= t crypto mechanisms they support? And developers will<meta charset=3D"utf-8= ">=A0just=A0have to know which alg to use with which service provider? I gu= ess I could live with that...<div> <br></div><div>Dirk.<br><br><div class=3D"gmail_quote">On Mon, Oct 4, 2010 = at 12:37 AM, Anthony Nadalin <span dir=3D"ltr"><<a href=3D"mailto:tonyna= d@microsoft.com">tonynad@microsoft.com</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I don= =92t believe that negotiation (policy) has to be part of this proposal, so = in the spec if one of the claims is not supported then the token MUST not b= e processed. We have this today in the web services security stack and there are really= no issues.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> Dirk Balfanz [mailto:<a href=3D"mailto:ba= lfanz@google.com" target=3D"_blank">balfanz@google.com</a>] <br></span></p><div class=3D"im"> <b>Sent:</b> Friday, October 01, 2010 8:45 PM<br> <b>To:</b> Yaron Goland<br> </div><b>Cc:</b> Anthony Nadalin; Mike Jones; <a href=3D"mailto:oauth@ietf.= org" target=3D"_blank">oauth@ietf.org</a><div><div></div><div class=3D"h5">= <br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</div></div><= p></p><div><div></div><div class=3D"h5"> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <<a = href=3D"mailto:yarong@microsoft.com" target=3D"_blank">yarong@microsoft.com= </a>> wrote:</p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">No ma= tter what algorithm or key size we pick the choice will prove unsupportable= for any number of implementers due to everything from security issues (no matter what key size we pick, someone will have a real= need for something larger) to legal issues (various countries have their o= wn opinions about what to use where, a la the NSA suite list). </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">So we= are going to have to support multiple algorithms and we are going to have = to deal with algorithm negotiation. I literally can see no way around that.</span></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I agree that over time, what will be considered secu= re will change. I also agree that usually this means that there is some sor= t of negotiation happening on what the two parties support. How would that = happen here? Remember that - as one datapoint - Google won't be able to support the ECC algorithm. What ha= ppens when you can't support one of the proposed algorithms, and there = is no provision in the protocol to signal this to other parties?</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Dirk.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Yaron</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">><= /span> So this one I do feel more strongly about: We should only include cr= ypto mechanisms that everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: &q= uot;do you support alg XYZ? No I don't, > please use ABC". Let&= #39;s not do that.=A0</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">>As just one datapoint, Google would have a hard = time supporting ECC, since it's not in the Java core library. We don= 9;t use bouncycastle.</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I agr= ee that there can be license issues that one could encounter with ECC (as w= e all did with RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that yo= u don=92t have to support. We already have the issue of =93do you support= =94 with claims and token types, etc</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span></p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a h= ref=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@= microsoft.com</a>> wrote:</p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">Dirk and I both posted JSON Token drafts on Thursday= .=A0 They are at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I=92ll refer to as Dirk=92s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I=92ll refer to as JWT).=A0 This note points out some of the differences (= and commonalities) in the interest of building consensus towards a unified = approach.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Commonalities:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both use a form of base64url encoding of the JSON claim data.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Differences:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft uses a base64url encoding that may include one or two= =91=3D=92 pad characters.=A0 The JWT draft uses base64url encoding without= padding.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT uses shorter claim names in the interest of brevity (=93iss=94, = =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93audi= ence=94).</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s tokens must be signed, whereas signing JWTs is optional.</p= > <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft provides for a key_id parameter and a means of serial= izing keys.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft utilizes a Magic Signatures envelope, whereas the onl= y =93envelope=94 component of a JWT is the encoded signature.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft proposes that a particular discovery mechanism be use= d with JSON tokens.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Let me tackle the differences one at a time, in hope= s of driving towards a consensus position.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Hi there - thanks for writhing this up. Comments bel= ow:</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>To pad or not to pad:</b>=A0 The =91=3D=92 pad characters add len= gth, are not URL-safe (and therefore must be escaped when used in URLs, add= ing more length), and add no information.=A0 Therefore, I would propose tha= t we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but remember J= ohn Panzer's cautionary tales here: Apparently, padding-less encoding i= s not well-supported in some frameworks, which can lead to confusion.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.= =A0 Having short tokens is especially important when used with mobile brows= ers, where URL length restrictions may be severe.=A0 (People are always free to use longer ones in any particular= application context if they have a reason to do so.)</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but I think ma= ny people do want to have more descriptive names here.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Elliptic curve crypto and longer key lengths:</b>=A0 The JWT spec= defines how to use ECC as well as HMAC and RSA.=A0 Given ECC=92s inclusion= in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.=A0 Likewise, it= makes sense for the spec to define how to use longer key lengths on an optional basis.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">So this one I do feel more strongly about: We should= only include crypto mechanisms that everybody MUST support. Otherwise, we&= #39;ll have to invent some sort of negotiation step in the protocol: "do you support alg XYZ? No I don't, please use ABC= ". Let's not do that.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">As just one datapoint, Google would have a hard time= supporting ECC, since it's not in the Java core library. We don't = use bouncycastle.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Unsigned tokens:</b>=A0 In some application contexts, it may make= sense to send unsigned tokens if carried in a signed and/or encrypted cont= ainer or channel.=A0 Allowing for unsigned tokens means that double signing= need not occur.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">That one just confuses me :-) What's the differe= nce between OAuth without signatures and unsigned tokens? Is the latter not= just a more complicated way of doing the former?=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Key identification:</b>=A0 I agree that having means of identifyi= ng and distributing keys are critical for to end-to-end security of signed = tokens.=A0 That=92s a separate point from whether the key identification an= d distribution mechanisms should be part of the token format specification, or treated separately.=A0 I would advoc= ate that it be treated separately (as was done with SWTs as well), but am o= pen to discussion on this point.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Discovery:</b>=A0 Like key distribution, I believe that an agreem= ent on discovery mechanisms is critical to many use cases.=A0 But like key = distribution, I=92d like us to take that up in a separate specification, ra= ther than tightly binding the use of JSON tokens to a particular discovery mechanism.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Here is where I'm coming from: I find the public= -key versions of the signatures much more intriguing - they allow for easie= r key management, key rotation, etc. To actually reap the benefits of key rotation, though, we need to say how to find out what = the currently-used key is. If we don't, then a lot of the potential adv= antage of using public keys evaporates. I'm concerned that, lacking the= discovery spec, developers will start hard-coding keys into their servers, and we'll end up in a situation where we can&= #39;t rotate keys when Something Bad happens.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0=A0</span><b>Envelope structure:</b>=A0 Dirk= =92s draft proposes that the signed content be wrapped in a particular kind= of envelope. =A0Among other things, this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that =93This is a JSON toke= n=94.=A0 I understand this motivation and am open to discussions on how to = best achieve it, while still providing as little mechanism as possible (but no less=A0<span style=3D"font-family:= Wingdings">J</span>).</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">Well, you've seen my proposal on how to achieve = it :-), but I'm also open to better ways, if someone comes up with one.= ..</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Dirk.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Dirk, and others, please jump in!</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike</p> <p class=3D"MsoNormal">=A0</p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal">=A0</p> </div> </div> </div> </div> </div> </blockquote> </div> <p class=3D"MsoNormal">=A0</p> </div></div></div> </div> </blockquote></div><br></div> --005045014273a791860491f96c69-- From phil.hunt@oracle.com Wed Oct 6 14:34:37 2010 Return-Path: <phil.hunt@oracle.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9105D3A71E2 for <oauth@core3.amsl.com>; Wed, 6 Oct 2010 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsf2KHKVOr34 for <oauth@core3.amsl.com>; Wed, 6 Oct 2010 14:34:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9B2F73A6EBF for <oauth@ietf.org>; Wed, 6 Oct 2010 14:34:36 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o96LZZNs006364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Wed, 6 Oct 2010 21:35:36 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o96HoCnY029593 for <oauth@ietf.org>; Wed, 6 Oct 2010 21:35:35 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 660624111286400850; Wed, 06 Oct 2010 14:34:10 -0700 Received: from [192.168.1.17] (/24.85.246.71) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Oct 2010 14:34:10 -0700 From: Phil Hunt <phil.hunt@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 14:34:08 -0700 Message-Id: <3FE44C47-9D12-4F05-85F3-0FFAF53BCAEC@oracle.com> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Indirect Access Grant Flow vs. User Agent Profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 21:34:37 -0000 I'm just re-reading section one, and the overview in section 1.3 seems = to have some inconsistencies/duplication with section 1.4 (profiles). Specifically, on page 9 in draft 10, figure 3 shows an apparent profile. = I assume this is just talking about a variation of the abstract profile. = The paragraph before suggests this is the same "profile" as in section = 1.4.2. Yet there are inconsistencies. It is not clear to me what the text on page 9 is attempting to say that = is different from section 1.4.2. Or for that matter why figures 2 and 3 = exist if there is another section on profiles. Would it be better to cut out everything beyond the basic abstract = profile description and leave out figures 2 and 3 in section 1.3. Or do = figures 2 and 3 need more text make clear distinct separate "flows" that = are used by profiles in section 1.4? Phil phil.hunt@oracle.com From tonynad@microsoft.com Thu Oct 7 00:17:45 2010 Return-Path: <tonynad@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572A93A6D4F for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 00:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.308 X-Spam-Level: X-Spam-Status: No, score=-10.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYHlyBD1d7CE for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 00:17:31 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id CFBF23A6C91 for <oauth@ietf.org>; Thu, 7 Oct 2010 00:17:31 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Oct 2010 00:18:27 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.41]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0218.012; Thu, 7 Oct 2010 00:18:27 -0700 From: Anthony Nadalin <tonynad@microsoft.com> To: Dirk Balfanz <balfanz@google.com> Thread-Topic: [OAUTH-WG] Comparing the JSON Token drafts Thread-Index: Actepo9jOHYKrp9WTw+gSIlGeIAPVgAxfo4AAB+fEkAAc5aNgAAZXjwAAF3pQcAAkFBuAAAF9oPw Date: Thu, 7 Oct 2010 07:18:26 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> In-Reply-To: <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F093C69TK5EX14MBXC113red_" MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 07:17:45 -0000 --_000_180155C5EA10854997314CA5E063D18F093C69TK5EX14MBXC113red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that this would be the baseline and if there is interest in some so= rt of negotiation protocol then could take that up at a later time, I know= its not the best but we need to be able to support the government endorsed= algorithms From: Dirk Balfanz [mailto:balfanz@google.com] Sent: Wednesday, October 06, 2010 2:26 PM To: Anthony Nadalin Cc: Yaron Goland; Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts So what's the proposal, then? That OAuth service providers document what cr= ypto mechanisms they support? And developers will just have to know which a= lg to use with which service provider? I guess I could live with that... Dirk. On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <tonynad@microsoft.com<mai= lto:tonynad@microsoft.com>> wrote: I don't believe that negotiation (policy) has to be part of this proposal, = so in the spec if one of the claims is not supported then the token MUST no= t be processed. We have this today in the web services security stack and t= here are really no issues. From: Dirk Balfanz [mailto:balfanz@google.com<mailto:balfanz@google.com>] Sent: Friday, October 01, 2010 8:45 PM To: Yaron Goland Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com<mailto:y= arong@microsoft.com>> wrote: No matter what algorithm or key size we pick the choice will prove unsuppor= table for any number of implementers due to everything from security issues= (no matter what key size we pick, someone will have a real need for someth= ing larger) to legal issues (various countries have their own opinions abou= t what to use where, a la the NSA suite list). So we are going to have to support multiple algorithms and we are going to = have to deal with algorithm negotiation. I literally can see no way around = that. I agree that over time, what will be considered secure will change. I also = agree that usually this means that there is some sort of negotiation happen= ing on what the two parties support. How would that happen here? Remember t= hat - as one datapoint - Google won't be able to support the ECC algorithm.= What happens when you can't support one of the proposed algorithms, and th= ere is no provision in the protocol to signal this to other parties? Dirk. Yaron From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Anthony Nadali= n Sent: Wednesday, September 29, 2010 8:34 AM To: Dirk Balfanz; Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts > So this one I do feel more strongly about: We should only include crypto = mechanisms that everybody MUST support. Otherwise, we'll have to invent som= e sort of negotiation step in the protocol: "do you support alg XYZ? No I d= on't, > please use ABC". Let's not do that. >As just one datapoint, Google would have a hard time supporting ECC, since= it's not in the Java core library. We don't use bouncycastle. I agree that there can be license issues that one could encounter with ECC = (as we all did with RSA), there are already customers that require ECC, and= so there is a need to have alternative algorithms that you don't have to s= upport. We already have the issue of "do you support" with claims and token= types, etc From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Dirk Balfanz Sent: Tuesday, September 28, 2010 10:23 AM To: Mike Jones Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com<ma= ilto:Michael.Jones@microsoft.com>> wrote: Dirk and I both posted JSON Token drafts on Thursday. They are at http://b= alfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which I'l= l refer to as Dirk's draft) and http://self-issued.info/docs/draft-goland-j= son-web-token-00.html (which I'll refer to as JWT). This note points out s= ome of the differences (and commonalities) in the interest of building cons= ensus towards a unified approach. Commonalities: * Both have ways of expressing the signature algorithm, token issue= r, token expiration time, and intended audience. * Both use a form of base64url encoding of the JSON claim data. * Both require support for the HMAC SHA-256 signature algorithm, an= d describe how to sign with RSA SHA-256 as well. Differences: * Dirk's draft uses a base64url encoding that may include one or tw= o '=3D' pad characters. The JWT draft uses base64url encoding without padd= ing. * JWT uses shorter claim names in the interest of brevity ("iss", "= exp", and "aud", versus "issuer", "not_after", and "audience"). * JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA= , and ECDSA with longer key lengths. * Dirk's tokens must be signed, whereas signing JWTs is optional. * Dirk's draft provides for a key_id parameter and a means of seria= lizing keys. * Dirk's draft utilizes a Magic Signatures envelope, whereas the on= ly "envelope" component of a JWT is the encoded signature. * Dirk's draft proposes that a particular discovery mechanism be us= ed with JSON tokens. Let me tackle the differences one at a time, in hopes of driving towards a = consensus position. Hi there - thanks for writhing this up. Comments below: * To pad or not to pad: The '=3D' pad characters add length, are n= ot URL-safe (and therefore must be escaped when used in URLs, adding more l= ength), and add no information. Therefore, I would propose that we agree n= ot to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf.or= g/html/rfc4648#section-5>), especially since a no-padding implementation is= trivial, as shown in JWT Section 13<http://self-issued.info/docs/draft-gol= and-json-web-token-00.html#base64urlnotes>. I don't feel strongly about this, but remember John Panzer's cautionary tal= es here: Apparently, padding-less encoding is not well-supported in some fr= ameworks, which can lead to confusion. * Claim name length: Given that a core goal of both specs is short = tokens, I would propose that we use the shorter reserved claim names. Havi= ng short tokens is especially important when used with mobile browsers, whe= re URL length restrictions may be severe. (People are always free to use l= onger ones in any particular application context if they have a reason to d= o so.) I don't feel strongly about this, but I think many people do want to have m= ore descriptive names here. * Elliptic curve crypto and longer key lengths: The JWT spec defin= es how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Su= ite B<http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> and t= hat it has engineering advantages over RSA (shorter key lengths and more ef= ficient computations), it makes sense that any modern spec incorporating cr= yptography allow its use as an option. Likewise, it makes sense for the sp= ec to define how to use longer key lengths on an optional basis. So this one I do feel more strongly about: We should only include crypto me= chanisms that everybody MUST support. Otherwise, we'll have to invent some = sort of negotiation step in the protocol: "do you support alg XYZ? No I don= 't, please use ABC". Let's not do that. As just one datapoint, Google would have a hard time supporting ECC, since = it's not in the Java core library. We don't use bouncycastle. * Unsigned tokens: In some application contexts, it may make sense= to send unsigned tokens if carried in a signed and/or encrypted container = or channel. Allowing for unsigned tokens means that double signing need no= t occur. That one just confuses me :-) What's the difference between OAuth without s= ignatures and unsigned tokens? Is the latter not just a more complicated wa= y of doing the former? * Key identification: I agree that having means of identifying and= distributing keys are critical for to end-to-end security of signed tokens= . That's a separate point from whether the key identification and distribu= tion mechanisms should be part of the token format specification, or treate= d separately. I would advocate that it be treated separately (as was done = with SWTs as well), but am open to discussion on this point. * Discovery: Like key distribution, I believe that an agreement on= discovery mechanisms is critical to many use cases. But like key distribu= tion, I'd like us to take that up in a separate specification, rather than = tightly binding the use of JSON tokens to a particular discovery mechanism. Here is where I'm coming from: I find the public-key versions of the signat= ures much more intriguing - they allow for easier key management, key rotat= ion, etc. To actually reap the benefits of key rotation, though, we need to= say how to find out what the currently-used key is. If we don't, then a lo= t of the potential advantage of using public keys evaporates. I'm concerned= that, lacking the discovery spec, developers will start hard-coding keys i= nto their servers, and we'll end up in a situation where we can't rotate ke= ys when Something Bad happens. * Envelope structure: Dirk's draft proposes that the signed conten= t be wrapped in a particular kind of envelope. Among other things, this en= velope can help prevent a token from being repurposed from one context to a= nother, by having a clear (and cryptographically verified) declaration that= "This is a JSON token". I understand this motivation and am open to discu= ssions on how to best achieve it, while still providing as little mechanism= as possible (but no less :)). Well, you've seen my proposal on how to achieve it :-), but I'm also open t= o better ways, if someone comes up with one... Dirk. Dirk, and others, please jump in! -- Mike --_000_180155C5EA10854997314CA5E063D18F093C69TK5EX14MBXC113red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I think that this would b= e the baseline and if there is interest in some sort of negotiation protoco= l then could take that up at  a later time, I know its not the best but we need to be able to support the government endorsed algorit= hms <o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Dirk Bal= fanz [mailto:balfanz@google.com] <br> <b>Sent:</b> Wednesday, October 06, 2010 2:26 PM<br> <b>To:</b> Anthony Nadalin<br> <b>Cc:</b> Yaron Goland; Mike Jones; oauth@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">So what's the proposal, then? That OAuth service pro= viders document what crypto mechanisms they support? And developers will&nb= sp;just have to know which alg to use with which service provider? I g= uess I could live with that...<o:p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Dirk.<o:p></o:p></p> <div> <p class=3D"MsoNormal">On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <= ;<a href=3D"mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>> wro= te:<o:p></o:p></p> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">I don’t belie= ve that negotiation (policy) has to be part of this proposal, so in the spe= c if one of the claims is not supported then the token MUST not be processed. We have this today in the web services se= curity stack and there are really no issues.</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> Dirk Balfanz [mailto:<a href=3D"mailto:balfanz@google.c= om" target=3D"_blank">balfanz@google.com</a>] </span><o:p></o:p></p> <div> <p class=3D"MsoNormal"><b>Sent:</b> Friday, October 01, 2010 8:45 PM<br> <b>To:</b> Yaron Goland<o:p></o:p></p> </div> <p class=3D"MsoNormal"><b>Cc:</b> Anthony Nadalin; Mike Jones; <a href=3D"m= ailto:oauth@ietf.org" target=3D"_blank"> oauth@ietf.org</a><o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= p> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <<a href=3D"mailto= :yarong@microsoft.com" target=3D"_blank">yarong@microsoft.com</a>> wrote= :<o:p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">No matter what algo= rithm or key size we pick the choice will prove unsupportable for any numbe= r of implementers due to everything from security issues (no matter what key size we pick, someone will have a real= need for something larger) to legal issues (various countries have their o= wn opinions about what to use where, a la the NSA suite list). </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">So we are going to = have to support multiple algorithms and we are going to have to deal with a= lgorithm negotiation. I literally can see no way around that.</span><o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I agree that over time, what will be considered secure will change= . I also agree that usually this means that there is some sort of negotiati= on happening on what the two parties support. How would that happen here? Remember that - as one datapoint - Go= ogle won't be able to support the ECC algorithm. What happens when you can'= t support one of the proposed algorithms, and there is no provision in the = protocol to signal this to other parties?<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">   &= nbsp;           &nbs= p;            &= nbsp;   Yaron</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span><o:p></o:p></p> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts<o:p></o:p></= p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">></span> So this= one I do feel more strongly about: We should only include crypto mechanism= s that everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: "= do you support alg XYZ? No I don't, > please use ABC". Let's not do= that. <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">>As just one datapoint, Google would have a hard time supportin= g ECC, since it's not in the Java core library. We don't use bouncycastle.<= o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D">I agree that there = can be license issues that one could encounter with ECC (as we all did with= RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that yo= u don’t have to support. We already have the issue of “do you s= upport” with claims and token types, etc</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;color:#1F497D"> </span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span><o:p><= /o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a href=3D"mailto:= Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@microsoft.com<= /a>> wrote:<o:p></o:p></p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk and I both posted JSON Token drafts on Thursday.  They a= re at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I’ll refer to as Dirk’s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I’ll refer to as JWT).  This note points out some of the differ= ences (and commonalities) in the interest of building consensus towards a u= nified approach.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Commonalities:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both use a form of base64url encoding of the JSON claim data.<o:p></= o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Differences:<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft uses a base64url encoding that may include one or= two ‘=3D’ pad characters.  The JWT draft uses base64url e= ncoding without padding.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT uses shorter claim names in the interest of brevity (“iss&= #8221;, “exp”, and “aud”, versus “issuer̶= 1;, “not_after”, and “audience”).<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s tokens must be signed, whereas signing JWTs is optional= .<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft provides for a key_id parameter and a means of se= rializing keys.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft utilizes a Magic Signatures envelope, whereas the= only “envelope” component of a JWT is the encoded signature.<o= :p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span>Dirk’s draft proposes that a particular discovery mechanism be= used with JSON tokens.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Let me tackle the differences one at a time, in hopes of driving t= owards a consensus position.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Hi there - thanks for writhing this up. Comments below:<o:p></o:p>= </p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>To pad or not to pad:</b>  The ‘=3D’ pad charact= ers add length, are not URL-safe (and therefore must be escaped when used i= n URLs, adding more length), and add no information.  Therefore, I wou= ld propose that we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but remember John Panzer's cauti= onary tales here: Apparently, padding-less encoding is not well-supported i= n some frameworks, which can lead to confusion.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.&n= bsp; Having short tokens is especially important when used with mobile brow= sers, where URL length restrictions may be severe.  (People are always free to use longer ones in any particu= lar application context if they have a reason to do so.)<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">I don't feel strongly about this, but I think many people do want = to have more descriptive names here. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Elliptic curve crypto and longer key lengths:</b>  The JWT s= pec defines how to use ECC as well as HMAC and RSA.  Given ECC’s= inclusion in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.  Likewise,= it makes sense for the spec to define how to use longer key lengths on an optional basis.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">So this one I do feel more strongly about: We should only include = crypto mechanisms that everybody MUST support. Otherwise, we'll have to inv= ent some sort of negotiation step in the protocol: "do you support alg XYZ? No I don't, please use ABC&quo= t;. Let's not do that. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">As just one datapoint, Google would have a hard time supporting EC= C, since it's not in the Java core library. We don't use bouncycastle.<o:p>= </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Unsigned tokens:</b>  In some application contexts, it may m= ake sense to send unsigned tokens if carried in a signed and/or encrypted c= ontainer or channel.  Allowing for unsigned tokens means that double s= igning need not occur.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">That one just confuses me :-) What's the difference between OAuth = without signatures and unsigned tokens? Is the latter not just a more compl= icated way of doing the former? <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Key identification:</b>  I agree that having means of identi= fying and distributing keys are critical for to end-to-end security of sign= ed tokens.  That’s a separate point from whether the key identif= ication and distribution mechanisms should be part of the token format specification, or treated separately.  I would ad= vocate that it be treated separately (as was done with SWTs as well), but a= m open to discussion on this point.<o:p></o:p></p> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>Discovery:</b>  Like key distribution, I believe that an agr= eement on discovery mechanisms is critical to many use cases.  But lik= e key distribution, I’d like us to take that up in a separate specifi= cation, rather than tightly binding the use of JSON tokens to a particular discovery mechanism.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Here is where I'm coming from: I find the public-key versions of t= he signatures much more intriguing - they allow for easier key management, = key rotation, etc. To actually reap the benefits of key rotation, though, we need to say how to find out what = the currently-used key is. If we don't, then a lot of the potential advanta= ge of using public keys evaporates. I'm concerned that, lacking the discove= ry spec, developers will start hard-coding keys into their servers, and we'll end up in a situation where we can't ro= tate keys when Something Bad happens.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">·</span><span style=3D"font-si= ze:7.0pt">         </span><b>E= nvelope structure:</b>  Dirk’s draft proposes that the signed co= ntent be wrapped in a particular kind of envelope.  Among other things= , this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that “This is a JSON = token”.  I understand this motivation and am open to discussions= on how to best achieve it, while still providing as little mechanism as possible (but no less <span style=3D"font-fami= ly:Wingdings">J</span>).<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Well, you've seen my proposal on how to achieve it :-), but I'm al= so open to better ways, if someone comes up with one...<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Dirk, and others, please jump in!<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =             &nb= sp;            =             &nb= sp;            =    -- Mike<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </div> </div> </div> </blockquote> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> </div> </div> </div> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_180155C5EA10854997314CA5E063D18F093C69TK5EX14MBXC113red_-- From prateek.mishra@oracle.com Thu Oct 7 06:57:54 2010 Return-Path: <prateek.mishra@oracle.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9901C3A705C for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47dHKsR-LHdH for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 06:57:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D384E3A6FEA for <oauth@ietf.org>; Thu, 7 Oct 2010 06:57:51 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o97DwoEd003719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 13:58:52 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o97DH9YX029034; Thu, 7 Oct 2010 13:58:49 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 663793261286459850; Thu, 07 Oct 2010 06:57:30 -0700 Received: from [192.168.1.4] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Oct 2010 06:57:28 -0700 Message-ID: <4CADD1C7.8050205@oracle.com> Date: Thu, 07 Oct 2010 09:57:27 -0400 From: Prateek Mishra <prateek.mishra@oracle.com> Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: George Fletcher <gffletch@aol.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> In-Reply-To: <4CA9FEAC.8090407@aol.com> Content-Type: multipart/alternative; boundary="------------080703090003060608090501" Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 13:57:54 -0000 This is a multi-part message in MIME format. --------------080703090003060608090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit George, I will comment at a later time on the details of your use-case. But as far as signing the request for a protected resource (signature over access token, client_id, scope, URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connection may terminate quite early at the resource server site? There may be a good number of hops between SSL termination and the resource server. So I am not sure that we need a business use-case to justify the need for signatures as a means of addressing the threat that the message may altered at the resource server site, before it is presented to a particular resource server. I guess this is a bit different from the motivation for request message signing you described in http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html - prateek > Hi Zachary, > > Here is a use case for signed messages. I've tried to keep this in the > format of the other OAuth use cases. Please contact me off-list if > there are editorial changes required. I've include the list to see if > others have feed back on this use case. > > Thanks, > George > > Use case: Signed Messages > > Description: > > Alice manages all her personal health records in her personal health > data store (www.myhealth.example.com). Alice's Primary Care Physician > (www.pcp.example.com) recommends that Alice see a sleep specialist > (www.sleepwell.example.com). Alice arrives at the sleep specialist's > office and authorizes it to access her basic health data from her PCP. > The application at www.pcp.example.com verifies that Alice has > authorized www.sleepwell.example.com to access her health data as well > as enforces that www.sleepwell.example.com is the only application > that can retrieve that data with that specific authorization. > > Pre-conditions: > > * Alice has a personal health data store that allows for discovery of > her participating health systems (e.g. psychiatrist, sleep specialist, > pcp, orthodontist, ophthalmologist, etc). > * The application at www.myhealth.example.com manages authorization of > access to Alice's participating health systems > * The application at www.myhealth.example.com can issues authorization > tokens understood by Alice's participating health systems > * The application at www.pcp.example.com stores Alice's basic health > and prescription records > * The application at www.sleepwell.com stores results of Alice's sleep > tests > > > Post-conditions: > * A successful procedure results in just the information that Alice > authorized being transferred from the Primary Care Physician > (www.pcp.example.com) to the sleep specialist (www.sleepwell.example.com). > * The transfer of health data only occurs if the application at > www.pcp.example.com can verify that www.sleepwell.example.com is the > party requesting access and that the authorization token presented by > www.sleepwell.example.com is issued by the application at > www.myhealth.example.com with a restricted audience of > www.sleepwell.example.com > > Requirements: > * The application at www.sleepwell.example.com accesses > www.myhealth.example.com to discover the location of the PCP system > (XRD discovery) > * The application at www.sleepwell.example.com requests Alice to > authorize access to the application at www.pcp.example.com for the > purpose of retrieving basic health data (e.g. date-of-birth, weight, > height, etc). The mechanism Alice uses to authorize this access is out > of scope for this use case. > * The application at www.myhealth.example.com issues a token bound to > www.sleepwell.example.com for access to the application at > www.pcp.example.com. Note that a signed token (JWT) can be used to > prove who issued the token. > * The application at www.sleepwell.example.com constructs a request > (includes the token issued by www.myhealth.example.com) to the > application at www.pcp.example.com > * The application at www.sleepwell.example.com signs the request > before sending it to www.pcp.example.com > * The application at www.pcp.example.com receives the request and > verifies the signature > * The application at www.pcp.example.com parses the message and finds > the authorization token > * The application at www.pcp.example.com verifies the signature of the > authorization token > * The application at www.pcp.example.com parses the authorization > token and verifies that this token was issued to the application at > www.sleepwell.com > * The application at www.pcp.example.com retrieves the requested data > and returns it to the application at www.sleepwell.example.com > > > > On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: >> >> These use cases are not in the draft >> https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth. >> >> Could you write them up? >> >> >> >> Thanks, >> >> Zachary >> >> >> >> ------------------------------------------------------------------------ >> >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >> Behalf Of *George Fletcher >> *Sent:* Tuesday, September 28, 2010 11:39 AM >> *To:* OAuth WG >> *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? >> >> >> >> I think of the signature issues as falling into two classes... I >> think they map to your classification as well... >> >> * *Signing tokens* is important for interoperability especially >> looking forward to a time when tokens issued by multiple >> Authorization Servers are accepted at a given host. >> * *Signing messages* is important because it provides a mechanism >> to ensure that the entity making the API call (and presenting >> an access token) is really the entity that is allowed to make >> the API call. >> >> Signing messages applies to the re-delegation use cases. I've heard >> the need for this class of use cases from both the hData (health >> data) community as well as the user managed access (UMA) community. >> >> Signing tokens covers both your second class of tokens as well as >> another use case that Eran has mentioned as well. Namely, a protected >> resource server honoring tokens from multiple Authorization Servers. >> >> These are the two classes of use cases that I'd like to see solved. >> >> Thanks, >> George >> >> >> On 9/28/10 12:58 AM, David Recordon wrote: >> >> If you know me then you'll know that I'm generally one of the last >> people to talk about Alice and Bob. That said, there are a lot of >> technical proposals flying across the list with very little shared >> understanding of the problem(s) we're trying to solve. >> >> >> >> From what I've seen there are two distinct classes of signature use >> cases. >> >> 1) The first is where the HTTP request parameters must be part of the >> signature. An example is any OAuth 1.0a style API where you want to >> make sure that the HTTP POST your server just received isn't >> masquerading itself as a GET. >> >> 2) The second is where the HTTP request is orthogonal. An example >> is OpenSocial where the server is sending state information to the >> client such as what user is currently logged in. >> >> >> >> The main practical example I have of the first use case is what >> Twitter wants to do with redelegation. In this case TweetDeck can't >> given TwitPic it's own bearer token, but needs to sign the POST >> request and pass that signature to TwitPic for it to include in the >> final API request to Twitter. >> >> >> >> In terms of signing protected resource requests, I haven't heard >> anyone bring up specific and detailed needs for this recently. >> >> >> >> JSON tokens pretty clearly make sense for the second class of >> signature use cases and it's actually a bit hard to argue why they >> would be a part of OAuth. Facebook shipped this a bit over a month >> ago for canvas applications. We include a `signed_request` parameter >> which is signature.base64url(JSON). Parsing it is 18 lines of PHP. >> http://developers.facebook.com/docs/authentication/canvas >> >> >> >> This second class of use case will also be required by OpenID Connect >> where the server is signing identity information and sending it to >> the client. I imagine that OpenSocial will also still have it and >> wish to continue relying on public key algorithms. >> >> >> >> So a few questions: >> >> * Do we want to tackle both of these classes of signatures in OAuth? >> >> * Why do you consider the second class part of OAuth versus >> something completely separate that might happen to include an OAuth >> access token? >> >> * Is the Twitter redelegation use case the right focus for the first >> class? >> >> * Is there an example of an OAuth 2.0 server that can't use bearer >> tokens for protected resource requests and thus requires signatures? >> >> >> >> Thanks, >> >> --David >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------080703090003060608090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> George,<br> <br> I will comment at a later time on the details of your use-case. <br> <br> But as far as signing the request for a protected resource (signature over access token, client_id, scope,  URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connection may terminate quite early at the resource server site? There may be a good number of hops between SSL termination and the resource server. So I am not sure that we need a business use-case to justify the need for signatures as a means of addressing the threat that the message may altered at the resource server site, before it is presented to a particular resource server. <br> <br> I guess this is a bit different from the motivation for request message signing you described in <br> <br> <a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html">http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html</a><br> <br> - prateek<br> <blockquote cite="mid:4CA9FEAC.8090407@aol.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <font face="Helvetica, Arial, sans-serif">Hi Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case.<br> <br> Thanks,<br> George<br> <br> </font><font face="Helvetica, Arial, sans-serif">Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data store (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) recommends that Alice see a sleep specialist (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies that Alice has authorized <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> to access her health data as well as enforces that <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the only application that can retrieve that data with that specific authorization.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> stores Alice's basic health and prescription records<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authorized being transferred from the Primary Care Physician (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>).<br> * The transfer of health data only occurs if the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> can verify that <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the party requesting access and that the authorization token presented by <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is issued by the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> with a restricted audience of <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> Requirements:<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> accesses <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> requests Alice to authorize access to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> issues a token bound to <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> for access to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>) to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> signs the request before sending it to <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> receives the request and verifies the signature<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the message and finds the authorization token<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </font><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <blockquote cite="mid:5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman"; color:black;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:130027848; mso-list-template-ids:931952956;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="Section1"> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">These use cases are not in the draft <a moz-do-not-send="true" href="https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Could you write them up?<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Thanks,<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Zachary<o:p></o:p></span></font></p> <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <div> <div class="MsoNormal" style="text-align: center;" align="center"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt; color: windowtext;"> <hr tabindex="-1" align="center" size="2" width="100%"> </span></font></div> <p class="MsoNormal"><b><font color="black" face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext; font-weight: bold;">From:</span></font></b><font color="black" face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext;"> <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>] <b><span style="font-weight: bold;">On Behalf Of </span></b>George Fletcher<br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, September 28, 2010 11:39 AM<br> <b><span style="font-weight: bold;">To:</span></b> OAuth WG<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</span></font><font color="black"><span style="color: windowtext;"><o:p></o:p></span></font></p> </div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica;">I think of the signature issues as falling into two classes... I think they map to your classification as well...</span></font><o:p></o:p></p> <ul type="disc"> <li class="MsoNormal" style=""><b><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing tokens</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span></font><o:p></o:p></li> <li class="MsoNormal" style=""><b><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing messages</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.</span></font><o:p></o:p></li> </ul> <p class="MsoNormal"><font color="black" face="Helvetica" size="3"><span style="font-size: 12pt; font-family: Helvetica;">Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span></font>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">From what I've seen there are two distinct classes of signature use cases.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <meta charset="utf-8"> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a href="http://developers.facebook.com/docs/authentication/canvas" moz-do-not-send="true">http://developers.facebook.com/docs/authentication/canvas</a><o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">So a few questions:<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Do we want to tackle both of these classes of signatures in OAuth?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Is the Twitter redelegation use case the right focus for the first class?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"> * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">Thanks,<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;">--David<o:p></o:p></span></font></p> </div> <pre wrap=""><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><fieldset class="mimeAttachmentHeader"></fieldset><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;">_______________________________________________<o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;">OAuth mailing list<o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></span></font></pre> <pre><font color="black" face="Courier New" size="2"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></span></font></pre> <p class="MsoNormal" style="margin-bottom: 12pt;"><font color="black" face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> </blockquote> <br> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------080703090003060608090501-- From gffletch@aol.com Thu Oct 7 07:11:53 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1619F3A6F5B for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldSTLhWbs0lD for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 07:11:49 -0700 (PDT) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id BA4B23A6F34 for <oauth@ietf.org>; Thu, 7 Oct 2010 07:11:48 -0700 (PDT) Received: from mtaout-da06.r1000.mx.aol.com (mtaout-da06.r1000.mx.aol.com [172.29.51.134]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o97ECSS5015006; Thu, 7 Oct 2010 10:12:28 -0400 Received: from palantir.local (unknown [10.172.2.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 11252E0000EA; Thu, 7 Oct 2010 10:12:22 -0400 (EDT) Message-ID: <4CADD544.9070100@aol.com> Date: Thu, 07 Oct 2010 10:12:20 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Prateek Mishra <prateek.mishra@oracle.com> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <4CADD1C7.8050205@oracle.com> In-Reply-To: <4CADD1C7.8050205@oracle.com> Content-Type: multipart/alternative; boundary="------------020709050403040003010706" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:472980608:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33864cadd54670bc X-AOL-IP: 10.172.2.114 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 14:11:53 -0000 This is a multi-part message in MIME format. --------------020709050403040003010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Prateek, I think that message signing has a number of benefits. The one you state is as important as any others. I was just writing up one use case as a justification for signatures. Not trying to cover them all:) Looking forward to your feedback. Thanks, George On 10/7/10 9:57 AM, Prateek Mishra wrote: > George, > > I will comment at a later time on the details of your use-case. > > But as far as signing the request for a protected resource (signature > over access token, client_id, scope, URL, request body) - isn't this > requirement is a simple consequence of network architecture wherein an > SSL connection may terminate quite early at the resource server site? > There may be a good number of hops between SSL termination and the > resource server. So I am not sure that we need a business use-case to > justify the need for signatures as a means of addressing the threat > that the message may altered at the resource server site, before it is > presented to a particular resource server. > > I guess this is a bit different from the motivation for request > message signing you described in > > http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html > > - prateek >> Hi Zachary, >> >> Here is a use case for signed messages. I've tried to keep this in >> the format of the other OAuth use cases. Please contact me off-list >> if there are editorial changes required. I've include the list to see >> if others have feed back on this use case. >> >> Thanks, >> George >> >> Use case: Signed Messages >> >> Description: >> >> Alice manages all her personal health records in her personal health >> data store (www.myhealth.example.com). Alice's Primary Care Physician >> (www.pcp.example.com) recommends that Alice see a sleep specialist >> (www.sleepwell.example.com). Alice arrives at the sleep specialist's >> office and authorizes it to access her basic health data from her >> PCP. The application at www.pcp.example.com verifies that Alice has >> authorized www.sleepwell.example.com to access her health data as >> well as enforces that www.sleepwell.example.com is the only >> application that can retrieve that data with that specific authorization. >> >> Pre-conditions: >> >> * Alice has a personal health data store that allows for discovery of >> her participating health systems (e.g. psychiatrist, sleep >> specialist, pcp, orthodontist, ophthalmologist, etc). >> * The application at www.myhealth.example.com manages authorization >> of access to Alice's participating health systems >> * The application at www.myhealth.example.com can issues >> authorization tokens understood by Alice's participating health systems >> * The application at www.pcp.example.com stores Alice's basic health >> and prescription records >> * The application at www.sleepwell.com stores results of Alice's >> sleep tests >> >> >> Post-conditions: >> * A successful procedure results in just the information that Alice >> authorized being transferred from the Primary Care Physician >> (www.pcp.example.com) to the sleep specialist >> (www.sleepwell.example.com). >> * The transfer of health data only occurs if the application at >> www.pcp.example.com can verify that www.sleepwell.example.com is the >> party requesting access and that the authorization token presented by >> www.sleepwell.example.com is issued by the application at >> www.myhealth.example.com with a restricted audience of >> www.sleepwell.example.com >> >> Requirements: >> * The application at www.sleepwell.example.com accesses >> www.myhealth.example.com to discover the location of the PCP system >> (XRD discovery) >> * The application at www.sleepwell.example.com requests Alice to >> authorize access to the application at www.pcp.example.com for the >> purpose of retrieving basic health data (e.g. date-of-birth, weight, >> height, etc). The mechanism Alice uses to authorize this access is >> out of scope for this use case. >> * The application at www.myhealth.example.com issues a token bound to >> www.sleepwell.example.com for access to the application at >> www.pcp.example.com. Note that a signed token (JWT) can be used to >> prove who issued the token. >> * The application at www.sleepwell.example.com constructs a request >> (includes the token issued by www.myhealth.example.com) to the >> application at www.pcp.example.com >> * The application at www.sleepwell.example.com signs the request >> before sending it to www.pcp.example.com >> * The application at www.pcp.example.com receives the request and >> verifies the signature >> * The application at www.pcp.example.com parses the message and finds >> the authorization token >> * The application at www.pcp.example.com verifies the signature of >> the authorization token >> * The application at www.pcp.example.com parses the authorization >> token and verifies that this token was issued to the application at >> www.sleepwell.com >> * The application at www.pcp.example.com retrieves the requested data >> and returns it to the application at www.sleepwell.example.com >> >> >> >> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: >>> >>> These use cases are not in the draft >>> https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth. >>> >>> Could you write them up? >>> >>> Thanks, >>> >>> Zachary >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >>> Behalf Of *George Fletcher >>> *Sent:* Tuesday, September 28, 2010 11:39 AM >>> *To:* OAuth WG >>> *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve? >>> >>> I think of the signature issues as falling into two classes... I >>> think they map to your classification as well... >>> >>> * *Signing tokens* is important for interoperability especially >>> looking forward to a time when tokens issued by multiple >>> Authorization Servers are accepted at a given host. >>> * *Signing messages* is important because it provides a >>> mechanism to ensure that the entity making the API call (and >>> presenting an access token) is really the entity that is >>> allowed to make the API call. >>> >>> Signing messages applies to the re-delegation use cases. I've heard >>> the need for this class of use cases from both the hData (health >>> data) community as well as the user managed access (UMA) community. >>> >>> Signing tokens covers both your second class of tokens as well as >>> another use case that Eran has mentioned as well. Namely, a >>> protected resource server honoring tokens from multiple >>> Authorization Servers. >>> >>> These are the two classes of use cases that I'd like to see solved. >>> >>> Thanks, >>> George >>> >>> >>> On 9/28/10 12:58 AM, David Recordon wrote: >>> >>> If you know me then you'll know that I'm generally one of the last >>> people to talk about Alice and Bob. That said, there are a lot of >>> technical proposals flying across the list with very little shared >>> understanding of the problem(s) we're trying to solve. >>> >>> From what I've seen there are two distinct classes of signature use >>> cases. >>> >>> 1) The first is where the HTTP request parameters must be part of >>> the signature. An example is any OAuth 1.0a style API where you want >>> to make sure that the HTTP POST your server just received isn't >>> masquerading itself as a GET. >>> >>> 2) The second is where the HTTP request is orthogonal. An example >>> is OpenSocial where the server is sending state information to the >>> client such as what user is currently logged in. >>> >>> The main practical example I have of the first use case is what >>> Twitter wants to do with redelegation. In this case TweetDeck can't >>> given TwitPic it's own bearer token, but needs to sign the POST >>> request and pass that signature to TwitPic for it to include in the >>> final API request to Twitter. >>> >>> In terms of signing protected resource requests, I haven't heard >>> anyone bring up specific and detailed needs for this recently. >>> >>> JSON tokens pretty clearly make sense for the second class of >>> signature use cases and it's actually a bit hard to argue why they >>> would be a part of OAuth. Facebook shipped this a bit over a month >>> ago for canvas applications. We include a `signed_request` parameter >>> which is signature.base64url(JSON). Parsing it is 18 lines of PHP. >>> http://developers.facebook.com/docs/authentication/canvas >>> >>> This second class of use case will also be required by OpenID >>> Connect where the server is signing identity information and sending >>> it to the client. I imagine that OpenSocial will also still have it >>> and wish to continue relying on public key algorithms. >>> >>> So a few questions: >>> >>> * Do we want to tackle both of these classes of signatures in OAuth? >>> >>> * Why do you consider the second class part of OAuth versus >>> something completely separate that might happen to include an OAuth >>> access token? >>> >>> * Is the Twitter redelegation use case the right focus for the >>> first class? >>> >>> * Is there an example of an OAuth 2.0 server that can't use bearer >>> tokens for protected resource requests and thus requires signatures? >>> >>> Thanks, >>> >>> --David >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------020709050403040003010706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> <font face="Helvetica, Arial, sans-serif">Hi Prateek,<br> <br> I think that message signing has a number of benefits. The one you state is as important as any others. I was just writing up one use case as a justification for signatures. Not trying to cover them all:)<br> <br> Looking forward to your feedback.<br> <br> Thanks,<br> George<br> </font><br> On 10/7/10 9:57 AM, Prateek Mishra wrote: <blockquote cite="mid:4CADD1C7.8050205@oracle.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> George,<br> <br> I will comment at a later time on the details of your use-case. <br> <br> But as far as signing the request for a protected resource (signature over access token, client_id, scope,  URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connection may terminate quite early at the resource server site? There may be a good number of hops between SSL termination and the resource server. So I am not sure that we need a business use-case to justify the need for signatures as a means of addressing the threat that the message may altered at the resource server site, before it is presented to a particular resource server. <br> <br> I guess this is a bit different from the motivation for request message signing you described in <br> <br> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html">http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html</a><br> <br> - prateek<br> <blockquote cite="mid:4CA9FEAC.8090407@aol.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <font face="Helvetica, Arial, sans-serif">Hi Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case.<br> <br> Thanks,<br> George<br> <br> </font><font face="Helvetica, Arial, sans-serif">Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data store (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) recommends that Alice see a sleep specialist (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies that Alice has authorized <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> to access her health data as well as enforces that <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the only application that can retrieve that data with that specific authorization.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> stores Alice's basic health and prescription records<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authorized being transferred from the Primary Care Physician (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a>).<br> * The transfer of health data only occurs if the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> can verify that <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is the party requesting access and that the authorization token presented by <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> is issued by the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> with a restricted audience of <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> Requirements:<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> accesses <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> to discover the location of the PCP system (XRD discovery)<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> requests Alice to authorize access to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> for the purpose of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a> issues a token bound to <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> for access to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> constructs a request (includes the token issued by <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.myhealth.example.com">www.myhealth.example.com</a>) to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a> signs the request before sending it to <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> receives the request and verifies the signature<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the message and finds the authorization token<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> verifies the signature of the authorization token<br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> parses the authorization token and verifies that this token was issued to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.com">www.sleepwell.com</a><br> * The application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.pcp.example.com">www.pcp.example.com</a> retrieves the requested data and returns it to the application at <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </font><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <blockquote cite="mid:5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman"; color:black;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:130027848; mso-list-template-ids:931952956;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="Section1"> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">These use cases are not in the draft <a moz-do-not-send="true" href="https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.<o:p></o:p></span></font></p> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">Could you write them up?<o:p></o:p></span></font></p> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">Thanks,<o:p></o:p></span></font></p> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;">Zachary<o:p></o:p></span></font></p> <p class="MsoNormal"><font face="Arial" size="2" color="navy"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p> <div> <div class="MsoNormal" style="text-align: center;" align="center"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt; color: windowtext;"> <hr tabindex="-1" size="2" width="100%" align="center"> </span></font></div> <p class="MsoNormal"><b><font face="Tahoma" size="2" color="black"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2" color="black"><span style="font-size: 10pt; font-family: Tahoma; color: windowtext;"> <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a> [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a>] <b><span style="font-weight: bold;">On Behalf Of </span></b>George Fletcher<br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, September 28, 2010 11:39 AM<br> <b><span style="font-weight: bold;">To:</span></b> OAuth WG<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</span></font><font color="black"><span style="color: windowtext;"><o:p></o:p></span></font></p> </div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> <p class="MsoNormal"><font face="Helvetica" size="3" color="black"><span style="font-size: 12pt; font-family: Helvetica;">I think of the signature issues as falling into two classes... I think they map to your classification as well...</span></font><o:p></o:p></p> <ul type="disc"> <li class="MsoNormal" style=""><b><font face="Helvetica" size="3" color="black"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing tokens</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span></font><o:p></o:p></li> <li class="MsoNormal" style=""><b><font face="Helvetica" size="3" color="black"><span style="font-size: 12pt; font-family: Helvetica; font-weight: bold;">Signing messages</span></font></b><font face="Helvetica"><span style="font-family: Helvetica;"> is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.</span></font><o:p></o:p></li> </ul> <p class="MsoNormal"><font face="Helvetica" size="3" color="black"><span style="font-size: 12pt; font-family: Helvetica;">Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span></font>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">From what I've seen there are two distinct classes of signature use cases.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <meta charset="utf-8"> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a href="http://developers.facebook.com/docs/authentication/canvas" moz-do-not-send="true">http://developers.facebook.com/docs/authentication/canvas</a><o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms.<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">So a few questions:<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"> * Do we want to tackle both of these classes of signatures in OAuth?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"> * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"> * Is the Twitter redelegation use case the right focus for the first class?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"> * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">Thanks,<o:p></o:p></span></font></p> </div> <div> <p class="MsoNormal"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;">--David<o:p></o:p></span></font></p> </div> <pre wrap=""><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><fieldset class="mimeAttachmentHeader"></fieldset><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;"><o:p> </o:p></span></font></pre> <pre><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;">_______________________________________________<o:p></o:p></span></font></pre> <pre><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;">OAuth mailing list<o:p></o:p></span></font></pre> <pre><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></span></font></pre> <pre><font face="Courier New" size="2" color="black"><span style="font-size: 10pt;"><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></span></font></pre> <p class="MsoNormal" style="margin-bottom: 12pt;"><font face="Times New Roman" size="3" color="black"><span style="font-size: 12pt;"><o:p> </o:p></span></font></p> </div> </blockquote> <br> <pre wrap=""><hr size="4" width="90%"> _______________________________________________ OAuth mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </blockquote> <br> </body> </html> --------------020709050403040003010706-- From balfanz@google.com Thu Oct 7 09:33:53 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E89A3A7253 for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 09:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.027 X-Spam-Level: X-Spam-Status: No, score=-105.027 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfCmemUsqrae for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 09:33:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 329873A6C24 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:33:44 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o97GYgx2009032 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:34:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286469282; bh=p99o2tOOxvfllfpmc9zdLVK5ubE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Hl12yGKI2wytjFowXPREH0y4bvyvIxqmnEZFCjpu39c7kMDGVesXBg1MHQKnMO5VE 4+U7z3rLutJ0W/ahylbYg== Received: from iwn41 (iwn41.prod.google.com [10.241.68.105]) by wpaz24.hot.corp.google.com with ESMTP id o97GYe7d005867 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:34:40 -0700 Received: by iwn41 with SMTP id 41so39488iwn.15 for <oauth@ietf.org>; Thu, 07 Oct 2010 09:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VI83oAo4ZlkwjzsQ9ejCIyipEI01AR8P+r06ljzlBrc=; b=Gf1fzSycSeZab4+Vhr1DglpXEQa/nBJD7kKtqquKWV0KErnlybmFUMKG307rQhWm0l vBoswjupQ95yM+3/FRbA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=geIwiKC3XHPk2ox9DaJC6ZY6Vfj3RPRYlZz8u685BRnegDcRus2pWompKA8KOuFthJ RKmlFqLvVe4MTqK5LGIA== MIME-Version: 1.0 Received: by 10.231.15.203 with SMTP id l11mr1066811iba.182.1286469278521; Thu, 07 Oct 2010 09:34:38 -0700 (PDT) Received: by 10.231.36.133 with HTTP; Thu, 7 Oct 2010 09:34:38 -0700 (PDT) In-Reply-To: <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Thu, 7 Oct 2010 09:34:38 -0700 Message-ID: <AANLkTi=mkh5=GDJcbSsHnNqxLHygUF=PfOk2V07GOo6W@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: Anthony Nadalin <tonynad@microsoft.com> Content-Type: multipart/alternative; boundary=002215046c8f5c6202049209781c X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 16:33:53 -0000 --002215046c8f5c6202049209781c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok, so in the spirit of convergence, I give you (optional) ECC - do you giv= e me Magic Signature Compact Serialization? :-) Dirk. On Thu, Oct 7, 2010 at 12:18 AM, Anthony Nadalin <tonynad@microsoft.com>wro= te: > I think that this would be the baseline and if there is interest in some > sort of negotiation protocol then could take that up at a later time, I > know its not the best but we need to be able to support the government > endorsed algorithms > > > > *From:* Dirk Balfanz [mailto:balfanz@google.com] > *Sent:* Wednesday, October 06, 2010 2:26 PM > *To:* Anthony Nadalin > *Cc:* Yaron Goland; Mike Jones; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > So what's the proposal, then? That OAuth service providers document what > crypto mechanisms they support? And developers will just have to know whi= ch > alg to use with which service provider? I guess I could live with that... > > > > Dirk. > > On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <tonynad@microsoft.com> > wrote: > > I don=92t believe that negotiation (policy) has to be part of this propos= al, > so in the spec if one of the claims is not supported then the token MUST = not > be processed. We have this today in the web services security stack and > there are really no issues. > > > > *From:* Dirk Balfanz [mailto:balfanz@google.com] > > *Sent:* Friday, October 01, 2010 8:45 PM > *To:* Yaron Goland > > *Cc:* Anthony Nadalin; Mike Jones; oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com> wrote= : > > No matter what algorithm or key size we pick the choice will prove > unsupportable for any number of implementers due to everything from secur= ity > issues (no matter what key size we pick, someone will have a real need fo= r > something larger) to legal issues (various countries have their own opini= ons > about what to use where, a la the NSA suite list). > > > > So we are going to have to support multiple algorithms and we are going t= o > have to deal with algorithm negotiation. I literally can see no way aroun= d > that. > > > > I agree that over time, what will be considered secure will change. I als= o > agree that usually this means that there is some sort of negotiation > happening on what the two parties support. How would that happen here? > Remember that - as one datapoint - Google won't be able to support the EC= C > algorithm. What happens when you can't support one of the proposed > algorithms, and there is no provision in the protocol to signal this to > other parties? > > > > Dirk. > > > > > > Yaron > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Anthony Nadalin > *Sent:* Wednesday, September 29, 2010 8:34 AM > *To:* Dirk Balfanz; Mike Jones > > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > > So this one I do feel more strongly about: We should only include crypt= o > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, > please use ABC". Let's not do that. > > > > >As just one datapoint, Google would have a hard time supporting ECC, sin= ce > it's not in the Java core library. We don't use bouncycastle. > > > > I agree that there can be license issues that one could encounter with EC= C > (as we all did with RSA), there are already customers that require ECC, a= nd > so there is a need to have alternative algorithms that you don=92t have t= o > support. We already have the issue of =93do you support=94 with claims an= d token > types, etc > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Dirk Balfanz > *Sent:* Tuesday, September 28, 2010 10:23 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > Dirk and I both posted JSON Token drafts on Thursday. They are at > http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html(= which I=92ll refer to as Dirk=92s draft) and > http://self-issued.info/docs/draft-goland-json-web-token-00.html (which > I=92ll refer to as JWT). This note points out some of the differences (a= nd > commonalities) in the interest of building consensus towards a unified > approach. > > > > Commonalities: > > =B7 Both have ways of expressing the signature algorithm, token > issuer, token expiration time, and intended audience. > > =B7 Both use a form of base64url encoding of the JSON claim data. > > =B7 Both require support for the HMAC SHA-256 signature algorithm= , > and describe how to sign with RSA SHA-256 as well. > > > > Differences: > > =B7 Dirk=92s draft uses a base64url encoding that may include one= or > two =91=3D=92 pad characters. The JWT draft uses base64url encoding with= out > padding. > > =B7 JWT uses shorter claim names in the interest of brevity (=93i= ss=94, > =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93au= dience=94). > > =B7 JWT also describes how to sign with ECDSA SHA-256, plus HMAC, > RSA, and ECDSA with longer key lengths. > > =B7 Dirk=92s tokens must be signed, whereas signing JWTs is optio= nal. > > =B7 Dirk=92s draft provides for a key_id parameter and a means of > serializing keys. > > =B7 Dirk=92s draft utilizes a Magic Signatures envelope, whereas = the > only =93envelope=94 component of a JWT is the encoded signature. > > =B7 Dirk=92s draft proposes that a particular discovery mechanism= be > used with JSON tokens. > > > > Let me tackle the differences one at a time, in hopes of driving towards = a > consensus position. > > > > Hi there - thanks for writhing this up. Comments below: > > =B7 *To pad or not to pad:* The =91=3D=92 pad characters add le= ngth, are > not URL-safe (and therefore must be escaped when used in URLs, adding mor= e > length), and add no information. Therefore, I would propose that we agre= e > not to use padding (as permitted by RFC 4648, Section 5<http://tools.ietf= .org/html/rfc4648#section-5>), > especially since a no-padding implementation is trivial, as shown in JWT > Section 13<http://self-issued.info/docs/draft-goland-json-web-token-00.ht= ml#base64urlnotes> > . > > > > I don't feel strongly about this, but remember John Panzer's cautionary > tales here: Apparently, padding-less encoding is not well-supported in so= me > frameworks, which can lead to confusion. > > > > =B7 *Claim name length:* Given that a core goal of both specs is > short tokens, I would propose that we use the shorter reserved claim name= s. > Having short tokens is especially important when used with mobile browser= s, > where URL length restrictions may be severe. (People are always free to = use > longer ones in any particular application context if they have a reason t= o > do so.) > > > > I don't feel strongly about this, but I think many people do want to have > more descriptive names here. > > > > =B7 *Elliptic curve crypto and longer key lengths:* The JWT spe= c > defines how to use ECC as well as HMAC and RSA. Given ECC=92s inclusion = in NSA > Suite B <http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml>a= nd that it has engineering advantages over RSA (shorter key lengths and > more efficient computations), it makes sense that any modern spec > incorporating cryptography allow its use as an option. Likewise, it make= s > sense for the spec to define how to use longer key lengths on an optional > basis. > > So this one I do feel more strongly about: We should only include crypto > mechanisms that everybody MUST support. Otherwise, we'll have to invent s= ome > sort of negotiation step in the protocol: "do you support alg XYZ? No I > don't, please use ABC". Let's not do that. > > > > As just one datapoint, Google would have a hard time supporting ECC, sinc= e > it's not in the Java core library. We don't use bouncycastle. > > > > =B7 *Unsigned tokens:* In some application contexts, it may mak= e > sense to send unsigned tokens if carried in a signed and/or encrypted > container or channel. Allowing for unsigned tokens means that double > signing need not occur. > > That one just confuses me :-) What's the difference between OAuth withou= t > signatures and unsigned tokens? Is the latter not just a more complicated > way of doing the former? > > > > =B7 *Key identification:* I agree that having means of identify= ing > and distributing keys are critical for to end-to-end security of signed > tokens. That=92s a separate point from whether the key identification an= d > distribution mechanisms should be part of the token format specification,= or > treated separately. I would advocate that it be treated separately (as w= as > done with SWTs as well), but am open to discussion on this point. > > =B7 *Discovery:* Like key distribution, I believe that an agreem= ent > on discovery mechanisms is critical to many use cases. But like key > distribution, I=92d like us to take that up in a separate specification, > rather than tightly binding the use of JSON tokens to a particular discov= ery > mechanism. > > > > Here is where I'm coming from: I find the public-key versions of the > signatures much more intriguing - they allow for easier key management, k= ey > rotation, etc. To actually reap the benefits of key rotation, though, we > need to say how to find out what the currently-used key is. If we don't, > then a lot of the potential advantage of using public keys evaporates. I'= m > concerned that, lacking the discovery spec, developers will start > hard-coding keys into their servers, and we'll end up in a situation wher= e > we can't rotate keys when Something Bad happens. > > > > =B7 *Envelope structure:* Dirk=92s draft proposes that the sign= ed > content be wrapped in a particular kind of envelope. Among other things, > this envelope can help prevent a token from being repurposed from one > context to another, by having a clear (and cryptographically verified) > declaration that =93This is a JSON token=94. I understand this motivatio= n and > am open to discussions on how to best achieve it, while still providing a= s > little mechanism as possible (but no less J). > > Well, you've seen my proposal on how to achieve it :-), but I'm also ope= n > to better ways, if someone comes up with one... > > > > Dirk. > > > > > > Dirk, and others, please jump in! > > > > -- Mike > > > > > > > > > --002215046c8f5c6202049209781c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok, so in the spirit of convergence, I give you (optional) ECC - do you giv= e me Magic Signature Compact Serialization? :-)<div><br>Dirk.<br><br><div c= lass=3D"gmail_quote">On Thu, Oct 7, 2010 at 12:18 AM, Anthony Nadalin <span= dir=3D"ltr"><<a href=3D"mailto:tonynad@microsoft.com">tonynad@microsoft= .com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I thi= nk that this would be the baseline and if there is interest in some sort of= negotiation protocol then could take that up at =A0a later time, I know it= s not the best but we need to be able to support the government endorsed algorit= hms=20 </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> Dirk Balfanz [mailto:<a href=3D"mailto:ba= lfanz@google.com" target=3D"_blank">balfanz@google.com</a>] <br> <b>Sent:</b> Wednesday, October 06, 2010 2:26 PM<br> <b>To:</b> Anthony Nadalin<br> <b>Cc:</b> Yaron Goland; Mike Jones; <a href=3D"mailto:oauth@ietf.org" targ= et=3D"_blank">oauth@ietf.org</a></span></p><div><div></div><div class=3D"h5= "><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</div></div><= p></p><div><div></div><div class=3D"h5"> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">So what's the proposal, then? That OAuth service= providers document what crypto mechanisms they support? And developers wil= l=A0just=A0have to know which alg to use with which service provider? I gue= ss I could live with that...</p> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Dirk.</p> <div> <p class=3D"MsoNormal">On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <= ;<a href=3D"mailto:tonynad@microsoft.com" target=3D"_blank">tonynad@microso= ft.com</a>> wrote:</p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I don= =92t believe that negotiation (policy) has to be part of this proposal, so = in the spec if one of the claims is not supported then the token MUST not be processed. We have this today in the web services se= curity stack and there are really no issues.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> Dirk Balfanz [mailto:<a href=3D"mailto:ba= lfanz@google.com" target=3D"_blank">balfanz@google.com</a>] </span></p> <div> <p class=3D"MsoNormal"><b>Sent:</b> Friday, October 01, 2010 8:45 PM<br> <b>To:</b> Yaron Goland</p> </div> <p class=3D"MsoNormal"><b>Cc:</b> Anthony Nadalin; Mike Jones; <a href=3D"m= ailto:oauth@ietf.org" target=3D"_blank"> oauth@ietf.org</a></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</p> </div> </div> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <<a = href=3D"mailto:yarong@microsoft.com" target=3D"_blank">yarong@microsoft.com= </a>> wrote:</p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">No ma= tter what algorithm or key size we pick the choice will prove unsupportable= for any number of implementers due to everything from security issues (no matter what key size we pick, someone will have a real= need for something larger) to legal issues (various countries have their o= wn opinions about what to use where, a la the NSA suite list). </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">So we= are going to have to support multiple algorithms and we are going to have = to deal with algorithm negotiation. I literally can see no way around that.</span></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I agree that over time, what will be considered secu= re will change. I also agree that usually this means that there is some sor= t of negotiation happening on what the two parties support. How would that happen here? Remember that - as one datapoint - Go= ogle won't be able to support the ECC algorithm. What happens when you = can't support one of the proposed algorithms, and there is no provision= in the protocol to signal this to other parties?</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Dirk.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Yaron</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Anthony Nadalin<br> <b>Sent:</b> Wednesday, September 29, 2010 8:34 AM<br> <b>To:</b> Dirk Balfanz; Mike Jones</span></p> <div> <div> <p class=3D"MsoNormal"><br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">><= /span> So this one I do feel more strongly about: We should only include cr= ypto mechanisms that everybody MUST support. Otherwise, we'll have to invent some sort of negotiation step in the protocol: &q= uot;do you support alg XYZ? No I don't, > please use ABC". Let&= #39;s not do that.=A0</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">>As just one datapoint, Google would have a hard = time supporting ECC, since it's not in the Java core library. We don= 9;t use bouncycastle.</p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">I agr= ee that there can be license issues that one could encounter with ECC (as w= e all did with RSA), there are already customers that require ECC, and so there is a need to have alternative algorithms that yo= u don=92t have to support. We already have the issue of =93do you support= =94 with claims and token types, etc</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">From:</span></b>= <span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Dirk Balfanz<br> <b>Sent:</b> Tuesday, September 28, 2010 10:23 AM<br> <b>To:</b> Mike Jones<br> <b>Cc:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> Re: [OAUTH-WG] Comparing the JSON Token drafts</span></p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <<a h= ref=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jones@= microsoft.com</a>> wrote:</p> <div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">Dirk and I both posted JSON Token drafts on Thursday= .=A0 They are at <a href=3D"http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken= -00.html" target=3D"_blank"> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html</a= > (which I=92ll refer to as Dirk=92s draft) and <a href=3D"http://self-issued.info/docs/draft-goland-json-web-token-00.html= " target=3D"_blank"> http://self-issued.info/docs/draft-goland-json-web-token-00.html</a> (which= I=92ll refer to as JWT).=A0 This note points out some of the differences (= and commonalities) in the interest of building consensus towards a unified = approach.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Commonalities:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both have ways of expressing the signature algorithm, token issuer, = token expiration time, and intended audience.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both use a form of base64url encoding of the JSON claim data.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Both require support for the HMAC SHA-256 signature algorithm, and d= escribe how to sign with RSA SHA-256 as well.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Differences:</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft uses a base64url encoding that may include one or two= =91=3D=92 pad characters.=A0 The JWT draft uses base64url encoding without= padding.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT uses shorter claim names in the interest of brevity (=93iss=94, = =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93audi= ence=94).</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA, a= nd ECDSA with longer key lengths.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s tokens must be signed, whereas signing JWTs is optional.</p= > <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft provides for a key_id parameter and a means of serial= izing keys.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft utilizes a Magic Signatures envelope, whereas the onl= y =93envelope=94 component of a JWT is the encoded signature.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span>Dirk=92s draft proposes that a particular discovery mechanism be use= d with JSON tokens.</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Let me tackle the differences one at a time, in hope= s of driving towards a consensus position.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Hi there - thanks for writhing this up. Comments bel= ow:</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>To pad or not to pad:</b>=A0 The =91=3D=92 pad characters add len= gth, are not URL-safe (and therefore must be escaped when used in URLs, add= ing more length), and add no information.=A0 Therefore, I would propose tha= t we agree not to use padding (as permitted by <a href=3D"http://tools.ietf.org/html/rfc4648#section-5" target=3D"_bla= nk">RFC 4648, Section 5</a>), especially since a no-padding implementation = is trivial, as shown in<a href=3D"http://self-issued.info/docs/draft-goland= -json-web-token-00.html#base64urlnotes" target=3D"_blank"> JWT Section 13</a>.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but remember J= ohn Panzer's cautionary tales here: Apparently, padding-less encoding i= s not well-supported in some frameworks, which can lead to confusion.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Claim name length:</b> Given that a core goal of both specs is sh= ort tokens, I would propose that we use the shorter reserved claim names.= =A0 Having short tokens is especially important when used with mobile brows= ers, where URL length restrictions may be severe.=A0 (People are always free to use longer ones in any particular= application context if they have a reason to do so.)</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">I don't feel strongly about this, but I think ma= ny people do want to have more descriptive names here.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Elliptic curve crypto and longer key lengths:</b>=A0 The JWT spec= defines how to use ECC as well as HMAC and RSA.=A0 Given ECC=92s inclusion= in <a href=3D"http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" = target=3D"_blank"> NSA Suite B</a> and that it has engineering advantages over RSA (shorter ke= y lengths and more efficient computations), it makes sense that any modern = spec incorporating cryptography allow its use as an option.=A0 Likewise, it= makes sense for the spec to define how to use longer key lengths on an optional basis.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">So this one I do feel more strongly about: We should= only include crypto mechanisms that everybody MUST support. Otherwise, we&= #39;ll have to invent some sort of negotiation step in the protocol: "do you support alg XYZ? No I don't, please use ABC= ". Let's not do that.=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">As just one datapoint, Google would have a hard time= supporting ECC, since it's not in the Java core library. We don't = use bouncycastle.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Unsigned tokens:</b>=A0 In some application contexts, it may make= sense to send unsigned tokens if carried in a signed and/or encrypted cont= ainer or channel.=A0 Allowing for unsigned tokens means that double signing= need not occur.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">That one just confuses me :-) What's the differe= nce between OAuth without signatures and unsigned tokens? Is the latter not= just a more complicated way of doing the former?=A0</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Key identification:</b>=A0 I agree that having means of identifyi= ng and distributing keys are critical for to end-to-end security of signed = tokens.=A0 That=92s a separate point from whether the key identification an= d distribution mechanisms should be part of the token format specification, or treated separately.=A0 I would advoc= ate that it be treated separately (as was done with SWTs as well), but am o= pen to discussion on this point.</p> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0 </span><b>Discovery:</b>=A0 Like key distribution, I believe that an agreem= ent on discovery mechanisms is critical to many use cases.=A0 But like key = distribution, I=92d like us to take that up in a separate specification, ra= ther than tightly binding the use of JSON tokens to a particular discovery mechanism.</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Here is where I'm coming from: I find the public= -key versions of the signatures much more intriguing - they allow for easie= r key management, key rotation, etc. To actually reap the benefits of key rotation, though, we need to say how to find out what = the currently-used key is. If we don't, then a lot of the potential adv= antage of using public keys evaporates. I'm concerned that, lacking the= discovery spec, developers will start hard-coding keys into their servers, and we'll end up in a situation where we can&= #39;t rotate keys when Something Bad happens.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p><span style=3D"font-family:Symbol">=B7</span><span style=3D"font-size:7.= 0pt">=A0=A0=A0=A0=A0=A0=A0=A0=A0</span><b>Envelope structure:</b>=A0 Dirk= =92s draft proposes that the signed content be wrapped in a particular kind= of envelope. =A0Among other things, this envelope can help prevent a token from being repurposed from one context to another, by having a cle= ar (and cryptographically verified) declaration that =93This is a JSON toke= n=94.=A0 I understand this motivation and am open to discussions on how to = best achieve it, while still providing as little mechanism as possible (but no less=A0<span style=3D"font-family:= Wingdings">J</span>).</p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal">Well, you've seen my proposal on how to achieve = it :-), but I'm also open to better ways, if someone comes up with one.= ..</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <div> <p class=3D"MsoNormal">Dirk.</p> </div> <div> <p class=3D"MsoNormal">=A0</p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i= n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-= bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">Dirk, and others, please jump in!</p> <p class=3D"MsoNormal">=A0</p> <p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike</p> <p class=3D"MsoNormal">=A0</p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal">=A0</p> </div> </div> </div> </div> </div> </blockquote> </div> <p class=3D"MsoNormal">=A0</p> </div> </div> </div> </div> </div> <p class=3D"MsoNormal">=A0</p> </div> </div></div></div> </div> </blockquote></div><br></div> --002215046c8f5c6202049209781c-- From tim.freeman@hp.com Thu Oct 7 13:57:55 2010 Return-Path: <tim.freeman@hp.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A7C3A708B for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzfLTbhXH7e7 for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 13:57:52 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 305B23A7020 for <oauth@ietf.org>; Thu, 7 Oct 2010 13:57:52 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 0266A1C156; Thu, 7 Oct 2010 20:58:55 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Oct 2010 20:56:59 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Thu, 7 Oct 2010 20:56:58 +0000 From: "Freeman, Tim" <tim.freeman@hp.com> To: George Fletcher <gffletch@aol.com>, Prateek Mishra <prateek.mishra@oracle.com> Date: Thu, 7 Oct 2010 20:56:57 +0000 Thread-Topic: [OAUTH-WG] Signatures...what are we trying to solve? Thread-Index: ActmKcHdxrfBiIrFRv6CWbN+xmh3SAAN6r+A Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A6539729D07@GVW0432EXB.americas.hpqcorp.net> References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <4CADD1C7.8050205@oracle.com> <4CADD544.9070100@aol.com> In-Reply-To: <4CADD544.9070100@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_59DD1BA8FD3C0F4C90771C18F2B5B53A6539729D07GVW0432EXBame_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 20:57:55 -0000 --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A6539729D07GVW0432EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Prateek Mishra >But as far as signing the request for a protected resource (signature over >access token, client_id, scope, URL, request body) - isn't this requireme= nt >is a simple consequence of network architecture wherein an SSL connection >may terminate quite early at the resource server site? There may be a good >number of hops between SSL termination and the resource server. If you don't trust SSL to do its job, you might as well drop it from the pr= otocol. Tim Freeman Email: tim.freeman@hp.com<mailto:tim.freeman@hp.com> Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G= eorge Fletcher Sent: Thursday, October 07, 2010 7:12 AM To: Prateek Mishra Cc: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? Hi Prateek, I think that message signing has a number of benefits. The one you state is= as important as any others. I was just writing up one use case as a justif= ication for signatures. Not trying to cover them all:) Looking forward to your feedback. Thanks, George On 10/7/10 9:57 AM, Prateek Mishra wrote: George, I will comment at a later time on the details of your use-case. But as far as signing the request for a protected resource (signature over = access token, client_id, scope, URL, request body) - isn't this requiremen= t is a simple consequence of network architecture wherein an SSL connection= may terminate quite early at the resource server site? There may be a good= number of hops between SSL termination and the resource server. So I am no= t sure that we need a business use-case to justify the need for signatures = as a means of addressing the threat that the message may altered at the res= ource server site, before it is presented to a particular resource server. I guess this is a bit different from the motivation for request message sig= ning you described in http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html - prateek Hi Zachary, Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are ed= itorial changes required. I've include the list to see if others have feed = back on this use case. Thanks, George Use case: Signed Messages Description: Alice manages all her personal health records in her personal health data s= tore (www.myhealth.example.com<http://www.myhealth.example.com>). Alice's P= rimary Care Physician (www.pcp.example.com<http://www.pcp.example.com>) rec= ommends that Alice see a sleep specialist (www.sleepwell.example.com<http:/= /www.sleepwell.example.com>). Alice arrives at the sleep specialist's offic= e and authorizes it to access her basic health data from her PCP. The appli= cation at www.pcp.example.com<http://www.pcp.example.com> verifies that Ali= ce has authorized www.sleepwell.example.com<http://www.sleepwell.example.co= m> to access her health data as well as enforces that www.sleepwell.example= .com<http://www.sleepwell.example.com> is the only application that can ret= rieve that data with that specific authorization. Pre-conditions: * Alice has a personal health data store that allows for discovery of her p= articipating health systems (e.g. psychiatrist, sleep specialist, pcp, orth= odontist, ophthalmologist, etc). * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> manages authorization of access to Alice's participating health systems * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> can issues authorization tokens understood by Alice's participating hea= lth systems * The application at www.pcp.example.com<http://www.pcp.example.com> stores= Alice's basic health and prescription records * The application at www.sleepwell.com<http://www.sleepwell.com> stores res= ults of Alice's sleep tests Post-conditions: * A successful procedure results in just the information that Alice authori= zed being transferred from the Primary Care Physician (www.pcp.example.com<= http://www.pcp.example.com>) to the sleep specialist (www.sleepwell.example= .com<http://www.sleepwell.example.com>). * The transfer of health data only occurs if the application at www.pcp.exa= mple.com<http://www.pcp.example.com> can verify that www.sleepwell.example.= com<http://www.sleepwell.example.com> is the party requesting access and th= at the authorization token presented by www.sleepwell.example.com<http://ww= w.sleepwell.example.com> is issued by the application at www.myhealth.examp= le.com<http://www.myhealth.example.com> with a restricted audience of www.s= leepwell.example.com<http://www.sleepwell.example.com> Requirements: * The application at www.sleepwell.example.com<http://www.sleepwell.example= .com> accesses www.myhealth.example.com<http://www.myhealth.example.com> to= discover the location of the PCP system (XRD discovery) * The application at www.sleepwell.example.com<http://www.sleepwell.example= .com> requests Alice to authorize access to the application at www.pcp.exam= ple.com<http://www.pcp.example.com> for the purpose of retrieving basic hea= lth data (e.g. date-of-birth, weight, height, etc). The mechanism Alice use= s to authorize this access is out of scope for this use case. * The application at www.myhealth.example.com<http://www.myhealth.example.c= om> issues a token bound to www.sleepwell.example.com<http://www.sleepwell.= example.com> for access to the application at www.pcp.example.com<http://ww= w.pcp.example.com>. Note that a signed token (JWT) can be used to prove who= issued the token. * The application at www.sleepwell.example.com<http://www.sleepwell.example= .com> constructs a request (includes the token issued by www.myhealth.examp= le.com<http://www.myhealth.example.com>) to the application at www.pcp.exam= ple.com<http://www.pcp.example.com> * The application at www.sleepwell.example.com<http://www.sleepwell.example= .com> signs the request before sending it to www.pcp.example.com<http://www= .pcp.example.com> * The application at www.pcp.example.com<http://www.pcp.example.com> receiv= es the request and verifies the signature * The application at www.pcp.example.com<http://www.pcp.example.com> parses= the message and finds the authorization token * The application at www.pcp.example.com<http://www.pcp.example.com> verifi= es the signature of the authorization token * The application at www.pcp.example.com<http://www.pcp.example.com> parses= the authorization token and verifies that this token was issued to the app= lication at www.sleepwell.com<http://www.sleepwell.com> * The application at www.pcp.example.com<http://www.pcp.example.com> retrie= ves the requested data and returns it to the application at www.sleepwell.e= xample.com<http://www.sleepwell.example.com> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: These use cases are not in the draft https://datatracker.ietf.org/doc/draft= -zeltsan-use-cases-oauth. Could you write them up? Thanks, Zachary ________________________________ From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org] On Behalf Of George Fletcher Sent: Tuesday, September 28, 2010 11:39 AM To: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? I think of the signature issues as falling into two classes... I think they= map to your classification as well... * Signing tokens is important for interoperability especially looking fo= rward to a time when tokens issued by multiple Authorization Servers are ac= cepted at a given host. * Signing messages is important because it provides a mechanism to ensur= e that the entity making the API call (and presenting an access token) is r= eally the entity that is allowed to make the API call. Signing messages applies to the re-delegation use cases. I've heard the nee= d for this class of use cases from both the hData (health data) community a= s well as the user managed access (UMA) community. Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource serve= r honoring tokens from multiple Authorization Servers. These are the two classes of use cases that I'd like to see solved. Thanks, George On 9/28/10 12:58 AM, David Recordon wrote: If you know me then you'll know that I'm generally one of the last people t= o talk about Alice and Bob. That said, there are a lot of technical proposa= ls flying across the list with very little shared understanding of the prob= lem(s) we're trying to solve. >From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signa= ture. An example is any OAuth 1.0a style API where you want to make sure th= at the HTTP POST your server just received isn't masquerading itself as a G= ET. 2) The second is where the HTTP request is orthogonal. An example is OpenSo= cial where the server is sending state information to the client such as wh= at user is currently logged in. The main practical example I have of the first use case is what Twitter wan= ts to do with redelegation. In this case TweetDeck can't given TwitPic it's= own bearer token, but needs to sign the POST request and pass that signatu= re to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bri= ng up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use= cases and it's actually a bit hard to argue why they would be a part of OA= uth. Facebook shipped this a bit over a month ago for canvas applications. = We include a `signed_request` parameter which is signature.base64url(JSON).= Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authent= ication/canvas This second class of use case will also be required by OpenID Connect where= the server is signing identity information and sending it to the client. I= imagine that OpenSocial will also still have it and wish to continue relyi= ng on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something comp= letely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class= ? * Is there an example of an OAuth 2.0 server that can't use bearer tokens = for protected resource requests and thus requires signatures? Thanks, --David _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A6539729D07GVW0432EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:blue; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle19 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:595.3pt 841.9pt; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1750152482; mso-list-template-ids:376443820;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DWordSection1> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>From: Prateek Mishra<br> >But as far as signing the request for a protected resource (signature o= ver <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>access token, client_id, scope,  URL, request body)= - isn't this requirement <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>is a simple consequence of network architecture wherein = an SSL connection <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>may terminate quite early at the resource server site? T= here may be a good <o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>>number of hops between SSL termination and the resource server.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'>If you don't trust SSL to do its job, you might as well drop= it from the protocol.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;color:#1F497D'><o:p>&n= bsp;</o:p></span></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;color:#1F497D'>Tim Fre= eman<br> Email: <a href=3D"mailto:tim.freeman@hp.com">tim.freeman@hp.com</a><br> Desk in Palo Alto: (650) 857-2581<br> Home: (408) 774-1298<br> Cell: (408) 348-7536<o:p></o:p></span></p> </div> <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in'> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma= ","sans-serif"; color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly: "Tahoma","sans-serif";color:windowtext'> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Thursday, October 07, 2010 7:12 AM<br> <b>To:</b> Prateek Mishra<br> <b>Cc:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?<o:= p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>H= i Prateek,<br> <br> I think that message signing has a number of benefits. The one you state is= as important as any others. I was just writing up one use case as a justificat= ion for signatures. Not trying to cover them all:)<br> <br> Looking forward to your feedback.<br> <br> Thanks,<br> George<br> </span><br> On 10/7/10 9:57 AM, Prateek Mishra wrote: <o:p></o:p></p> <p class=3DMsoNormal>George,<br> <br> I will comment at a later time on the details of your use-case. <br> <br> But as far as signing the request for a protected resource (signature over access token, client_id, scope,  URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connection may terminate quite early at the resource server site? There may= be a good number of hops between SSL termination and the resource server. So I= am not sure that we need a business use-case to justify the need for signature= s as a means of addressing the threat that the message may altered at the resour= ce server site, before it is presented to a particular resource server. <br> <br> I guess this is a bit different from the motivation for request message sig= ning you described in <br> <br> <a href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html= ">http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html</a><br> <br> - prateek<br> <br> <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>H= i Zachary,<br> <br> Here is a use case for signed messages. I've tried to keep this in the form= at of the other OAuth use cases. Please contact me off-list if there are edito= rial changes required. I've include the list to see if others have feed back on = this use case.<br> <br> Thanks,<br> George<br> <br> Use case: Signed Messages<br> <br> Description:<br> <br> Alice manages all her personal health records in her personal health data s= tore (<a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a>). Alice's Primary Care Physician (<a href=3D"http://www.pcp.example.com">www.= pcp.example.com</a>) recommends that Alice see a sleep specialist (<a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a>). A= lice arrives at the sleep specialist's office and authorizes it to access her ba= sic health data from her PCP. The application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> verifies that A= lice has authorized <a href=3D"http://www.sleepwell.example.com">www.sleepwell.e= xample.com</a> to access her health data as well as enforces that <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = the only application that can retrieve that data with that specific authorizati= on.<br> <br> Pre-conditions:<br> <br> * Alice has a personal health data store that allows for discovery of her participating health systems (e.g. psychiatrist, sleep specialist, pcp, orthodontist, ophthalmologist, etc).<br> * The application at <a href=3D"http://www.myhealth.example.com">www.myheal= th.example.com</a> manages authorization of access to Alice's participating health systems<br> * The application at <a href=3D"http://www.myhealth.example.com">www.myheal= th.example.com</a> can issues authorization tokens understood by Alice's participating health systems<br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> stores Alice's basic health and prescription records<br> * The application at <a href=3D"http://www.sleepwell.com">www.sleepwell.com= </a> stores results of Alice's sleep tests<br> <br> <br> Post-conditions:<br> * A successful procedure results in just the information that Alice authori= zed being transferred from the Primary Care Physician (<a href=3D"http://www.pcp.example.com">www.pcp.example.com</a>) to the sleep specialist (<a href=3D"http://www.sleepwell.example.com">www.sleepwell.exam= ple.com</a>).<br> * The transfer of health data only occurs if the application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> can verify that= <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = the party requesting access and that the authorization token presented by <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a> is = issued by the application at <a href=3D"http://www.myhealth.example.com">www.myhea= lth.example.com</a> with a restricted audience of <a href=3D"http://www.sleepwell.example.com">= www.sleepwell.example.com</a><br> <br> Requirements:<br> * The application at <a href=3D"http://www.sleepwell.example.com">www.sleep= well.example.com</a> accesses <a href=3D"http://www.myhealth.example.com">www.myhealth.example.c= om</a> to discover the location of the PCP system (XRD discovery)<br> * The application at <a href=3D"http://www.sleepwell.example.com">www.sleep= well.example.com</a> requests Alice to authorize access to the application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</a> for the purpose= of retrieving basic health data (e.g. date-of-birth, weight, height, etc). The mechanism Alice uses to authorize this access is out of scope for this use case.<br> * The application at <a href=3D"http://www.myhealth.example.com">www.myheal= th.example.com</a> issues a token bound to <a href=3D"http://www.sleepwell.example.com">www.sl= eepwell.example.com</a> for access to the application at <a href=3D"http://www.pcp.example.com">www= .pcp.example.com</a>. Note that a signed token (JWT) can be used to prove who issued the token.<b= r> * The application at <a href=3D"http://www.sleepwell.example.com">www.sleep= well.example.com</a> constructs a request (includes the token issued by <a href=3D"http://www.myhealth.example.com">www.myhealth.example.com</a>) to t= he application at <a href=3D"http://www.pcp.example.com">www.pcp.example.com</= a><br> * The application at <a href=3D"http://www.sleepwell.example.com">www.sleep= well.example.com</a> signs the request before sending it to <a href=3D"http://www.pcp.example.co= m">www.pcp.example.com</a><br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> receives the request and verifies the signature<br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> parses the message and finds the authorization token<br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> verifies the signature of the authorization token<br> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> parses the authorization token and verifies that this token was issued to t= he application at <a href=3D"http://www.sleepwell.com">www.sleepwell.com</a><b= r> * The application at <a href=3D"http://www.pcp.example.com">www.pcp.example= .com</a> retrieves the requested data and returns it to the application at <a href=3D"http://www.sleepwell.example.com">www.sleepwell.example.com</a><br> <br> </span><br> <br> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote: <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>These use cases are not in the draft <a href=3D"https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth">htt= ps://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth</a>.</span><o:p= ></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Could you write them up?</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'> </span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Thanks,</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'>Zachary</span><o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s= ans-serif"; color:navy'> </span><o:p></o:p></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span style=3D'color:windowtext'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></div> <p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma= ","sans-serif"; color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly: "Tahoma","sans-serif";color:windowtext'> <a href=3D"mailto:oauth-bounces@ie= tf.org">oauth-bounces@ietf.org</a> [<a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a= >] <b>On Behalf Of </b>George Fletcher<br> <b>Sent:</b> Tuesday, September 28, 2010 11:39 AM<br> <b>To:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] Signatures...what are we trying to solve?</s= pan><o:p></o:p></p> </div> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>I= think of the signature issues as falling into two classes... I think they map to = your classification as well...</span><o:p></o:p></p> <ul style=3D'margin-top:0in' type=3Ddisc> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><span style=3D'= font-family: "Helvetica","sans-serif"'>Signing tokens</span></b><span style=3D'font= -family: "Helvetica","sans-serif"'> is important for interoperability especiall= y looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.</span><o:p></o:p></li> <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><b><span style=3D'= font-family: "Helvetica","sans-serif"'>Signing messages</span></b><span style=3D'font-family:"Helvetica","sans-serif"'> is important because i= t provides a mechanism to ensure that the entity making the API call (an= d presenting an access token) is really the entity that is allowed to ma= ke the API call.</span><o:p></o:p></li> </ul> <p class=3DMsoNormal><span style=3D'font-family:"Helvetica","sans-serif"'>S= igning messages applies to the re-delegation use cases. I've heard the need for th= is class of use cases from both the hData (health data) community as well as t= he user managed access (UMA) community.<br> <br> Signing tokens covers both your second class of tokens as well as another u= se case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.<br> <br> These are the two classes of use cases that I'd like to see solved.<br> <br> Thanks,<br> George<br> <br> <br> O</span>n 9/28/10 12:58 AM, David Recordon wrote: <o:p></o:p></p> <div> <p class=3DMsoNormal>If you know me then you'll know that I'm generally one= of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understa= nding of the problem(s) we're trying to solve.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>From what I've seen there are two distinct classes of signature use cases.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal>1) The first is where the HTTP request parameters must= be part of the signature. An example is any OAuth 1.0a style API where you wan= t to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal>2) The second is where the HTTP request is orthog= onal. An example is OpenSocial where the server is sending state information= to the client such as what user is currently logged in.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>The main practical example I have of the first use cas= e is what Twitter wants to do with redelegation. In this case TweetDeck can't gi= ven TwitPic it's own bearer token, but needs to sign the POST request and pass = that signature to TwitPic for it to include in the final API request to Twitter.= <o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>In terms of signing protected resource requests, I hav= en't heard anyone bring up specific and detailed needs for this recently.<o:p></= o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>JSON tokens pretty clearly make sense for the second c= lass of signature use cases and it's actually a bit hard to argue why they would= be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. <a href=3D"http://developers.facebook.com/docs/authentication/canvas">http://d= evelopers.facebook.com/docs/authentication/canvas</a><o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending= it to the client. I imagine that OpenSocial will also still have it and wish t= o continue relying on public key algorithms.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>So a few questions:<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> * Do we want to tackle both of these classes of signatures in OAuth?<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> * Why do you consider the second class part of O= Auth versus something completely separate that might happen to include an OAuth access token?<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> * Is the Twitter redelegation use case the right= focus for the first class?<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> * Is there an example of an OAuth 2.0 server tha= t can't use bearer tokens for protected resource requests and thus requires signatures?<o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal>Thanks,<o:p></o:p></p> </div> <div> <p class=3DMsoNormal>--David<o:p></o:p></p> </div> <pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre>______________= _________________________________<o:p></o:p></pre><pre>OAuth mailing list<o= :p></o:p></pre><pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre><pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/m= ailman/listinfo/oauth</a><o:p></o:p></pre> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'> <o:p></o:p></p> <p class=3DMsoNormal><br> <br> <o:p></o:p></p> <pre style=3D'text-align:center'> <hr size=3D4 width=3D"90%" align=3Dcenter> </pre><pre><o:p> </o:p></pre><pre>____________________________________= ___________<o:p></o:p></pre><pre>OAuth mailing list<o:p></o:p></pre><pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre><pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/m= ailman/listinfo/oauth</a>  <o:p></o:p></pre> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A6539729D07GVW0432EXBame_-- From sakimura@gmail.com Tue Oct 12 02:20:40 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C438C3A67C2 for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 02:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX5xvjcJxV5b for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 02:20:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 73BB83A6765 for <oauth@ietf.org>; Tue, 12 Oct 2010 02:20:38 -0700 (PDT) Received: by iwn10 with SMTP id 10so5997893iwn.31 for <oauth@ietf.org>; Tue, 12 Oct 2010 02:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6TZ47Vz3GH3dyzqZC57NcpxWwjRx/l+WOAbxhXTlF4s=; b=i0/u6EuYKDR9QM6WkZuida7mT3X5oDIlwRk8fUouJGUsEQ5nDesTOvQXBIWeD6SZBT vqGMCTIG/LIR6JdrILQqRUgeJU0/cJKw0GOe+D7GQUv+G/E0eXnrcDuoGFoWZOa+f/dt OiMjdMJsn71Zs/58ADk6LWXFz8ni/E3a28tNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EH6UyTzYJSTnQzh17gzMBIiPZ2nWLl7c3EExxuBREY4t+42vZTY/v4uAdePYHCSKt+ KUFTe5DfHev9niMUBGaQWNgs9cEELF/fSouW2mTVTyFx+Ja/jEFvi1z8dIPcCnW+41yI 06m257cGp7t4ni4dNNQrkBXsHg511jtHidl0I= MIME-Version: 1.0 Received: by 10.231.80.213 with SMTP id u21mr4828949ibk.173.1286875312112; Tue, 12 Oct 2010 02:21:52 -0700 (PDT) Received: by 10.231.161.138 with HTTP; Tue, 12 Oct 2010 02:21:52 -0700 (PDT) In-Reply-To: <AANLkTi=mkh5=GDJcbSsHnNqxLHygUF=PfOk2V07GOo6W@mail.gmail.com> References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTi=mkh5=GDJcbSsHnNqxLHygUF=PfOk2V07GOo6W@mail.gmail.com> Date: Tue, 12 Oct 2010 18:21:52 +0900 Message-ID: <AANLkTimi=eUNxbn-VesSGSHo2aHakSQ3gr8eH-KjQv7q@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Oct 2010 09:20:40 -0000 JWT does not state anything about how keys are expressed while JT (JSON Tokens) has the discovery in it as stated by the initial mail of this thread. In my use case, I really need X.509 certs in the conventional sense to establish trust. So if key discovery is to be included, finding the X.509 certs through given URI would be good. Please see http://jsonenc.info/jss/1.0/ for what we are doing at Artifact Binding WG. (Hereafter, I refer it as JSS, JSON Simple Sign). The envelope structure used in JSS is a bit different as well. It is closer to JWT so that we only need to base64url encode the envelope and then apply signature, so that we do not need concatenating operation like Dirk's proposal. The main difference is that JSS have "name spaced" the signature parameters and payload so that it is easy to process, as well as to avoid name space collision. We are currently debating if we really need to have "payload" name space though. We could just stick in the "sig_params" to the original JSON structure. (Pros about having "payload" is that then it will be able to sign practically anything, BTW.) If we make them completely flat, without any name spacing, it will be same as the JWT envelope. Down side for that is it is going to be hard to have multiple signatures, which we have in our use cases. =3Dnat On Fri, Oct 8, 2010 at 1:34 AM, Dirk Balfanz <balfanz@google.com> wrote: > Ok, so in the spirit of convergence, I give you (optional) ECC - do you g= ive > me Magic Signature Compact Serialization? :-) > Dirk. > > On Thu, Oct 7, 2010 at 12:18 AM, Anthony Nadalin <tonynad@microsoft.com> > wrote: >> >> I think that this would be the baseline and if there is interest in some >> sort of negotiation protocol then could take that up at =A0a later time,= I >> know its not the best but we need to be able to support the government >> endorsed algorithms >> >> >> >> From: Dirk Balfanz [mailto:balfanz@google.com] >> Sent: Wednesday, October 06, 2010 2:26 PM >> To: Anthony Nadalin >> Cc: Yaron Goland; Mike Jones; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts >> >> >> >> So what's the proposal, then? That OAuth service providers document what >> crypto mechanisms they support? And developers will=A0just=A0have to kno= w which >> alg to use with which service provider? I guess I could live with that..= . >> >> >> >> Dirk. >> >> On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <tonynad@microsoft.com> >> wrote: >> >> I don=92t believe that negotiation (policy) has to be part of this propo= sal, >> so in the spec if one of the claims is not supported then the token MUST= not >> be processed. We have this today in the web services security stack and >> there are really no issues. >> >> >> >> From: Dirk Balfanz [mailto:balfanz@google.com] >> >> Sent: Friday, October 01, 2010 8:45 PM >> To: Yaron Goland >> >> Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts >> >> >> >> On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yarong@microsoft.com> wrot= e: >> >> No matter what algorithm or key size we pick the choice will prove >> unsupportable for any number of implementers due to everything from secu= rity >> issues (no matter what key size we pick, someone will have a real need f= or >> something larger) to legal issues (various countries have their own opin= ions >> about what to use where, a la the NSA suite list). >> >> >> >> So we are going to have to support multiple algorithms and we are going = to >> have to deal with algorithm negotiation. I literally can see no way arou= nd >> that. >> >> >> >> I agree that over time, what will be considered secure will change. I al= so >> agree that usually this means that there is some sort of negotiation >> happening on what the two parties support. How would that happen here? >> Remember that - as one datapoint - Google won't be able to support the E= CC >> algorithm. What happens when you can't support one of the proposed >> algorithms, and there is no provision in the protocol to signal this to >> other parties? >> >> >> >> Dirk. >> >> >> >> >> >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Yaron >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Anthony Nadalin >> Sent: Wednesday, September 29, 2010 8:34 AM >> To: Dirk Balfanz; Mike Jones >> >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts >> >> >> >> > So this one I do feel more strongly about: We should only include cryp= to >> > mechanisms that everybody MUST support. Otherwise, we'll have to inven= t some >> > sort of negotiation step in the protocol: "do you support alg XYZ? No = I >> > don't, > please use ABC". Let's not do that. >> >> >> >> >As just one datapoint, Google would have a hard time supporting ECC, >> > since it's not in the Java core library. We don't use bouncycastle. >> >> >> >> I agree that there can be license issues that one could encounter with E= CC >> (as we all did with RSA), there are already customers that require ECC, = and >> so there is a need to have alternative algorithms that you don=92t have = to >> support. We already have the issue of =93do you support=94 with claims a= nd token >> types, etc >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Dirk Balfanz >> Sent: Tuesday, September 28, 2010 10:23 AM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts >> >> >> >> On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <Michael.Jones@microsoft.com= > >> wrote: >> >> Dirk and I both posted JSON Token drafts on Thursday.=A0 They are at >> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html >> (which I=92ll refer to as Dirk=92s draft) and >> http://self-issued.info/docs/draft-goland-json-web-token-00.html (which = I=92ll >> refer to as JWT).=A0 This note points out some of the differences (and >> commonalities) in the interest of building consensus towards a unified >> approach. >> >> >> >> Commonalities: >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Both have ways of expressing the signature a= lgorithm, token >> issuer, token expiration time, and intended audience. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Both use a form of base64url encoding of the= JSON claim data. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Both require support for the HMAC SHA-256 si= gnature algorithm, >> and describe how to sign with RSA SHA-256 as well. >> >> >> >> Differences: >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft uses a base64url encoding tha= t may include one or >> two =91=3D=92 pad characters.=A0 The JWT draft uses base64url encoding w= ithout >> padding. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 JWT uses shorter claim names in the interest= of brevity (=93iss=94, >> =93exp=94, and =93aud=94, versus =93issuer=94, =93not_after=94, and =93a= udience=94). >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 JWT also describes how to sign with ECDSA SH= A-256, plus HMAC, >> RSA, and ECDSA with longer key lengths. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s tokens must be signed, whereas sign= ing JWTs is optional. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft provides for a key_id paramet= er and a means of >> serializing keys. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft utilizes a Magic Signatures e= nvelope, whereas the >> only =93envelope=94 component of a JWT is the encoded signature. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Dirk=92s draft proposes that a particular di= scovery mechanism be >> used with JSON tokens. >> >> >> >> Let me tackle the differences one at a time, in hopes of driving towards= a >> consensus position. >> >> >> >> Hi there - thanks for writhing this up. Comments below: >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 To pad or not to pad:=A0 The =91=3D=92 pad c= haracters add length, are >> not URL-safe (and therefore must be escaped when used in URLs, adding mo= re >> length), and add no information.=A0 Therefore, I would propose that we a= gree >> not to use padding (as permitted by RFC 4648, Section 5), especially sin= ce a >> no-padding implementation is trivial, as shown in JWT Section 13. >> >> >> >> I don't feel strongly about this, but remember John Panzer's cautionary >> tales here: Apparently, padding-less encoding is not well-supported in s= ome >> frameworks, which can lead to confusion. >> >> >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Claim name length: Given that a core goal of= both specs is short >> tokens, I would propose that we use the shorter reserved claim names. >> Having short tokens is especially important when used with mobile browse= rs, >> where URL length restrictions may be severe.=A0 (People are always free = to use >> longer ones in any particular application context if they have a reason = to >> do so.) >> >> >> >> I don't feel strongly about this, but I think many people do want to hav= e >> more descriptive names here. >> >> >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Elliptic curve crypto and longer key lengths= :=A0 The JWT spec >> defines how to use ECC as well as HMAC and RSA.=A0 Given ECC=92s inclusi= on in >> NSA Suite B and that it has engineering advantages over RSA (shorter key >> lengths and more efficient computations), it makes sense that any modern >> spec incorporating cryptography allow its use as an option.=A0 Likewise,= it >> makes sense for the spec to define how to use longer key lengths on an >> optional basis. >> >> So this one I do feel more strongly about: We should only include crypto >> mechanisms that everybody MUST support. Otherwise, we'll have to invent = some >> sort of negotiation step in the protocol: "do you support alg XYZ? No I >> don't, please use ABC". Let's not do that. >> >> >> >> As just one datapoint, Google would have a hard time supporting ECC, sin= ce >> it's not in the Java core library. We don't use bouncycastle. >> >> >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Unsigned tokens:=A0 In some application cont= exts, it may make >> sense to send unsigned tokens if carried in a signed and/or encrypted >> container or channel.=A0 Allowing for unsigned tokens means that double >> signing need not occur. >> >> That one just confuses me :-) What's the difference between OAuth withou= t >> signatures and unsigned tokens? Is the latter not just a more complicate= d >> way of doing the former? >> >> >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Key identification:=A0 I agree that having m= eans of identifying >> and distributing keys are critical for to end-to-end security of signed >> tokens.=A0 That=92s a separate point from whether the key identification= and >> distribution mechanisms should be part of the token format specification= , or >> treated separately.=A0 I would advocate that it be treated separately (a= s was >> done with SWTs as well), but am open to discussion on this point. >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0 Discovery:=A0 Like key distribution, I belie= ve that an agreement >> on discovery mechanisms is critical to many use cases.=A0 But like key >> distribution, I=92d like us to take that up in a separate specification, >> rather than tightly binding the use of JSON tokens to a particular disco= very >> mechanism. >> >> >> >> Here is where I'm coming from: I find the public-key versions of the >> signatures much more intriguing - they allow for easier key management, = key >> rotation, etc. To actually reap the benefits of key rotation, though, we >> need to say how to find out what the currently-used key is. If we don't, >> then a lot of the potential advantage of using public keys evaporates. I= 'm >> concerned that, lacking the discovery spec, developers will start >> hard-coding keys into their servers, and we'll end up in a situation whe= re >> we can't rotate keys when Something Bad happens. >> >> >> >> =B7=A0=A0=A0=A0=A0=A0=A0=A0=A0Envelope structure:=A0 Dirk=92s draft prop= oses that the signed >> content be wrapped in a particular kind of envelope. =A0Among other thin= gs, >> this envelope can help prevent a token from being repurposed from one >> context to another, by having a clear (and cryptographically verified) >> declaration that =93This is a JSON token=94.=A0 I understand this motiva= tion and >> am open to discussions on how to best achieve it, while still providing = as >> little mechanism as possible (but no less=A0J). >> >> Well, you've seen my proposal on how to achieve it :-), but I'm also ope= n >> to better ways, if someone comes up with one... >> >> >> >> Dirk. >> >> >> >> >> >> Dirk, and others, please jump in! >> >> >> >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike >> >> >> >> >> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From wmills@yahoo-inc.com Tue Oct 12 09:32:40 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0964A3A693E for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.807 X-Spam-Level: X-Spam-Status: No, score=-16.807 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_05=-1.11, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICXOSWgpexhN for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 09:32:39 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 09E223A68DA for <oauth@ietf.org>; Tue, 12 Oct 2010 09:32:30 -0700 (PDT) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o9CGXIMI035997 for <oauth@ietf.org>; Tue, 12 Oct 2010 09:33:19 -0700 (PDT) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Tue, 12 Oct 2010 09:33:18 -0700 From: William Mills <wmills@yahoo-inc.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Tue, 12 Oct 2010 09:33:14 -0700 Thread-Topic: Opensource impl yet? Thread-Index: ActqKyroRXG8W8MtSzGDUZEBkU+e3Q== Message-ID: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AICM A5V/ ByNG DLPd DwDu D9wZ EPG9 EucU Gmhg IXgF JDd+ JNwg JWiI J+x+ KoG6 LNaI; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5F1BED94-2F85-44FB-AB3D-6C3EDE83D771}; dwBtAGkAbABsAHMAQAB5AGEAaABvAG8ALQBpAG4AYwAuAGMAbwBtAA==; Tue, 12 Oct 2010 16:33:14 GMT;TwBwAGUAbgBzAG8AdQByAGMAZQAgAGkAbQBwAGwAIAB5AGUAdAA/AA== x-cr-puzzleid: {5F1BED94-2F85-44FB-AB3D-6C3EDE83D771} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156254C4A715ESP2EX07VS06ds_" MIME-Version: 1.0 Subject: [OAUTH-WG] Opensource impl yet? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Oct 2010 16:32:40 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156254C4A715ESP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a C/C++ opensource implementation yet I can use for the reference = implementation of the SASL mechanism yet? --_000_FFDFD7371D517847AD71FBB08F9A3156254C4A715ESP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>Is there a C/C++ opensource implementation yet I can u= se for the reference implementation of the SASL mechanism yet?<o:p></o:p></p> </div> </body> </html> --_000_FFDFD7371D517847AD71FBB08F9A3156254C4A715ESP2EX07VS06ds_-- From recordond@gmail.com Tue Oct 12 22:31:42 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86043A6B87 for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 22:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgW+g9JVfGfX for <oauth@core3.amsl.com>; Tue, 12 Oct 2010 22:31:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CCF163A6B72 for <oauth@ietf.org>; Tue, 12 Oct 2010 22:31:31 -0700 (PDT) Received: by iwn10 with SMTP id 10so7351037iwn.31 for <oauth@ietf.org>; Tue, 12 Oct 2010 22:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Fl8oUxmGN2/4HEgrSRxWMsIgCfaIdNkC6csLPpwhSVE=; b=cexqZa5awUP8LMGsPQtQVwBzGVyJpnTxaLGbLv3SI9wBPNoQqJW/1GznJ+rrc03S7e J07JZ6HMszrtty3AGVCX8GRRUpiGCnuhWJbl6p1m8d3TQd020wC5Pv3Qf1WcQWvujhfZ NJESAYvaZMk1hd/2xG0yuVQd5FWh+wt/iSTSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FnHWTN+hphX7PTi0BGwSiXNF+jXQc7WzS9FkVSLziardeS8u5EAeYpUFMoHXRTW+PJ XmdcULGLHCEYwjeo39cCGV7Z34X9SuyJW7Sivh5hVhSI1TDlYOIGd9yB/nmYd9s+ADgY RpFrsNl3gSnmTrh61TaC4HHZsHshZ70ToOd8o= MIME-Version: 1.0 Received: by 10.42.209.131 with SMTP id gg3mr3050588icb.448.1286947964316; Tue, 12 Oct 2010 22:32:44 -0700 (PDT) Received: by 10.231.148.70 with HTTP; Tue, 12 Oct 2010 22:32:44 -0700 (PDT) In-Reply-To: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> References: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> Date: Tue, 12 Oct 2010 22:32:44 -0700 Message-ID: <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: William Mills <wmills@yahoo-inc.com> Content-Type: multipart/alternative; boundary=20cf303ea02441ea6b049278ecca Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Opensource impl yet? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 05:31:42 -0000 --20cf303ea02441ea6b049278ecca Content-Type: text/plain; charset=ISO-8859-1 I haven't seen one. Have been trying to keep track of all the implementation on http://wiki.oauth.net/w/page/OAuth-2. On Tue, Oct 12, 2010 at 9:33 AM, William Mills <wmills@yahoo-inc.com> wrote: > Is there a C/C++ opensource implementation yet I can use for the > reference implementation of the SASL mechanism yet? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf303ea02441ea6b049278ecca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't seen one. Have been trying to keep track of all the implement= ation on=A0<a href=3D"http://wiki.oauth.net/w/page/OAuth-2">http://wiki.oau= th.net/w/page/OAuth-2</a>.<div><br><br><div class=3D"gmail_quote">On Tue, O= ct 12, 2010 at 9:33 AM, William Mills <span dir=3D"ltr"><<a href=3D"mail= to:wmills@yahoo-inc.com">wmills@yahoo-inc.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal">Is there a C/C++ opensource implementation yet I can= use for the reference implementation of the SASL mechanism yet?</p> </div> </div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --20cf303ea02441ea6b049278ecca-- From progrium@twilio.com Wed Oct 13 10:46:50 2010 Return-Path: <progrium@twilio.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE89B3A6A5B for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5nm1e3GfTma for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 10:46:48 -0700 (PDT) Received: from mail-ww0-f52.google.com (mail-ww0-f52.google.com [74.125.82.52]) by core3.amsl.com (Postfix) with ESMTP id B33723A69F5 for <oauth@ietf.org>; Wed, 13 Oct 2010 10:46:47 -0700 (PDT) Received: by wwi18 with SMTP id 18so4554825wwi.33 for <oauth@ietf.org>; Wed, 13 Oct 2010 10:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.37.8 with SMTP id v8mr8758450wbd.180.1286992084062; Wed, 13 Oct 2010 10:48:04 -0700 (PDT) Received: by 10.227.27.196 with HTTP; Wed, 13 Oct 2010 10:48:03 -0700 (PDT) In-Reply-To: <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> References: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> Date: Wed, 13 Oct 2010 10:48:03 -0700 Message-ID: <AANLkTinOpT=v8cFjmP0h-bnmRUxfOaOi5eQEhpszOJZA@mail.gmail.com> From: Jeff Lindsay <progrium@twilio.com> To: David Recordon <recordond@gmail.com> Content-Type: multipart/alternative; boundary=002215974c5affd1d80492833179 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Opensource impl yet? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 17:46:50 -0000 --002215974c5affd1d80492833179 Content-Type: text/plain; charset=ISO-8859-1 Don't have SASL yet, but probably worth putting on that page: http://github.com/progrium/oauth2-appengine Intended for learning purposes. -jeff On Tue, Oct 12, 2010 at 10:32 PM, David Recordon <recordond@gmail.com>wrote: > I haven't seen one. Have been trying to keep track of all the > implementation on http://wiki.oauth.net/w/page/OAuth-2. > > > On Tue, Oct 12, 2010 at 9:33 AM, William Mills <wmills@yahoo-inc.com>wrote: > >> Is there a C/C++ opensource implementation yet I can use for the >> reference implementation of the SASL mechanism yet? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --002215974c5affd1d80492833179 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Don't have SASL yet, but probably worth putting on that page:<div><a hr= ef=3D"http://github.com/progrium/oauth2-appengine">http://github.com/progri= um/oauth2-appengine</a></div><div><br></div><div>Intended for learning purp= oses.</div> <div><br></div><div>-jeff<br><br><div class=3D"gmail_quote">On Tue, Oct 12,= 2010 at 10:32 PM, David Recordon <span dir=3D"ltr"><<a href=3D"mailto:r= ecordond@gmail.com">recordond@gmail.com</a>></span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex;"> I haven't seen one. Have been trying to keep track of all the implement= ation on=A0<a href=3D"http://wiki.oauth.net/w/page/OAuth-2" target=3D"_blan= k">http://wiki.oauth.net/w/page/OAuth-2</a>.<div><br><br><div class=3D"gmai= l_quote"> <div class=3D"im">On Tue, Oct 12, 2010 at 9:33 AM, William Mills <span dir= =3D"ltr"><<a href=3D"mailto:wmills@yahoo-inc.com" target=3D"_blank">wmil= ls@yahoo-inc.com</a>></span> wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal">Is there a C/C++ opensource implementation yet I can= use for the reference implementation of the SASL mechanism yet?</p> </div> </div> <br></div>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --002215974c5affd1d80492833179-- From breno.demedeiros@gmail.com Wed Oct 13 11:30:14 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678AD3A69FB for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0YgSyIfYKbW for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 11:30:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0DA373A6A0B for <oauth@ietf.org>; Wed, 13 Oct 2010 11:30:11 -0700 (PDT) Received: by ywa6 with SMTP id 6so2440208ywa.31 for <oauth@ietf.org>; Wed, 13 Oct 2010 11:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=NoyHgn4hA2l4EL9wrM5noMklHWlfppCJjlQ/tD6ILGs=; b=NWL9jM4maM2DsLecGL5dY9WO6CkKwi+B4I5DkT7dr9qVi6JjA6hZmJ92JffWLc2Pe1 qsJLOaN8T1EYg0iEZQ3gdrGDbZPVYM2YFWtBLHo/4N1Q2aKq4QysNown+GLi0p7bC8yK 7ffZNY5TZdbOnJYPLJZXzKOARA0RLFClh20E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GXalrdyD/u5O18ZkGbsULKG8Kde+tSb9i371Qw8G20KPLFT8H07+uhxqHCK8WM2n2s k5sSW4CWIYXIo7GpeQNsuy91qQFxDqdVPm0A0yhPCLIO29WQU65Gt2dxlxNB1U5ljtal 3aje7qXz3zae8hevvqISIKLjdp0pvLhLsSsro= MIME-Version: 1.0 Received: by 10.42.215.71 with SMTP id hd7mr4694825icb.505.1286994688447; Wed, 13 Oct 2010 11:31:28 -0700 (PDT) Received: by 10.231.154.213 with HTTP; Wed, 13 Oct 2010 11:31:28 -0700 (PDT) Date: Wed, 13 Oct 2010 11:31:28 -0700 Message-ID: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 18:30:14 -0000 Suppose server A documents that their endpoint X is at https://server.example.com/x; there's no service at the corresponding http location for security reasons. Client developer fatfingers URL as http://server.example.com/x What is the correct response? I understand that this is out of scope for the spec, but maybe there's agreement on some guidance? One thing one shouldn't do is serve a 302 here; it would allow defective clients to remain unpatched. My preference is to simply return a bare 403 or 404 here -- after all the endpoint does not exist (404) or if one uses the convention that resources at http/https are usually identical, then http is a non-authorized method to access the resource (403). Thoughts? -- Breno de Medeiros From paul.tarjan@facebook.com Wed Oct 13 13:44:58 2010 Return-Path: <paul.tarjan@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238D43A69AB for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SpHT77MZjB for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:44:57 -0700 (PDT) Received: from mx-out.facebook.com (outmail007.snc4.facebook.com [66.220.144.139]) by core3.amsl.com (Postfix) with ESMTP id 31CEC3A698A for <oauth@ietf.org>; Wed, 13 Oct 2010 13:44:57 -0700 (PDT) Received: from [192.168.18.212] ([192.168.18.212:33440] helo=mail.thefacebook.com) by mta019.snc4.facebook.com (envelope-from <paul.tarjan@facebook.com>) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 01/7A-17412-09A16BC4; Wed, 13 Oct 2010 13:46:08 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.231]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 13 Oct 2010 13:46:08 -0700 From: Paul Tarjan <paul.tarjan@facebook.com> To: Breno <breno.demedeiros@gmail.com> Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: AQHLawTe+snTrHx/JUC4TZ4mTPil45M/zqCA Date: Wed, 13 Oct 2010 20:46:07 +0000 Message-ID: <2CF95A0F-D113-450D-8E1A-93944F1EAE77@facebook.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> In-Reply-To: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2CF95A0FD113450D8E1A93944F1EAE77facebookcom_" MIME-Version: 1.0 Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 20:44:58 -0000 --_000_2CF95A0FD113450D8E1A93944F1EAE77facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At Facebook we issue an HTTP 400 with "invalid_request" as the error. http://graph.facebook.com/me?access_token=3Dblah&client_id=3D15062924494816= 4 <http://graph.facebook.com/me?access_token=3Dblah&client_id=3D1506292449481= 64>(the client_id is to enable draft-10 error messaging). On Oct 13, 2010, at 11:31 AM, Breno wrote: Suppose server A documents that their endpoint X is at https://server.example.com/x; there's no service at the corresponding http location for security reasons. Client developer fatfingers URL as http://server.example.com/x What is the correct response? I understand that this is out of scope for the spec, but maybe there's agreement on some guidance? One thing one shouldn't do is serve a 302 here; it would allow defective clients to remain unpatched. My preference is to simply return a bare 403 or 404 here -- after all the endpoint does not exist (404) or if one uses the convention that resources at http/https are usually identical, then http is a non-authorized method to access the resource (403). Thoughts? -- Breno de Medeiros _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_2CF95A0FD113450D8E1A93944F1EAE77facebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <95c15aa0-adaf-4406-a471-121de61033bd> Content-Transfer-Encoding: quoted-printable <html><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= ></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -we= bkit-line-break: after-white-space; ">At Facebook we issue an HTTP 400 with= "invalid_request" as the error.<div><br></div><div><a href=3D"ht= tp://graph.facebook.com/me?access_token=3Dblah&client_id=3D150629244948= 164">http://graph.facebook.com/me?access_token=3Dblah&client_id=3D15062= 9244948164</a></div><div><br></div><div><a href=3D"http://graph.facebook.co= m/me?access_token=3Dblah&client_id=3D150629244948164"></a>(the client_i= d is to enable draft-10 error messaging).</div><div><br><div><div>On Oct 13= , 2010, at 11:31 AM, Breno wrote:</div><br class=3D"Apple-interchange-newli= ne"><blockquote type=3D"cite"><div>Suppose server A documents that their en= dpoint X is at<br><a href=3D"https://server.example.com/x">https://server.e= xample.com/x</a>; there's no service at the corresponding<br>http location = for security reasons.<br><br>Client developer fatfingers URL as <a href=3D"= http://server.example.com/x">http://server.example.com/x</a><br><br>What is= the correct response? I understand that this is out of scope<br>for the sp= ec, but maybe there's agreement on some guidance?<br><br>One thing one shou= ldn't do is serve a 302 here; it would allow<br>defective clients to remain= unpatched.<br><br>My preference is to simply return a bare 403 or 404 here= -- after all<br>the endpoint does not exist (404) or if one uses the conve= ntion that<br>resources at http/https are usually identical, then http is a= <br>non-authorized method to access the resource (403).<br><br>Thoughts?<br= ><br>-- <br>Breno de Medeiros<br>__________________________________________= _____<br>OAuth mailing list<br><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf= .org</a><br>https://www.ietf.org/mailman/listinfo/oauth<br></div></blockquo= te></div><br></div></body></html>= --_000_2CF95A0FD113450D8E1A93944F1EAE77facebookcom_-- From mscurtescu@google.com Wed Oct 13 13:54:29 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19813A69DF for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT9oC2+K0MAY for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:54:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 573833A69C1 for <oauth@ietf.org>; Wed, 13 Oct 2010 13:54:28 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o9DKtiWD021581 for <oauth@ietf.org>; Wed, 13 Oct 2010 13:55:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287003345; bh=Xyz1pkKAV9gth2GI/O+ylsQW/ec=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=btmSr55DD4jM1yCrfB8HjEVlAztqF9FjTH1y3A/dBMfd+EIjZVL60EL9yGGUtyo/k 7xFfZIBIPnhOur2YivpqA== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by kpbe18.cbf.corp.google.com with ESMTP id o9DKskAo023107 for <oauth@ietf.org>; Wed, 13 Oct 2010 13:55:43 -0700 Received: by gyd10 with SMTP id 10so2340947gyd.28 for <oauth@ietf.org>; Wed, 13 Oct 2010 13:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=IQsyvQZH1yw1Se6mGe2H1p0Y09uIpKzMzCmFYdW5UPU=; b=FMX+kC/Tb/sshRkiKTrN4XeUoV81oYz/AM1qN+qCNG22WBjpYFtd9Ef80H5HxUSLqL y5nTT48VTLnL9qObenoQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ppD5it01L4+qBiBDOALrve9e3VIunb9jjzwx7fvUTTCMiaaWm1gLwVRne/6/vZslHM cU2WPTRx0Shoc+qgisiA== Received: by 10.100.134.13 with SMTP id h13mr5295141and.36.1287003343401; Wed, 13 Oct 2010 13:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.123.19 with HTTP; Wed, 13 Oct 2010 13:55:23 -0700 (PDT) In-Reply-To: <2CF95A0F-D113-450D-8E1A-93944F1EAE77@facebook.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <2CF95A0F-D113-450D-8E1A-93944F1EAE77@facebook.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 13 Oct 2010 13:55:23 -0700 Message-ID: <AANLkTinPPTg0zCzwLB4h=14FcAyKPbY1Mxzhfi+1zPrh@mail.gmail.com> To: Paul Tarjan <paul.tarjan@facebook.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 20:54:29 -0000 On Wed, Oct 13, 2010 at 1:46 PM, Paul Tarjan <paul.tarjan@facebook.com> wrote: > At Facebook we issue an HTTP 400 with "invalid_request" as the error. > http://graph.facebook.com/me?access_token=blah&client_id=150629244948164 > (the client_id is to enable draft-10 error messaging). Without client_id you get a different error message (JSON as well, but not OAuth2 compliant). Why do you need this parameter to make the distinction? Marius From paul.tarjan@facebook.com Wed Oct 13 13:59:26 2010 Return-Path: <paul.tarjan@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AA83A69C1 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhpZxoO54BuI for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 13:59:25 -0700 (PDT) Received: from mx-out.facebook.com (outmail009.snc4.facebook.com [66.220.144.141]) by core3.amsl.com (Postfix) with ESMTP id 2C7F63A696C for <oauth@ietf.org>; Wed, 13 Oct 2010 13:59:25 -0700 (PDT) Received: from [192.168.18.212] ([192.168.18.212:12967] helo=mail.thefacebook.com) by mta007.snc4.facebook.com (envelope-from <paul.tarjan@facebook.com>) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id BA/67-26490-4FD16BC4; Wed, 13 Oct 2010 14:00:36 -0700 Received: from SC-MBX04.TheFacebook.com ([169.254.3.231]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 13 Oct 2010 14:00:36 -0700 From: Paul Tarjan <paul.tarjan@facebook.com> To: Marius Scurtescu <mscurtescu@google.com> Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: AQHLawTe+snTrHx/JUC4TZ4mTPil45M/zqCAgAACl4CAAAFzAA== Date: Wed, 13 Oct 2010 21:00:34 +0000 Message-ID: <B5861468-C397-44C9-BF09-B0AE65592AF1@facebook.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <2CF95A0F-D113-450D-8E1A-93944F1EAE77@facebook.com> <AANLkTinPPTg0zCzwLB4h=14FcAyKPbY1Mxzhfi+1zPrh@mail.gmail.com> In-Reply-To: <AANLkTinPPTg0zCzwLB4h=14FcAyKPbY1Mxzhfi+1zPrh@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <62c3ff39-9ec9-4074-9158-7186886564d4> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 20:59:26 -0000 >=20 >> At Facebook we issue an HTTP 400 with "invalid_request" as the error. >> http://graph.facebook.com/me?access_token=3Dblah&client_id=3D15062924494= 8164 >> (the client_id is to enable draft-10 error messaging). >=20 > Without client_id you get a different error message (JSON as well, but > not OAuth2 compliant). Why do you need this parameter to make the > distinction? Backwards compatibility. When we shipped, OAuth2 was at draft 00 and there = was no standard error mechanism. So we invented one that isn't compatible w= ith the current error codes (our key "error" was an array, and the current = one is a "string" so we can't just send both). When the spec finalizes, we'll do a single migration and change the default= to be the final format (and all other non-backwards compatible changes). Paul= From mscurtescu@google.com Wed Oct 13 14:54:50 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771A53A69DF for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 14:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kabnS2ndzkBL for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 14:54:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1CBC73A69CE for <oauth@ietf.org>; Wed, 13 Oct 2010 14:54:49 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o9DLu5me031994 for <oauth@ietf.org>; Wed, 13 Oct 2010 14:56:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287006966; bh=jDQo2uJa4VYvMZVEVByuguWPnqc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=UAzsZ43Gj18eGFop4C7iSUQ+39U8rRlA5+j8Gge5RX7eRd4i34kk8z2NiGcwY3b9X 1RZOYWPFI92DwiaHOdq6A== Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by hpaq5.eem.corp.google.com with ESMTP id o9DLu3HT029695 for <oauth@ietf.org>; Wed, 13 Oct 2010 14:56:04 -0700 Received: by gyh20 with SMTP id 20so2473483gyh.2 for <oauth@ietf.org>; Wed, 13 Oct 2010 14:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0qRXdnWmbPH7AFrG9xa+VIGpcG8jQG4Lgim7n1AN6r4=; b=FeyKE1Iklgi5dhvCAo29XpIDnGVLDP7TKbjBpomfhF5Z7JVa4wgYboouAi0xuPwDOm brzFdma3g2Qbc3B3O/Hw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=QZ2158anXd6ksXnuilCqlGlcIsD8t4w3UmajQIC3C57BKc1529gc1J6ZFsBK3IpJCf 8GLfMpIufnHFiZ+A9bwA== Received: by 10.150.134.11 with SMTP id h11mr1905882ybd.193.1287006963539; Wed, 13 Oct 2010 14:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.123.19 with HTTP; Wed, 13 Oct 2010 14:55:43 -0700 (PDT) In-Reply-To: <B5861468-C397-44C9-BF09-B0AE65592AF1@facebook.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <2CF95A0F-D113-450D-8E1A-93944F1EAE77@facebook.com> <AANLkTinPPTg0zCzwLB4h=14FcAyKPbY1Mxzhfi+1zPrh@mail.gmail.com> <B5861468-C397-44C9-BF09-B0AE65592AF1@facebook.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 13 Oct 2010 14:55:43 -0700 Message-ID: <AANLkTi=X1gSdNoc_SQRd4AMwkmEy4Zh11H5vyjSw6LeY@mail.gmail.com> To: Paul Tarjan <paul.tarjan@facebook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 21:54:50 -0000 On Wed, Oct 13, 2010 at 2:00 PM, Paul Tarjan <paul.tarjan@facebook.com> wro= te: >> >>> At Facebook we issue an HTTP 400 with "invalid_request" as the error. >>> http://graph.facebook.com/me?access_token=3Dblah&client_id=3D1506292449= 48164 >>> (the client_id is to enable draft-10 error messaging). >> >> Without client_id you get a different error message (JSON as well, but >> not OAuth2 compliant). Why do you need this parameter to make the >> distinction? > > Backwards compatibility. When we shipped, OAuth2 was at draft 00 and ther= e was no standard error mechanism. So we invented one that isn't compatible= with the current error codes (our key "error" was an array, and the curren= t one is a "string" so we can't just send both). > > When the spec finalizes, we'll do a single migration and change the defau= lt to be the final format (and all other non-backwards compatible changes). Got it, thanks. Marius From eran@hueniverse.com Wed Oct 13 15:56:59 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685993A6A6C for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 15:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELgV8eXYuNYW for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 15:56:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6F3953A6A63 for <oauth@ietf.org>; Wed, 13 Oct 2010 15:56:57 -0700 (PDT) Received: (qmail 7987 invoked from network); 13 Oct 2010 22:58:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Oct 2010 22:58:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 13 Oct 2010 15:58:01 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Breno <breno.demedeiros@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 13 Oct 2010 15:57:47 -0700 Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: ActrBN87mYxWqMOsSj2rKzKxJcarKQAJRv9A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> In-Reply-To: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 22:56:59 -0000 Hopefully you also invalidate the token (if bearer) since it was send over = an insecure channel. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Breno > Sent: Wednesday, October 13, 2010 11:31 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Request sent to http: instead of https:` >=20 > Suppose server A documents that their endpoint X is at > https://server.example.com/x; there's no service at the corresponding htt= p > location for security reasons. >=20 > Client developer fatfingers URL as http://server.example.com/x >=20 > What is the correct response? I understand that this is out of scope for = the > spec, but maybe there's agreement on some guidance? >=20 > One thing one shouldn't do is serve a 302 here; it would allow defective > clients to remain unpatched. >=20 > My preference is to simply return a bare 403 or 404 here -- after all the > endpoint does not exist (404) or if one uses the convention that resource= s at > http/https are usually identical, then http is a non-authorized method to > access the resource (403). >=20 > Thoughts? >=20 > -- > Breno de Medeiros > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From progrium@twilio.com Wed Oct 13 16:11:19 2010 Return-Path: <progrium@twilio.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFE13A6A75 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 16:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D03ztbhVkyOO for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 16:11:16 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 36CFE3A6A6A for <oauth@ietf.org>; Wed, 13 Oct 2010 16:11:16 -0700 (PDT) Received: by wwj40 with SMTP id 40so4788587wwj.13 for <oauth@ietf.org>; Wed, 13 Oct 2010 16:12:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.208 with SMTP id e16mr8907112wbv.164.1287011551901; Wed, 13 Oct 2010 16:12:31 -0700 (PDT) Received: by 10.227.27.196 with HTTP; Wed, 13 Oct 2010 16:12:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 13 Oct 2010 16:12:31 -0700 Message-ID: <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> From: Jeff Lindsay <progrium@twilio.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=0016367f9a0e5f7a43049287badd Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 23:11:19 -0000 --0016367f9a0e5f7a43049287badd Content-Type: text/plain; charset=ISO-8859-1 > > Hopefully you also invalidate the token (if bearer) since it was send over > an insecure channel. > Excuse my naivety, but perhaps that's worth putting in the spec? > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Breno > > Sent: Wednesday, October 13, 2010 11:31 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Request sent to http: instead of https:` > > > > Suppose server A documents that their endpoint X is at > > https://server.example.com/x; there's no service at the corresponding > http > > location for security reasons. > > > > Client developer fatfingers URL as http://server.example.com/x > > > > What is the correct response? I understand that this is out of scope for > the > > spec, but maybe there's agreement on some guidance? > > > > One thing one shouldn't do is serve a 302 here; it would allow defective > > clients to remain unpatched. > > > > My preference is to simply return a bare 403 or 404 here -- after all the > > endpoint does not exist (404) or if one uses the convention that > resources at > > http/https are usually identical, then http is a non-authorized method to > > access the resource (403). > > > > Thoughts? > > > > -- > > Breno de Medeiros > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016367f9a0e5f7a43049287badd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hopefully you al= so invalidate the token (if bearer) since it was send over an insecure chan= nel.<br> </blockquote><div><br></div><div>Excuse my naivety, but perhaps that's = worth putting in the spec?</div><div><br></div><div>=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex;"> <font color=3D"#888888"><br> EHL<br> </font><div><div></div><div class=3D"h5"><br> > -----Original Message-----<br> > From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org= </a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.o= rg</a>] On Behalf<br> > Of Breno<br> > Sent: Wednesday, October 13, 2010 11:31 AM<br> > To: <a href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a><br> > Subject: [OAUTH-WG] Request sent to http: instead of https:`<br> ><br> > Suppose server A documents that their endpoint X is at<br> > <a href=3D"https://server.example.com/x" target=3D"_blank">https://ser= ver.example.com/x</a>; there's no service at the corresponding http<br> > location for security reasons.<br> ><br> > Client developer fatfingers URL as <a href=3D"http://server.example.co= m/x" target=3D"_blank">http://server.example.com/x</a><br> ><br> > What is the correct response? I understand that this is out of scope f= or the<br> > spec, but maybe there's agreement on some guidance?<br> ><br> > One thing one shouldn't do is serve a 302 here; it would allow def= ective<br> > clients to remain unpatched.<br> ><br> > My preference is to simply return a bare 403 or 404 here -- after all = the<br> > endpoint does not exist (404) or if one uses the convention that resou= rces at<br> > http/https are usually identical, then http is a non-authorized method= to<br> > access the resource (403).<br> ><br> > Thoughts?<br> ><br> > --<br> > Breno de Medeiros<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br> --0016367f9a0e5f7a43049287badd-- From breno.demedeiros@gmail.com Wed Oct 13 16:47:25 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E7F3A6A95 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 16:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44SLR874yE1v for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 16:47:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1E0E33A6A75 for <oauth@ietf.org>; Wed, 13 Oct 2010 16:47:24 -0700 (PDT) Received: by iwn10 with SMTP id 10so8580424iwn.31 for <oauth@ietf.org>; Wed, 13 Oct 2010 16:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=X0I0tEEITV3/+RMvShclQRBhOVjU+OeNAU9biL7QSo8=; b=jirv1wue9PL4kq024O4iVnP6RPFVm/UwEcW7rli/lmIFZrNSk15ybBonNI+DgRnukR rsKhlbFhH6Q/ZEL/CcI6Y+juS2VzQL7lhp8beJRovIxKQ8RoNw9E5jcbOx+Y6UFtyGuE 2K1lTGvX80itSNqXwFlperV8TlbFcvUS6ExR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HVc7WMu7F+PPZO7R2eaQ0xXSuBBZ9KcGG3TR8sltM8KpHi+vU+w5JBdVW9dpaHHZ+J DXx0qJ1wf63dfr+wrOo8fTJOPeZjR1pCdpkuWMovJPE5qOkyfTJ/TAxLZsPQZ90MGU2v kYeG/gUn8mcshmHPLsDu1v1MDmP85vaU/+bqM= MIME-Version: 1.0 Received: by 10.42.142.198 with SMTP id t6mr1083202icu.293.1287013721565; Wed, 13 Oct 2010 16:48:41 -0700 (PDT) Received: by 10.231.154.213 with HTTP; Wed, 13 Oct 2010 16:48:41 -0700 (PDT) In-Reply-To: <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> Date: Wed, 13 Oct 2010 16:48:41 -0700 Message-ID: <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Jeff Lindsay <progrium@twilio.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Oct 2010 23:47:25 -0000 +1 for language in the spec describing how to handle this case On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> wrote: >> Hopefully you also invalidate the token (if bearer) since it was send over >> an insecure channel. > > Excuse my naivety, but perhaps that's worth putting in the spec? > >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Breno >> > Sent: Wednesday, October 13, 2010 11:31 AM >> > To: oauth@ietf.org >> > Subject: [OAUTH-WG] Request sent to http: instead of https:` >> > >> > Suppose server A documents that their endpoint X is at >> > https://server.example.com/x; there's no service at the corresponding >> > http >> > location for security reasons. >> > >> > Client developer fatfingers URL as http://server.example.com/x >> > >> > What is the correct response? I understand that this is out of scope for >> > the >> > spec, but maybe there's agreement on some guidance? >> > >> > One thing one shouldn't do is serve a 302 here; it would allow defective >> > clients to remain unpatched. >> > >> > My preference is to simply return a bare 403 or 404 here -- after all >> > the >> > endpoint does not exist (404) or if one uses the convention that >> > resources at >> > http/https are usually identical, then http is a non-authorized method >> > to >> > access the resource (403). >> > >> > Thoughts? >> > >> > -- >> > Breno de Medeiros >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- Breno de Medeiros From wmills@yahoo-inc.com Wed Oct 13 17:04:02 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC0F3A69EF for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.494 X-Spam-Level: X-Spam-Status: No, score=-17.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5WCTUatcX2 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:04:02 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 3963C3A69B0 for <oauth@ietf.org>; Wed, 13 Oct 2010 17:04:02 -0700 (PDT) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o9E04qkO023799; Wed, 13 Oct 2010 17:04:52 -0700 (PDT) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Wed, 13 Oct 2010 17:04:52 -0700 From: William Mills <wmills@yahoo-inc.com> To: Breno <breno.demedeiros@gmail.com>, Jeff Lindsay <progrium@twilio.com> Date: Wed, 13 Oct 2010 17:04:51 -0700 Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: ActrMWEod6MO6T69RqetfsTo6OBRuwAAdZmA Message-ID: <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> In-Reply-To: <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 00:04:03 -0000 This rather implies that we're specifying running a full server on port 80 = as a "stupid detector". We should tread carefully here. > +1 for language in the spec describing how to handle this case >=20 > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> > wrote: > >> Hopefully you also invalidate the token (if bearer) since it was > send over > >> an insecure channel. > > > > Excuse my naivety, but perhaps that's worth putting in the spec? From progrium@twilio.com Wed Oct 13 17:24:02 2010 Return-Path: <progrium@twilio.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF1B3A6A6F for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ur5HEiAVRPW for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:24:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BB08B3A686B for <oauth@ietf.org>; Wed, 13 Oct 2010 17:24:01 -0700 (PDT) Received: by wwj40 with SMTP id 40so4822607wwj.13 for <oauth@ietf.org>; Wed, 13 Oct 2010 17:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.133.69 with SMTP id e5mr9434766wbt.51.1287015918659; Wed, 13 Oct 2010 17:25:18 -0700 (PDT) Received: by 10.227.27.196 with HTTP; Wed, 13 Oct 2010 17:25:18 -0700 (PDT) In-Reply-To: <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> Date: Wed, 13 Oct 2010 17:25:18 -0700 Message-ID: <AANLkTi=wXFR6uqkg8YPCJnV1_Q30e6UCw6EoQknFSoVQ@mail.gmail.com> From: Jeff Lindsay <progrium@twilio.com> To: William Mills <wmills@yahoo-inc.com> Content-Type: multipart/alternative; boundary=001485f77656a6e9a3049288be1b Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 00:24:02 -0000 --001485f77656a6e9a3049288be1b Content-Type: text/plain; charset=ISO-8859-1 > > This rather implies that we're specifying running a full server on port 80 > as a "stupid detector". We should tread carefully here. > Right, I suppose you're better off not responding on port 80 if possible. But I imagine this could be phrased in Section 5.0 roughly, "if the resource server is available over an insecure channel, but does not honor insecure requests to protected resources, it SHOULD/MUST respond to insecure requests by invalidating the token and returning an invalid_request error." > > > +1 for language in the spec describing how to handle this case > > > > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> > > wrote: > > >> Hopefully you also invalidate the token (if bearer) since it was > > send over > > >> an insecure channel. > > > > > > Excuse my naivety, but perhaps that's worth putting in the spec? > --001485f77656a6e9a3049288be1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This rather impl= ies that we're specifying running a full server on port 80 as a "s= tupid detector". =A0We should tread carefully here.<br> </blockquote><div><br></div><div>Right, I suppose you're better off not= responding on port 80 if possible. But I imagine this could be phrased in = Section 5.0 roughly, "if the resource server is available over an inse= cure channel, but does not honor insecure requests to protected resources, = it SHOULD/MUST respond to insecure requests by invalidating the token and r= eturning an invalid_request error."</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5"><br> > +1 for language in the spec describing how to handle this case<br> ><br> > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <<a href=3D"mailto:pr= ogrium@twilio.com">progrium@twilio.com</a>><br> > wrote:<br> > >> Hopefully you also invalidate the token (if bearer) since it = was<br> > send over<br> > >> an insecure channel.<br> > ><br> > > Excuse my naivety, but perhaps that's worth putting in the sp= ec?<br> </div></div></blockquote></div><br> --001485f77656a6e9a3049288be1b-- From romeda@gmail.com Wed Oct 13 17:32:09 2010 Return-Path: <romeda@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87043A6A88 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL3S7KvjNUxV for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 17:31:45 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A01B23A6A3C for <oauth@ietf.org>; Wed, 13 Oct 2010 17:31:24 -0700 (PDT) Received: by qwc9 with SMTP id 9so3512175qwc.31 for <oauth@ietf.org>; Wed, 13 Oct 2010 17:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=7VR0ryMbhHO9kWC4qbAvnvN0lQ2dtQTUP3uRR3uYCvU=; b=DHQsGUkSX1FE0hIzV4MbB4oWsKk20qhC7EyMOqsGm3JFOnGVsgIo4hhO34ZqcjsJrh 8wyOxUORC/fd43/eOAn/PEgqNEr9JQrjl9683uWm6KclWjVgxeq7peowDw7tbDoxdH6L 59ydZw8iinzbhT+rUkxfqMRTou4+YJO7Ye+ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=liHF1HBVi7WgQU3AWiYJo/jha9DDXhX992Vbs7i/Yww9wGqJC2GbymiW7GnTgd/4lb bt+2ShKQ1eVI6cI6p/KnsjBoIRUw61AoZadfVAuafijS2fSOJwRQPh1WyuEva0I2TcK1 FhPxiTKG5FP1Bfhs4rSvP9B2GGG1keNRWXPWE= Received: by 10.229.241.12 with SMTP id lc12mr8148216qcb.178.1287016360424; Wed, 13 Oct 2010 17:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.97 with HTTP; Wed, 13 Oct 2010 17:32:20 -0700 (PDT) From: Blaine Cook <romeda@gmail.com> Date: Wed, 13 Oct 2010 17:32:20 -0700 Message-ID: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 00:32:10 -0000 Over the past few weeks, the working group debated the issues around the introduction of signatures and the structure of the specification. The working group seems to endorse the proposal to split the current specification into two parts: one including section 5 (bearer token) and the other including the rest (how to obtain a token), with an additional specification covering signature use cases. This serves as a call for consensus on the proposed editorial work. Before we proceed with the changes, the chairs would like to ask if anyone has any concerns or objections against this proposal. In addition, the chairs are seeking a volunteer to take over the bearer token specification (section 5) as editor. Please submit your comments by Wednesday, October 20th. - The OAuth Working Group Chairs From eran@hueniverse.com Wed Oct 13 18:33:23 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D0A3A6A8C for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY9smTDqrBNE for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 18:32:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 1D6743A6A83 for <oauth@ietf.org>; Wed, 13 Oct 2010 18:32:45 -0700 (PDT) Received: (qmail 28385 invoked from network); 14 Oct 2010 01:33:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Oct 2010 01:33:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 13 Oct 2010 18:33:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: William Mills <wmills@yahoo-inc.com>, Breno <breno.demedeiros@gmail.com>, Jeff Lindsay <progrium@twilio.com> Date: Wed, 13 Oct 2010 18:33:19 -0700 Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: ActrMWEod6MO6T69RqetfsTo6OBRuwAAdZmAAAMfSnA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4691FADB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> In-Reply-To: <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 01:33:25 -0000 I don't think so. If you are not running a server on port 80, the connectio= n will never happen and nothing bad will be send on the wire. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, October 13, 2010 5:05 PM > To: Breno; Jeff Lindsay > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` >=20 > This rather implies that we're specifying running a full server on port 8= 0 as a > "stupid detector". We should tread carefully here. >=20 > > +1 for language in the spec describing how to handle this case > > > > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> > > wrote: > > >> Hopefully you also invalidate the token (if bearer) since it was > > send over > > >> an insecure channel. > > > > > > Excuse my naivety, but perhaps that's worth putting in the spec? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Oct 13 18:33:38 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A503A6AA5 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 18:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eljfd+1xLPlw for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 18:33:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 45C793A6A6B for <oauth@ietf.org>; Wed, 13 Oct 2010 18:32:47 -0700 (PDT) Received: (qmail 28761 invoked from network); 14 Oct 2010 01:33:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Oct 2010 01:33:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 13 Oct 2010 18:33:53 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Breno <breno.demedeiros@gmail.com>, Jeff Lindsay <progrium@twilio.com> Date: Wed, 13 Oct 2010 18:33:39 -0700 Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: ActrMSsdNhceKTtrRBG1WbXQp3Q1QAADqFmA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4691FADC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> In-Reply-To: <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 01:33:38 -0000 Write it, and I'll get it incorporated. EHL > -----Original Message----- > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Wednesday, October 13, 2010 4:49 PM > To: Jeff Lindsay > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` >=20 > +1 for language in the spec describing how to handle this case >=20 > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> wrote= : > >> Hopefully you also invalidate the token (if bearer) since it was send > >> over an insecure channel. > > > > Excuse my naivety, but perhaps that's worth putting in the spec? > > > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > Behalf Of Breno > >> > Sent: Wednesday, October 13, 2010 11:31 AM > >> > To: oauth@ietf.org > >> > Subject: [OAUTH-WG] Request sent to http: instead of https:` > >> > > >> > Suppose server A documents that their endpoint X is at > >> > https://server.example.com/x; there's no service at the > >> > corresponding http location for security reasons. > >> > > >> > Client developer fatfingers URL as http://server.example.com/x > >> > > >> > What is the correct response? I understand that this is out of > >> > scope for the spec, but maybe there's agreement on some guidance? > >> > > >> > One thing one shouldn't do is serve a 302 here; it would allow > >> > defective clients to remain unpatched. > >> > > >> > My preference is to simply return a bare 403 or 404 here -- after > >> > all the endpoint does not exist (404) or if one uses the convention > >> > that resources at http/https are usually identical, then http is a > >> > non-authorized method to access the resource (403). > >> > > >> > Thoughts? > >> > > >> > -- > >> > Breno de Medeiros > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > >=20 >=20 >=20 > -- > Breno de Medeiros From lshepard@facebook.com Wed Oct 13 19:54:10 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912D13A68A9 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 19:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZhLnzlLbP5h for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 19:54:09 -0700 (PDT) Received: from mx-out.facebook.com (outmail006.snc1.tfbnw.net [69.63.178.165]) by core3.amsl.com (Postfix) with ESMTP id E7F403A685B for <oauth@ietf.org>; Wed, 13 Oct 2010 19:54:08 -0700 (PDT) Received: from [10.18.255.126] ([10.18.255.126:20491] helo=mail.thefacebook.com) by mta003.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 76/B9-26397-E1176BC4; Wed, 13 Oct 2010 19:55:27 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.4]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 13 Oct 2010 19:55:26 -0700 From: Luke Shepard <lshepard@facebook.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:` Thread-Index: AQHLawTgfxKHb6TwOkqWAIorOXsBIJM/82qAgAAEHYCAAAobgIAAHVSAgAAW2IA= Date: Thu, 14 Oct 2010 02:55:25 +0000 Message-ID: <88E45490-742E-466F-B707-4D06680A2B4C@facebook.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FADC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4691FADC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <b96771cc-93f1-433e-975d-77036eb17d35> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 02:54:10 -0000 In our architecture, revoking the specific token would mean revoking access= to the app, which is something we don't want to do. We just return an error message but do not invalidate the token. I think th= at this is fine. Since it doesn't work, it will only be encountered in deve= lopment. On Oct 13, 2010, at 6:33 PM, Eran Hammer-Lahav wrote: > Write it, and I'll get it incorporated. >=20 > EHL >=20 >> -----Original Message----- >> From: Breno [mailto:breno.demedeiros@gmail.com] >> Sent: Wednesday, October 13, 2010 4:49 PM >> To: Jeff Lindsay >> Cc: Eran Hammer-Lahav; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` >>=20 >> +1 for language in the spec describing how to handle this case >>=20 >> On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> wrot= e: >>>> Hopefully you also invalidate the token (if bearer) since it was send >>>> over an insecure channel. >>>=20 >>> Excuse my naivety, but perhaps that's worth putting in the spec? >>>=20 >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of Breno >>>>> Sent: Wednesday, October 13, 2010 11:31 AM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] Request sent to http: instead of https:` >>>>>=20 >>>>> Suppose server A documents that their endpoint X is at >>>>> https://server.example.com/x; there's no service at the >>>>> corresponding http location for security reasons. >>>>>=20 >>>>> Client developer fatfingers URL as http://server.example.com/x >>>>>=20 >>>>> What is the correct response? I understand that this is out of >>>>> scope for the spec, but maybe there's agreement on some guidance? >>>>>=20 >>>>> One thing one shouldn't do is serve a 302 here; it would allow >>>>> defective clients to remain unpatched. >>>>>=20 >>>>> My preference is to simply return a bare 403 or 404 here -- after >>>>> all the endpoint does not exist (404) or if one uses the convention >>>>> that resources at http/https are usually identical, then http is a >>>>> non-authorized method to access the resource (403). >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> -- >>>>> Breno de Medeiros >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> Breno de Medeiros > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From breno.demedeiros@gmail.com Wed Oct 13 20:41:37 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF783A68A9 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 20:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-NGRyux2Dvv for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 20:41:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 31C323A6863 for <oauth@ietf.org>; Wed, 13 Oct 2010 20:41:36 -0700 (PDT) Received: by iwn10 with SMTP id 10so8881006iwn.31 for <oauth@ietf.org>; Wed, 13 Oct 2010 20:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bVFi0ArLoGf3RZZAY85siL//z9HPkQYfERMKddY8AMc=; b=A1NJBP21Sh4a7pxdAQDGYd6sMEF5/LA75vjj2LXpwpUCPFbyR4OYgLFnPCSPoNxwQS VnbCwnswTYKOtEGdEV6QLwig1jSxHeFUY9R40MSwM2MjbYN4Axu99W1nn8MRKuEYSFFB Ib+RBEHFfMYV8Th0f2O+b4dzYAgC2/48Ba3CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=u4L4ee5I20vS+10pd6scunc3u8JBOu+38UeuJG7Ec1tHWQgQPZ+VDNG+e83xHSPmD9 U1lPu3Tjc3XCBAVSG2/OHQMZb7/bUKHA1ih+vRyxm6wfD4KHB+Ug1YzTSQiXSn07pz4y n0J+yeAWdYOIpuER2Pjxu5HQE7cyct1ugLOZI= MIME-Version: 1.0 Received: by 10.231.33.129 with SMTP id h1mr7104512ibd.140.1287027772627; Wed, 13 Oct 2010 20:42:52 -0700 (PDT) Received: by 10.231.154.213 with HTTP; Wed, 13 Oct 2010 20:42:52 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4691FADB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FADB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 13 Oct 2010 20:42:52 -0700 Message-ID: <AANLkTi=1wzU6ARvhf3XVP-ZK+rmRF5LAH-YzAYULg82m@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 03:41:37 -0000 Or a connection to evil will happen. On Wed, Oct 13, 2010 at 6:33 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > I don't think so. If you are not running a server on port 80, the connect= ion will never happen and nothing bad will be send on the wire. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of William Mills >> Sent: Wednesday, October 13, 2010 5:05 PM >> To: Breno; Jeff Lindsay >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` >> >> This rather implies that we're specifying running a full server on port = 80 as a >> "stupid detector". =A0We should tread carefully here. >> >> > +1 for language in the spec describing how to handle this case >> > >> > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> >> > wrote: >> > >> Hopefully you also invalidate the token (if bearer) since it was >> > send over >> > >> an insecure channel. >> > > >> > > Excuse my naivety, but perhaps that's worth putting in the spec? >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Breno de Medeiros From jpanzer@google.com Wed Oct 13 23:02:03 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A91D3A6AC4 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.894 X-Spam-Level: X-Spam-Status: No, score=-105.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVxoR5ujXtra for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 22:59:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AEA6B3A6AAE for <oauth@ietf.org>; Wed, 13 Oct 2010 22:59:35 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o9E60rsN032457 for <oauth@ietf.org>; Wed, 13 Oct 2010 23:00:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287036053; bh=0tOcoCfLaTlRDdd/XRLvpA5fRn0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=e3fT6BPiYnc040Draak9zj8sievmBA1Yb23U/3jrZQj2j9mTnLIwBbBTQLIRRDclP 5xo56ZxBw3FkhqRhYXLbA== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by wpaz17.hot.corp.google.com with ESMTP id o9E60blc015556 for <oauth@ietf.org>; Wed, 13 Oct 2010 23:00:52 -0700 Received: by gxk7 with SMTP id 7so1391425gxk.36 for <oauth@ietf.org>; Wed, 13 Oct 2010 23:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e5k61ew42Z1rKc2P4Y9FgdRvbuPmnMPdiOsHhUCdHpE=; b=JkIw3C99wEajbssMLl2W25nMNss2msroAW29cWNPc+MTLs3rvatsaSuW0E8rqmDwps xi3sXr/E6LdWXXNS8FbQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mY1ibEan+myIxb/yPyIVnQHHxtqjEOHkRe2sf6suIAOAhpWwKvw6sjaluvGB9US4f3 dfLaOg8csSvI7cWRF7VQ== MIME-Version: 1.0 Received: by 10.100.136.7 with SMTP id j7mr3756772and.64.1287036051040; Wed, 13 Oct 2010 23:00:51 -0700 (PDT) Received: by 10.100.223.2 with HTTP; Wed, 13 Oct 2010 23:00:50 -0700 (PDT) In-Reply-To: <AANLkTi=1wzU6ARvhf3XVP-ZK+rmRF5LAH-YzAYULg82m@mail.gmail.com> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A3156254C4A752A@SP2-EX07VS06.ds.corp.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FADB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTi=1wzU6ARvhf3XVP-ZK+rmRF5LAH-YzAYULg82m@mail.gmail.com> Date: Wed, 13 Oct 2010 23:00:50 -0700 Message-ID: <AANLkTimsn_5DXd+cHZj+3BYoeVwOKAYCx92ze7Un1Vcm@mail.gmail.com> From: John Panzer <jpanzer@google.com> To: Breno <breno.demedeiros@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 06:02:05 -0000 In which case, nothing the legit server does can help that client. Since they're talking to the evil. On Wednesday, October 13, 2010, Breno <breno.demedeiros@gmail.com> wrote: > Or a connection to evil will happen. > > On Wed, Oct 13, 2010 at 6:33 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote: >> I don't think so. If you are not running a server on port 80, the connec= tion will never happen and nothing bad will be send on the wire. >> >> EHL >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of William Mills >>> Sent: Wednesday, October 13, 2010 5:05 PM >>> To: Breno; Jeff Lindsay >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` >>> >>> This rather implies that we're specifying running a full server on port= 80 as a >>> "stupid detector". =A0We should tread carefully here. >>> >>> > +1 for language in the spec describing how to handle this case >>> > >>> > On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> >>> > wrote: >>> > >> Hopefully you also invalidate the token (if bearer) since it was >>> > send over >>> > >> an insecure channel. >>> > > >>> > > Excuse my naivety, but perhaps that's worth putting in the spec? >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Breno de Medeiros > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From Michael.Jones@microsoft.com Thu Oct 14 00:05:23 2010 Return-Path: <Michael.Jones@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD553A6822 for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 00:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk2KPZfGDBfu for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 00:05:22 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 887D53A6868 for <oauth@ietf.org>; Thu, 14 Oct 2010 00:05:22 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Oct 2010 00:06:40 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.8]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0218.012; Thu, 14 Oct 2010 00:06:40 -0700 From: Mike Jones <Michael.Jones@microsoft.com> To: Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NABU8g Date: Thu, 14 Oct 2010 07:06:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> In-Reply-To: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 07:05:23 -0000 I am willing to serve as editor for the bearer token specification and have= my management's approval to do so. Furthermore, I believe that I am quali= fied, having successfully served as an editor for several standards specifi= cations, including the OASIS IMI specification and related SAML token profi= les, the OpenID PAPE specification, and (some time ago), the POSIX Threads = standard. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= laine Cook Sent: Wednesday, October 13, 2010 5:32 PM To: oauth@ietf.org Subject: [OAUTH-WG] Call for Consensus on Document Split Over the past few weeks, the working group debated the issues around the in= troduction of signatures and the structure of the specification. The working group seems to endorse the proposal to split the current specif= ication into two parts: one including section 5 (bearer token) and the othe= r including the rest (how to obtain a token), with an additional specificat= ion covering signature use cases. This serves as a call for consensus on the proposed editorial work. Before we proceed with the changes, the chairs would like to ask if anyone = has any concerns or objections against this proposal. In addition, the chairs are seeking a volunteer to take over the bearer tok= en specification (section 5) as editor. Please submit your comments by Wednesday, October 20th. - The OAuth Working Group Chairs _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From lr@lukasrosenstock.net Thu Oct 14 01:21:00 2010 Return-Path: <lr@lukasrosenstock.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978E13A681E for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 01:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw6KjMPWiFGu for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 01:20:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9E4423A67CF for <oauth@ietf.org>; Thu, 14 Oct 2010 01:20:59 -0700 (PDT) Received: by qyk8 with SMTP id 8so1505451qyk.10 for <oauth@ietf.org>; Thu, 14 Oct 2010 01:22:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.199.67 with SMTP id er3mr7444623qab.37.1287044518569; Thu, 14 Oct 2010 01:21:58 -0700 (PDT) Received: by 10.229.190.210 with HTTP; Thu, 14 Oct 2010 01:21:58 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 14 Oct 2010 10:21:58 +0200 Message-ID: <AANLkTik5XHaXBfV3y-vGBBrKBEWh=BUeL65Z23+-ERSB@mail.gmail.com> From: Lukas Rosenstock <lr@lukasrosenstock.net> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 08:21:00 -0000 Facebook doesn't invalidate the token. Isn't invalidating tokens incompatible with architectures which use self-contained (cryptographic) tokens instead of random strings?! If so, making this a requirement would force the server developers to implement a TRL (token revocation list, similar to a CRL) where every token - even those cryptographically valid - would need to be checked against. While this would be great from a security perspective, it might be impractical. 2010/10/14 Eran Hammer-Lahav <eran@hueniverse.com>: > Hopefully you also invalidate the token (if bearer) since it was send over an insecure channel. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Breno >> Sent: Wednesday, October 13, 2010 11:31 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Request sent to http: instead of https:` >> >> Suppose server A documents that their endpoint X is at >> https://server.example.com/x; there's no service at the corresponding http >> location for security reasons. >> >> Client developer fatfingers URL as http://server.example.com/x >> >> What is the correct response? I understand that this is out of scope for the >> spec, but maybe there's agreement on some guidance? >> >> One thing one shouldn't do is serve a 302 here; it would allow defective >> clients to remain unpatched. >> >> My preference is to simply return a bare 403 or 404 here -- after all the >> endpoint does not exist (404) or if one uses the convention that resources at >> http/https are usually identical, then http is a non-authorized method to >> access the resource (403). >> >> Thoughts? >> >> -- >> Breno de Medeiros >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Oct 14 10:04:30 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67A33A6B53 for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gizUhPM37NZz for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 10:04:30 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 799713A6B4B for <oauth@ietf.org>; Thu, 14 Oct 2010 10:04:29 -0700 (PDT) Received: from [79.253.23.248] (helo=[192.168.71.44]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1P6RFT-0007WS-BE for oauth@ietf.org; Thu, 14 Oct 2010 19:05:47 +0200 Message-ID: <4CB7386A.5080306@lodderstedt.net> Date: Thu, 14 Oct 2010 19:05:46 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 17:04:30 -0000 Will there be a OAuth session at IETF-79? The agenda currently does not contain such a session (http://tools.ietf.org/agenda/79/). regards, Torsten. From hannes.tschofenig@gmx.net Thu Oct 14 10:39:30 2010 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581263A6B27 for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnJqrLdCH8xQ for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 10:39:29 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E488D3A69DC for <oauth@ietf.org>; Thu, 14 Oct 2010 10:39:28 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2010 17:40:46 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp057) with SMTP; 14 Oct 2010 19:40:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18uga9+ld8uBYO7Diy/UqfuHYjyPhRZ8Of4RqK7bB vXIAHYBVkV+3+9 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig <hannes.tschofenig@gmx.net> In-Reply-To: <4CB7386A.5080306@lodderstedt.net> Date: Thu, 14 Oct 2010 20:40:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <F39A9271-BBD6-413D-BB7A-369116FC658D@gmx.net> References: <4CB7386A.5080306@lodderstedt.net> To: Torsten Lodderstedt <torsten@lodderstedt.net> X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 17:39:31 -0000 No, there is not going to be a session at IETF79. We intentionally did = not request a slot because of the IETF78 experience.=20 On Oct 14, 2010, at 8:05 PM, Torsten Lodderstedt wrote: > Will there be a OAuth session at IETF-79? The agenda currently does = not contain such a session (http://tools.ietf.org/agenda/79/). >=20 > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Oct 14 16:18:22 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B213A69E3 for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 16:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STBH0fZZuzEJ for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 16:18:21 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 458883A69D7 for <oauth@ietf.org>; Thu, 14 Oct 2010 16:18:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,333,1283695200"; d="scan'208";a="14307287" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 15 Oct 2010 10:19:39 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6136"; a="10816957" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 15 Oct 2010 10:19:39 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 15 Oct 2010 10:19:38 +1100 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 15 Oct 2010 10:19:36 +1100 Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> In-Reply-To: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 23:18:22 -0000 Blaine, I am in favour of splitting the specification, but the right dividing line = is not the whole of section 5 "Accessing a Protected Resource". The core OAuth spec needs to keep a section defining a WWW-Authenticate res= ponse header with which to tell a client that the OAuth "get a token" flows= can be used to get access to a resource. This is a bit like section 5.2 "T= he WWW-Authenticate Response Header Field". Error codes [section 5.2] like "expired_token" or "insufficient_scope" only= make sense in a spec that defines the flows to renew a token or change its= scope. I assume that will be the core OAuth spec, not the bearer token spe= c. For comparison, the HTTP BASIC spec does not tell you how to change your= password or register for a password. My suggestion for the editorial split: * Remove 5, 5.1, 5.1.1, 5.1.2, and 5.1.3. * Keep 5.2, and 5.2.1. -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= laine Cook Sent: Thursday, 14 October 2010 11:32 AM To: oauth@ietf.org Subject: [OAUTH-WG] Call for Consensus on Document Split Over the past few weeks, the working group debated the issues around the introduction of signatures and the structure of the specification. The working group seems to endorse the proposal to split the current specification into two parts: one including section 5 (bearer token) and the other including the rest (how to obtain a token), with an additional specification covering signature use cases. This serves as a call for consensus on the proposed editorial work. Before we proceed with the changes, the chairs would like to ask if anyone has any concerns or objections against this proposal. In addition, the chairs are seeking a volunteer to take over the bearer token specification (section 5) as editor. Please submit your comments by Wednesday, October 20th. - The OAuth Working Group Chairs _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Oct 14 16:27:55 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D144D3A69AE for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 16:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2TsJkQGP7Vd for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 16:27:55 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id CC9DD3A6973 for <oauth@ietf.org>; Thu, 14 Oct 2010 16:27:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,333,1283695200"; d="scan'208,217";a="14204148" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 15 Oct 2010 10:29:14 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6136"; a="11306701" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 15 Oct 2010 10:29:13 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 15 Oct 2010 09:29:12 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 15 Oct 2010 09:29:11 +1000 Thread-Topic: GOOG1 Thread-Index: Actr95smpefG+gMoRAuEh9Fz8rmVvg== Message-ID: <255B9BB34FB7D647A506DC292726F6E112705633B6@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112705633B6WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] GOOG1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 23:27:55 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112705633B6WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I noticed that a new HTTP authentication scheme has been defined: GOOG1. http://code.google.com/apis/storage/docs/developer-guide.html#authenticatio= n Is this a candidate for the signature spec? It should be the sort of scheme that OAuth core can provide credentials for= (access key & secret) without the scheme needing to know about OAuth. [It is an HMAC-SHA1; carried in the Authorization header; calculated over t= he method (eg GET), date, content-type, URI path (but not host or scheme), = MD5-hash of request body (optional), and some proprietary headers (eg acces= s-control details). It looks very similar to the Amazon S3 scheme.] -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E112705633B6WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-AU" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoPlainText">I noticed that a new HTTP authentication scheme h= as been defined: GOOG1.<o:p></o:p></p> <p class=3D"MsoPlainText"><a href=3D"http://code.google.com/apis/storage/do= cs/developer-guide.html#authentication">http://code.google.com/apis/storage= /docs/developer-guide.html#authentication</a><o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">Is this a candidate for the signature spec?<o:p><= /o:p></p> <p class=3D"MsoPlainText">It should be the sort of scheme that OAuth core c= an provide credentials for (access key & secret) without the scheme nee= ding to know about OAuth.<o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">[It is an HMAC-SHA1; carried in the Authorization= header; calculated over the method (eg GET), date, content-type, URI path = (but not host or scheme), MD5-hash of request body (optional), and some pro= prietary headers (eg access-control details). It looks very similar to the Amazon S3 scheme.]<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">--<o:p></o:p></p> <p class=3D"MsoNormal">James Manger<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_255B9BB34FB7D647A506DC292726F6E112705633B6WSMSG3153Vsrv_-- From eran@hueniverse.com Thu Oct 14 21:39:25 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBA33A6A6F for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 21:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdu8qb04EWNK for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 21:37:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EE8063A688A for <oauth@ietf.org>; Thu, 14 Oct 2010 21:37:37 -0700 (PDT) Received: (qmail 13907 invoked from network); 15 Oct 2010 04:38:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Oct 2010 04:38:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 14 Oct 2010 21:38:57 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, Blaine Cook <romeda@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 14 Oct 2010 21:38:46 -0700 Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQAAys2oA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4691FDFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 04:39:25 -0000 This was the proposal posted to the group earlier. In the past you have strongly promoted separate schemes for each token type= , as well as rejected the idea of a single scheme framework with sub-typing= . How would you suggest we define a general purpose www-authenticate header= that does not have a matching request header? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, October 14, 2010 4:20 PM > To: Blaine Cook; oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >=20 > Blaine, >=20 > I am in favour of splitting the specification, but the right dividing lin= e is not > the whole of section 5 "Accessing a Protected Resource". >=20 > The core OAuth spec needs to keep a section defining a WWW-Authenticate > response header with which to tell a client that the OAuth "get a token" > flows can be used to get access to a resource. This is a bit like section= 5.2 "The > WWW-Authenticate Response Header Field". >=20 > Error codes [section 5.2] like "expired_token" or "insufficient_scope" on= ly > make sense in a spec that defines the flows to renew a token or change it= s > scope. I assume that will be the core OAuth spec, not the bearer token sp= ec. > For comparison, the HTTP BASIC spec does not tell you how to change your > password or register for a password. >=20 >=20 > My suggestion for the editorial split: > * Remove 5, 5.1, 5.1.1, 5.1.2, and 5.1.3. > * Keep 5.2, and 5.2.1. >=20 >=20 > -- > James Manger >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Blaine Cook > Sent: Thursday, 14 October 2010 11:32 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for Consensus on Document Split >=20 > Over the past few weeks, the working group debated the issues around the > introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current > specification into two parts: one including section 5 (bearer token) and = the > other including the rest (how to obtain a token), with an additional > specification covering signature use cases. >=20 > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if anyon= e > has any concerns or objections against this proposal. >=20 > In addition, the chairs are seeking a volunteer to take over the bearer t= oken > specification (section 5) as editor. >=20 > Please submit your comments by Wednesday, October 20th. >=20 > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Oct 14 22:09:10 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DA03A6A3C for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 22:09:10 -0700 (PDT) X-Quarantine-ID: <20fXK1kmng1S> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...4691FDFA@P3PW5EX1MB01.EX1.SECURESERVER.NET>\n \n X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20fXK1kmng1S for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 22:09:09 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 0ABEA3A699A for <oauth@ietf.org>; Thu, 14 Oct 2010 22:09:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,334,1283695200"; d="scan'208";a="14301744" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 15 Oct 2010 16:10:27 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6136"; a="11068473" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 15 Oct 2010 16:10:27 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 15 Oct 2010 16:10:26 +1100 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 15 Oct 2010 16:10:25 +1100 Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQAAys2oAAACbDIAABCygQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127062CA94@WSMSG3153V.srv.dir.telstra.com> References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FDFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 05:09:10 -0000 Eran, > How would you suggest we define a general purpose www-authenticate > header that does not have a matching request header? Why would that be a problem? We define what a "WWW-Authenticate: OAuth2 ..." response header means, but = don't define any meaning for a "Authorization: OAuth2 ..." request header. No other scheme should define a meaning for "Authorization: OAuth2 ...". Consequently, the bearer token spec need to choose a different scheme name = (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request & response = headers. There is even some precedent for this. draft-broyer-http-cookie-auth define= s "WWW-Authenticate: COOKIE ...", without any matching request header. I think there have also been ideas to define something like "WWW-Authentica= te: TLS ..." to indicate when authentication at a lower layer (TLS, IPsec) = is required. Again there was no matching "Authorization: TLS ..." header. -- James Manger From eran@hueniverse.com Thu Oct 14 22:29:28 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6AF3A68B6 for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 22:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-SBxB3h5jKU for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 22:29:22 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A855F3A6A65 for <oauth@ietf.org>; Thu, 14 Oct 2010 22:29:21 -0700 (PDT) Received: (qmail 21441 invoked from network); 15 Oct 2010 05:30:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Oct 2010 05:30:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 14 Oct 2010 22:30:41 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 14 Oct 2010 22:30:31 -0700 Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQAAys2oAAACbDIAABCygQAACzY6A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4691FDFE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FDFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127062CA94@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127062CA94@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 05:29:29 -0000 I have no objection to this if it passes the smell test by some HTTP expert= s. I'll ask. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, October 14, 2010 10:10 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >=20 > Eran, >=20 > > How would you suggest we define a general purpose www-authenticate > > header that does not have a matching request header? >=20 > Why would that be a problem? > We define what a "WWW-Authenticate: OAuth2 ..." response header > means, but don't define any meaning for a "Authorization: OAuth2 ..." > request header. > No other scheme should define a meaning for "Authorization: OAuth2 ...". > Consequently, the bearer token spec need to choose a different scheme > name (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request & > response headers. >=20 > There is even some precedent for this. draft-broyer-http-cookie-auth > defines "WWW-Authenticate: COOKIE ...", without any matching request > header. > I think there have also been ideas to define something like "WWW- > Authenticate: TLS ..." to indicate when authentication at a lower layer (= TLS, > IPsec) is required. Again there was no matching "Authorization: TLS ..." > header. >=20 > -- > James Manger >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Oct 14 23:26:07 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70C23A6A6D for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 23:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w60akaZUcySq for <oauth@core3.amsl.com>; Thu, 14 Oct 2010 23:26:07 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id C79963A6857 for <oauth@ietf.org>; Thu, 14 Oct 2010 23:26:06 -0700 (PDT) Received: from [80.187.100.146] (helo=[10.217.210.210]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1P6dlF-0005b6-RC; Fri, 15 Oct 2010 08:27:26 +0200 Message-ID: <4CB7F449.7020609@lodderstedt.net> Date: Fri, 15 Oct 2010 08:27:21 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hannes Tschofenig <hannes.tschofenig@gmx.net> References: <4CB7386A.5080306@lodderstedt.net> <F39A9271-BBD6-413D-BB7A-369116FC658D@gmx.net> In-Reply-To: <F39A9271-BBD6-413D-BB7A-369116FC658D@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 06:26:07 -0000 I'm surprised, since there is a lot to talk about. For example, I planned to present (together with Mark) the current status of the security consideration work (e.g. threat model). Moreover, there are several I-Ds waiting for promotion to WG item. How will we proceed here? Who else of the WG planned to come to IETF-79? regards, Torsten. Am 14.10.2010 19:40, schrieb Hannes Tschofenig: > No, there is not going to be a session at IETF79. We intentionally did not request a slot because of the IETF78 experience. > > On Oct 14, 2010, at 8:05 PM, Torsten Lodderstedt wrote: > >> Will there be a OAuth session at IETF-79? The agenda currently does not contain such a session (http://tools.ietf.org/agenda/79/). >> >> regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Fri Oct 15 00:24:26 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415263A6C65 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 00:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ychvSddFu4Pe for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 00:24:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C8C9D3A6C5F for <oauth@ietf.org>; Fri, 15 Oct 2010 00:24:21 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9F7PWLK029070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Oct 2010 02:25:33 -0500 (CDT) Received: from [135.244.227.98] (faynberg.lra.lucent.com [135.244.227.98]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o9F7PU1p016896; Fri, 15 Oct 2010 02:25:31 -0500 (CDT) Message-ID: <4CB801E8.6030407@alcatel-lucent.com> Date: Fri, 15 Oct 2010 03:25:28 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt <torsten@lodderstedt.net> References: <4CB7386A.5080306@lodderstedt.net> <F39A9271-BBD6-413D-BB7A-369116FC658D@gmx.net> <4CB7F449.7020609@lodderstedt.net> In-Reply-To: <4CB7F449.7020609@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 07:24:26 -0000 I echo Torsten's concern. I definitely plan to come, and Torsten's and Mark's security discussion was one, perhaps the most important, of several that I planned to participate in. and where I expect many others will. Then there are new use cases, too, coming different place, and it would be good to settle on them and freeze the document at soon as possible so that all new features in 2.0 could be introduced only if they are needed by one or another use case. The problem with the last meeting's "low energy" and respective attendance, in my opinion, is one word: vacation. For many people the meeting just came in the midst of it... Igor Torsten Lodderstedt wrote: > I'm surprised, since there is a lot to talk about. For example, I > planned to present (together with Mark) the current status of the > security consideration work (e.g. threat model). Moreover, there are > several I-Ds waiting for promotion to WG item. How will we proceed here? > > Who else of the WG planned to come to IETF-79? > > regards, > Torsten. > > Am 14.10.2010 19:40, schrieb Hannes Tschofenig: >> No, there is not going to be a session at IETF79. We intentionally >> did not request a slot because of the IETF78 experience. >> >> On Oct 14, 2010, at 8:05 PM, Torsten Lodderstedt wrote: >> >>> Will there be a OAuth session at IETF-79? The agenda currently does >>> not contain such a session (http://tools.ietf.org/agenda/79/). >>> >>> regards, >>> Torsten. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lear@cisco.com Fri Oct 15 04:08:32 2010 Return-Path: <lear@cisco.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51533A6AA4 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXdWatU3Hpnd for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:08:31 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BF07D3A6A55 for <oauth@ietf.org>; Fri, 15 Oct 2010 04:08:31 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFACvTt0yrRN+K/2dsb2JhbACDH5AHjXtxoFSKHZIegSKDM3QEiko X-IronPort-AV: E=Sophos;i="4.57,335,1283731200"; d="scan'208";a="201334230" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 15 Oct 2010 11:09:52 +0000 Received: from ams3-vpn-dhcp5233.cisco.com (ams3-vpn-dhcp5233.cisco.com [10.61.84.112]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9FB9phD001618; Fri, 15 Oct 2010 11:09:52 GMT Message-ID: <4CB8369F.4000804@cisco.com> Date: Fri, 15 Oct 2010 13:10:23 +0200 From: Eliot Lear <lear@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4CB7386A.5080306@lodderstedt.net> <F39A9271-BBD6-413D-BB7A-369116FC658D@gmx.net> <4CB7F449.7020609@lodderstedt.net> <4CB801E8.6030407@alcatel-lucent.com> In-Reply-To: <4CB801E8.6030407@alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 11:08:32 -0000 I agree with Hannes' approach. What happened in Maastricht was that we ended up with bifurcated discussions- in the room and on the list. That didn't seem very productive. From lear@cisco.com Fri Oct 15 04:20:57 2010 Return-Path: <lear@cisco.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F7F3A6AC7 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.821 X-Spam-Level: X-Spam-Status: No, score=-108.821 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLyhJKNlqfQd for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:20:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 961C23A699E for <oauth@ietf.org>; Fri, 15 Oct 2010 04:20:56 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsEAL/Vt0yQ/khNgWdsb2JhbACDH5AHjXsVAQEWIiKgWYodkh6BIoMzdASKSg X-IronPort-AV: E=Sophos;i="4.57,335,1283731200"; d="scan'208";a="66749339" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2010 11:22:17 +0000 Received: from ams3-vpn-dhcp5233.cisco.com (ams3-vpn-dhcp5233.cisco.com [10.61.84.112]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9FBMG9q000673; Fri, 15 Oct 2010 11:22:17 GMT Message-ID: <4CB83989.803@cisco.com> Date: Fri, 15 Oct 2010 13:22:49 +0200 From: Eliot Lear <lear@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: torsten@lodderstedt.net References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> In-Reply-To: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 11:20:57 -0000 On 10/15/10 1:13 PM, torsten@lodderstedt.net wrote: > What is the alternative from your point of view? > Continued use of the mailing list, as long as we think that's working. Eliot From hannes.tschofenig@gmx.net Fri Oct 15 04:38:54 2010 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B51E3A6AA4 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdH9wH4kQCDk for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:38:53 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id CBAE13A69CF for <oauth@ietf.org>; Fri, 15 Oct 2010 04:38:52 -0700 (PDT) Received: (qmail invoked by alias); 15 Oct 2010 11:40:12 -0000 Received: from unknown (EHLO [10.254.0.17]) [192.100.123.77] by mail.gmx.net (mp023) with SMTP; 15 Oct 2010 13:40:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+y1/R9K0eyR+kP+2EOcB6l9tMlz+CGJJm2cqbBVW pfVFNG9zu/lugc Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig <hannes.tschofenig@gmx.net> In-Reply-To: <4CB83989.803@cisco.com> Date: Fri, 15 Oct 2010 14:40:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <E35508EE-6490-44B1-A5CB-08F96330AC58@gmx.net> References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> <4CB83989.803@cisco.com> To: Eliot Lear <lear@cisco.com> X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 11:38:54 -0000 Hi Torsten,=20 there is no problem with skipping a meeting. This is done in other = working groups as well.=20 Ciao Hannes On Oct 15, 2010, at 2:22 PM, Eliot Lear wrote: >=20 >=20 > On 10/15/10 1:13 PM, torsten@lodderstedt.net wrote: >> What is the alternative from your point of view? >>=20 > Continued use of the mailing list, as long as we think that's working. >=20 > Eliot > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From SRS0=lBuS2s=RR=lodderstedt.net=torsten@srs.bis.eu.blackberry.com Fri Oct 15 04:11:54 2010 Return-Path: <SRS0=lBuS2s=RR=lodderstedt.net=torsten@srs.bis.eu.blackberry.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FDB3A6B21 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmncQTT2RUMh for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 04:11:51 -0700 (PDT) Received: from smtp04.bis.eu.blackberry.com (smtp04.bis.eu.blackberry.com [216.9.253.27]) by core3.amsl.com (Postfix) with ESMTP id 8B0E73A6C07 for <oauth@ietf.org>; Fri, 15 Oct 2010 04:11:50 -0700 (PDT) Received: from bda319.bisx.produk.on.blackberry (bda319.bisx.produk.on.blackberry [172.24.226.175]) by srs.bis.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id o9FBDA6e010074; Fri, 15 Oct 2010 11:13:10 GMT Received: from bda319.bisx.produk.on.blackberry (localhost.localdomain [127.0.0.1]) by bda319.bisx.produk.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id o9FBDANx000537; Fri, 15 Oct 2010 11:13:10 GMT X-rim-org-msg-ref-id: 245536261 Message-ID: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: "Eliot Lear" <lear@cisco.com>, igor.faynberg@alcatel-lucent.com From: torsten@lodderstedt.net Date: Fri, 15 Oct 2010 11:13:08 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 11:54:12 -0000 V2hhdCBpcyB0aGUgYWx0ZXJuYXRpdmUgZnJvbSB5b3VyIHBvaW50IG9mIHZpZXc/DQoNClJlZ2Fy ZHMsDQpUb3JzdGVuLg0KLS0tLS0tT3JpZ2luYWxuYWNocmljaHQtLS0tLS0NClZvbjogRWxpb3Qg TGVhcg0KQW46aWdvci5mYXluYmVyZ0BhbGNhdGVsLWx1Y2VudC5jb20NCkNjOkxvZGRlcnN0ZWR0 LCBUb3JzdGVuDQpDYzpvYXV0aEBpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtPQVVUSC1XR10gT0F1 dGggc2Vzc2lvbiBhdCBJRVRGLTc5DQpHZXNlbmRldDogMTUuIE9rdC4gMjAxMCAxMzoxMA0KDQog SSBhZ3JlZSB3aXRoIEhhbm5lcycgYXBwcm9hY2guICBXaGF0IGhhcHBlbmVkIGluIE1hYXN0cmlj aHQgd2FzIHRoYXQgd2UNCmVuZGVkIHVwIHdpdGggIGJpZnVyY2F0ZWQgZGlzY3Vzc2lvbnMtIGlu IHRoZSByb29tIGFuZCBvbiB0aGUgbGlzdC4gDQpUaGF0IGRpZG4ndCBzZWVtIHZlcnkgcHJvZHVj dGl2ZS4NCg0KDQpHZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBE ZXV0c2NobGFuZCAg From hannes.tschofenig@nsn.com Fri Oct 15 05:12:44 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E2E3A6A9E for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UAElutJZ3BO for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 05:12:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EEB023A6C8A for <oauth@ietf.org>; Fri, 15 Oct 2010 05:11:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9FCCr6T009303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 14:12:53 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9FCCnQN026442; Fri, 15 Oct 2010 14:12:53 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Oct 2010 14:11:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2010 15:11:29 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45033374BA@FIESEXC015.nsn-intra.net> In-Reply-To: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth session at IETF-79 Thread-Index: ActsX+PPSD1CrZbBRnSnMmZBkZH0XwAATspw References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: <torsten@lodderstedt.net>, "Eliot Lear" <lear@cisco.com>, <igor.faynberg@alcatel-lucent.com> X-OriginalArrivalTime: 15 Oct 2010 12:11:08.0332 (UTC) FILETIME=[0C8C7EC0:01CB6C62] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 12:12:44 -0000 Hi Torsten, We have to figure out what the most efficient way is to get our work done.=20 With the Prague IETF we will see again whether there is a need for face-to-face meeting. We had phone conference calls earlier this year as well. That's another option to make progress in addition to the usage of the mailing list. =20 Attending the IETF meetings is useful to get a better understanding of the big picture and that's why I go there. However, I understand that others have travel restrictions. Meetings outside the US, like this one, are obviously more expensive for those who are based in the US.=20 =20 Ciao Hannes > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of ext torsten@lodderstedt.net > Sent: Friday, October 15, 2010 2:13 PM > To: Eliot Lear; igor.faynberg@alcatel-lucent.com > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth session at IETF-79 >=20 > What is the alternative from your point of view? >=20 > Regards, > Torsten. > ------Originalnachricht------ > Von: Eliot Lear > An:igor.faynberg@alcatel-lucent.com > Cc:Lodderstedt, Torsten > Cc:oauth@ietf.org > Betreff: Re: [OAUTH-WG] OAuth session at IETF-79 > Gesendet: 15. Okt. 2010 13:10 >=20 > I agree with Hannes' approach. What happened in Maastricht=20 > was that we > ended up with bifurcated discussions- in the room and on the list.=20 > That didn't seem very productive. >=20 >=20 > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From hannes.tschofenig@gmx.net Fri Oct 15 05:56:55 2010 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82ABB3A69A4 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 05:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.913 X-Spam-Level: X-Spam-Status: No, score=-100.913 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEmHniWNos2f for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 05:56:54 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 40C4C3A6A45 for <oauth@ietf.org>; Fri, 15 Oct 2010 05:56:54 -0700 (PDT) Received: (qmail invoked by alias); 15 Oct 2010 12:58:13 -0000 Received: from unknown (EHLO [10.254.0.17]) [192.100.123.77] by mail.gmx.net (mp064) with SMTP; 15 Oct 2010 14:58:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/RuvEuyNDRwoj7NGgc3jdqqAIC97hqpdoyze4rDA ncvmGyVcrm2E/v From: Hannes Tschofenig <hannes.tschofenig@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2010 15:58:12 +0300 Message-Id: <AF91F25C-362B-4505-82BA-473B8935D22C@gmx.net> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 12:56:55 -0000 Hi all,=20 please drop me a mail if you plan to travel to Beijing and if you are = interested to chat about OAuth. We have no time restrictions (unlike = with working group meetings) and so we could go into the details of any = topic. I personally would be interested to do some OAuth security work. Ciao Hannes From recordond@gmail.com Fri Oct 15 10:50:51 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740423A6CDA for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 10:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZusUnTEbWDdz for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 10:50:49 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B16703A6CB8 for <oauth@ietf.org>; Fri, 15 Oct 2010 10:50:49 -0700 (PDT) Received: by iwn10 with SMTP id 10so1389124iwn.31 for <oauth@ietf.org>; Fri, 15 Oct 2010 10:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CNNNVVFFkevYMJHBgRYXYXZih6IEUXMJlGno1W4l72E=; b=T8lqsTd5FdqCZjlz6g6bwu5Mxwo4Hjx3XlTXhvSH10UaowbLRv6ZBrDWs+msBu59m/ vALavBLlbqEzV58hfoH8FLfX3OoeHDVCfvhbDuXn3IGYAyvjfN+Z0hfNVCh/u8jXMchE EFAaRFbQGpXNqeYYHd9qdPhRFk5nP8iGd8e2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I7OQgA7M1KIokkbUcKP/asOfHsmJJ+3qrtxZZgppzoziJ6n7QToUxcp0chA5476W+I Lp2Yg2bCwX0UN9dfM1gjhAip1Imo2Dbd9IV5JMs5KTpszEb9K0qM4MSXRbWY3MM7zeKP cetuyUf74XmF+Uw01pu0arfKfQszacwmYOs6o= MIME-Version: 1.0 Received: by 10.42.176.200 with SMTP id bf8mr982644icb.3.1287165128541; Fri, 15 Oct 2010 10:52:08 -0700 (PDT) Received: by 10.231.148.70 with HTTP; Fri, 15 Oct 2010 10:52:07 -0700 (PDT) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45033374BA@FIESEXC015.nsn-intra.net> References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> <3D3C75174CB95F42AD6BCC56E5555B45033374BA@FIESEXC015.nsn-intra.net> Date: Fri, 15 Oct 2010 10:52:07 -0700 Message-ID: <AANLkTincXp+JsFrQJm91krKw10rei418Uo-YpLEf26Zb@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Content-Type: multipart/alternative; boundary=90e6ba6e84fc4121ca0492ab7ca3 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 17:50:51 -0000 --90e6ba6e84fc4121ca0492ab7ca3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Hannes, I'd like to at least explain my reasoning behind not planning t= o go to the China meeting because it really isn't restrictions around travel. This is likely inpolitic to say, but it's because of how much of a waste of my time the LA meeting was. The LA meeting contained numerous people who weren't =96 and still aren't =96 engaged in this working group who felt tha= t they should argue with us repeatedly around how what we were doing was wron= g and already solved by Kerberos. That trip was only two days, but China will easily be a week. So for me it is about what is the best use of my time, no= t just how much it costs. I'd love to have another face to face meeting between people working actively on deploying OAuth 2.0. I hope that IIW in a few weeks will provid= e a venue for some of that. But if it's in Europe then I'll go to Europe. For me it is about who is (and isn't) going to be there rather than where the meeting is physically located. --David On Fri, Oct 15, 2010 at 5:11 AM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > Hi Torsten, > > We have to figure out what the most efficient way is to get our work > done. > > With the Prague IETF we will see again whether there is a need for > face-to-face meeting. We had phone conference calls earlier this year as > well. That's another option to make progress in addition to the usage of > the mailing list. > > Attending the IETF meetings is useful to get a better understanding of > the big picture and that's why I go there. However, I understand that > others have travel restrictions. Meetings outside the US, like this one, > are obviously more expensive for those who are based in the US. > > Ciao > Hannes > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > On Behalf Of ext torsten@lodderstedt.net > > Sent: Friday, October 15, 2010 2:13 PM > > To: Eliot Lear; igor.faynberg@alcatel-lucent.com > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth session at IETF-79 > > > > What is the alternative from your point of view? > > > > Regards, > > Torsten. > > ------Originalnachricht------ > > Von: Eliot Lear > > An:igor.faynberg@alcatel-lucent.com<An%3Aigor.faynberg@alcatel-lucent.c= om> > > Cc:Lodderstedt, Torsten > > Cc:oauth@ietf.org <Cc%3Aoauth@ietf.org> > > Betreff: Re: [OAUTH-WG] OAuth session at IETF-79 > > Gesendet: 15. Okt. 2010 13:10 > > > > I agree with Hannes' approach. What happened in Maastricht > > was that we > > ended up with bifurcated discussions- in the room and on the list. > > That didn't seem very productive. > > > > > > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --90e6ba6e84fc4121ca0492ab7ca3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey Hannes, I'd like to at least explain my reasoning behind not planni= ng to go to the China meeting because it really isn't restrictions arou= nd travel. This is likely inpolitic to say, but it's because of how muc= h of a waste of my time the LA meeting was. The LA meeting contained numero= us people who weren't =96 and still aren't =96 engaged in this work= ing group who felt that they should argue with us=A0repeatedly=A0around how= what we were doing was wrong and already solved by Kerberos.=A0<meta chars= et=3D"utf-8">That trip was only two days, but China will easily be a week.= =A0So for me it is about what is the best use of my time, not just how much= it costs.<div> <br></div><div>I'd love to have another face to face meeting between pe= ople working actively on deploying OAuth 2.0. I hope that IIW in a few week= s will provide a venue for some of that. But if it's in Europe then I&#= 39;ll go to Europe. For me it is about who is (and isn't) going to be t= here rather than where the meeting is physically located.<br> <div><br></div><div>--David</div><div><br><br><div class=3D"gmail_quote">On= Fri, Oct 15, 2010 at 5:11 AM, Tschofenig, Hannes (NSN - FI/Espoo) <span di= r=3D"ltr"><<a href=3D"mailto:hannes.tschofenig@nsn.com">hannes.tschofeni= g@nsn.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hi Torsten,<br> <br> We have to figure out what the most efficient way is to get our work<br> done.<br> <br> With the Prague IETF we will see again whether there is a need for<br> face-to-face meeting. We had phone conference calls earlier this year as<br= > well. That's another option to make progress in addition to the usage o= f<br> the mailing list.<br> <br> Attending the IETF meetings is useful to get a better understanding of<br> the big picture and that's why I go there. =A0However, I understand tha= t<br> others have travel restrictions. Meetings outside the US, like this one,<br= > are obviously more expensive for those who are based in the US.<br> <br> Ciao<br> Hannes<br> <div class=3D"im"><br> > -----Original Message-----<br> > From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org= </a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.o= rg</a>]<br> > On Behalf Of ext <a href=3D"mailto:torsten@lodderstedt.net">torsten@lo= dderstedt.net</a><br> > Sent: Friday, October 15, 2010 2:13 PM<br> > To: Eliot Lear; <a href=3D"mailto:igor.faynberg@alcatel-lucent.com">ig= or.faynberg@alcatel-lucent.com</a><br> > Cc: <a href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a><br> > Subject: Re: [OAUTH-WG] OAuth session at IETF-79<br> ><br> > What is the alternative from your point of view?<br> ><br> > Regards,<br> > Torsten.<br> > ------Originalnachricht------<br> > Von: Eliot Lear<br> > <a href=3D"mailto:An%3Aigor.faynberg@alcatel-lucent.com">An:igor.faynb= erg@alcatel-lucent.com</a><br> > Cc:Lodderstedt, Torsten<br> > <a href=3D"mailto:Cc%3Aoauth@ietf.org">Cc:oauth@ietf.org</a><br> > Betreff: Re: [OAUTH-WG] OAuth session at IETF-79<br> > Gesendet: 15. Okt. 2010 13:10<br> ><br> > =A0I agree with Hannes' approach. =A0What happened in Maastricht<b= r> > was that we<br> > ended up with =A0bifurcated discussions- in the room and on the list.<= br> > That didn't seem very productive.<br> ><br> ><br> </div>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland<br> <div><div></div><div class=3D"h5">> ____________________________________= ___________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br></div></div> --90e6ba6e84fc4121ca0492ab7ca3-- From muralive@gmail.com Fri Oct 15 11:25:28 2010 Return-Path: <muralive@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F413A6A2B for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfBgaXZ9-0gh for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 11:25:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 32A293A69A1 for <oauth@ietf.org>; Fri, 15 Oct 2010 11:25:27 -0700 (PDT) Received: by yxk30 with SMTP id 30so551224yxk.31 for <oauth@ietf.org>; Fri, 15 Oct 2010 11:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=FfFYmx0dofFkZh63ObhR7Ra/u2Fh2afiypMIdIz1vh4=; b=HuEpxJQAq90Vpxc3Mha86IxWt4DH+5gadDVUrvwD+hzNUo5VWVxAjDv3DCYrzi6Nqa SuWRfcGLEAf/tOh1uTvZXNtduqhijBKCcccWylNAyB7oY6UPGPqj6M+tszys4Met+X55 lEoY4S13xUX7npePmglnsHGAIhy/OsOEVAgr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=pfrYUa0HXayMEA1d5VKmbKPIT2qegrXaBVxEU3NLSCVS8qnBGSx0CFBQvTHO6n1wyK fAqCmC9ZAdHuDaFPvZf2mOJirGunYgtE2Ri/8Z4+BabEzgVCt75fgKqLA6XoTn2mnZhc 7CVVq7WbCo3CLNe7Nia83n8nhNURbXqNs5QPI= Received: by 10.103.108.8 with SMTP id k8mr683685mum.53.1287167207499; Fri, 15 Oct 2010 11:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.114.198 with HTTP; Fri, 15 Oct 2010 11:26:27 -0700 (PDT) In-Reply-To: <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> References: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> From: Murali VP <muralive@gmail.com> Date: Fri, 15 Oct 2010 11:26:27 -0700 Message-ID: <AANLkTik+ydsu3rk0iYGRBZhVhkfE9nBDA-WbFfqWNxHu@mail.gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: multipart/alternative; boundary=001636416d772b678a0492abf851 Subject: Re: [OAUTH-WG] Opensource impl yet? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 18:25:28 -0000 --001636416d772b678a0492abf851 Content-Type: text/plain; charset=ISO-8859-1 LinkedIn announced recently that they use OAuth2's UserAgent flow: http://developer.linkedin.com/community/jsapi On Tue, Oct 12, 2010 at 10:32 PM, David Recordon <recordond@gmail.com>wrote: > I haven't seen one. Have been trying to keep track of all the > implementation on http://wiki.oauth.net/w/page/OAuth-2. > > > On Tue, Oct 12, 2010 at 9:33 AM, William Mills <wmills@yahoo-inc.com>wrote: > >> Is there a C/C++ opensource implementation yet I can use for the >> reference implementation of the SASL mechanism yet? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636416d772b678a0492abf851 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable LinkedIn announced recently that they use OAuth2's UserAgent flow:<br><= a href=3D"http://developer.linkedin.com/community/jsapi">http://developer.l= inkedin.com/community/jsapi</a><br><br><div class=3D"gmail_quote">On Tue, O= ct 12, 2010 at 10:32 PM, David Recordon <span dir=3D"ltr"><<a href=3D"ma= ilto:recordond@gmail.com">recordond@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I haven't see= n one. Have been trying to keep track of all the implementation on=A0<a hre= f=3D"http://wiki.oauth.net/w/page/OAuth-2" target=3D"_blank">http://wiki.oa= uth.net/w/page/OAuth-2</a>.<div> <br><br><div class=3D"gmail_quote"><div class=3D"im">On Tue, Oct 12, 2010 a= t 9:33 AM, William Mills <span dir=3D"ltr"><<a href=3D"mailto:wmills@yah= oo-inc.com" target=3D"_blank">wmills@yahoo-inc.com</a>></span> wrote:<br= > </div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;= border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class= =3D"im"> <div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"> <div> <p class=3D"MsoNormal">Is there a C/C++ opensource implementation yet I can= use for the reference implementation of the SASL mechanism yet?</p> </div> </div> <br></div>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br> --001636416d772b678a0492abf851-- From eve@xmlgrrl.com Fri Oct 15 13:35:22 2010 Return-Path: <eve@xmlgrrl.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE483A6CDA for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 13:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPVXqd7eEJf3 for <oauth@core3.amsl.com>; Fri, 15 Oct 2010 13:35:19 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 9753F3A63D2 for <oauth@ietf.org>; Fri, 15 Oct 2010 13:35:16 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o9FKaT5C005246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Oct 2010 13:36:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-194--369855518 From: Eve Maler <eve@xmlgrrl.com> In-Reply-To: <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> Date: Fri, 15 Oct 2010 13:36:29 -0700 Message-Id: <7C9956AE-B231-4ECA-9585-4BE071F5617E@xmlgrrl.com> References: <FFDFD7371D517847AD71FBB08F9A3156254C4A715E@SP2-EX07VS06.ds.corp.yahoo.com> <AANLkTimPSfdfvL2BcviYTgpGdvXKkYKLSrGtaB1xiYWa@mail.gmail.com> To: David Recordon <recordond@gmail.com> X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Opensource impl yet? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 20:35:22 -0000 --Apple-Mail-194--369855518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Don't forget this implementation: http://leeloo.smartam.net/ Eve On 12 Oct 2010, at 10:32 PM, David Recordon wrote: > I haven't seen one. Have been trying to keep track of all the = implementation on http://wiki.oauth.net/w/page/OAuth-2. >=20 >=20 > On Tue, Oct 12, 2010 at 9:33 AM, William Mills <wmills@yahoo-inc.com> = wrote: > Is there a C/C++ opensource implementation yet I can use for the = reference implementation of the SASL mechanism yet? >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail-194--369855518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div>Don't forget this implementation:</div><div><br></div><div><a = href=3D"http://leeloo.smartam.net/">http://leeloo.smartam.net/</a></div><d= iv><br></div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>Eve</div><br><div><div>On 12 Oct = 2010, at 10:32 PM, David Recordon wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite">I haven't = seen one. Have been trying to keep track of all the implementation = on <a = href=3D"http://wiki.oauth.net/w/page/OAuth-2">http://wiki.oauth.net/w/page= /OAuth-2</a>.<div><br><br><div class=3D"gmail_quote">On Tue, Oct 12, = 2010 at 9:33 AM, William Mills <span dir=3D"ltr"><<a = href=3D"mailto:wmills@yahoo-inc.com">wmills@yahoo-inc.com</a>></span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div><p class=3D"MsoNormal">Is there a C/C++ opensource implementation = yet I can use for the reference implementation of the SASL mechanism yet?</p> </div> </div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> _______________________________________________<br>OAuth mailing = list<br><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>https://www.ietf.org/= mailman/listinfo/oauth<br></blockquote></div><br><div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = Helvetica; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; line-height: normal; orphans: 2; = text-indent: 0px; text-transform: none; white-space: normal; widows: 2; = word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = Helvetica; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; line-height: normal; orphans: 2; = text-indent: 0px; text-transform: none; white-space: normal; widows: 2; = word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = Helvetica; font-size: medium; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = Courier; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div><br = class=3D"Apple-interchange-newline">Eve Maler       =                     =        <a = href=3D"http://www.xmlgrrl.com/blog">http://www.xmlgrrl.com/blog</a></div>= <div>+1 425 345 6756               =           <a = href=3D"http://www.twitter.com/xmlgrrl">http://www.twitter.com/xmlgrrl</a>= </div></span></div></span></div></span></div></span></div> </div> <br></body></html>= --Apple-Mail-194--369855518-- From torsten@lodderstedt.net Sat Oct 16 02:46:13 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF293A6BE9 for <oauth@core3.amsl.com>; Sat, 16 Oct 2010 02:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QoC+0AJObRD for <oauth@core3.amsl.com>; Sat, 16 Oct 2010 02:46:09 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by core3.amsl.com (Postfix) with ESMTP id 819413A6BE7 for <oauth@ietf.org>; Sat, 16 Oct 2010 02:46:03 -0700 (PDT) Received: from [79.253.23.81] (helo=[192.168.71.44]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1P73MK-0000Jy-Ij; Sat, 16 Oct 2010 11:47:24 +0200 Message-ID: <4CB974A9.4000407@lodderstedt.net> Date: Sat, 16 Oct 2010 11:47:21 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Recordon <recordond@gmail.com> References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> <3D3C75174CB95F42AD6BCC56E5555B45033374BA@FIESEXC015.nsn-intra.net> <AANLkTincXp+JsFrQJm91krKw10rei418Uo-YpLEf26Zb@mail.gmail.com> In-Reply-To: <AANLkTincXp+JsFrQJm91krKw10rei418Uo-YpLEf26Zb@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------000704000803070703020303" X-Df-Sender: torsten@lodderstedt-online.de Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 Oct 2010 09:46:13 -0000 This is a multi-part message in MIME format. --------------000704000803070703020303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Am 15.10.2010 19:52, schrieb David Recordon: > Hey Hannes, I'd like to at least explain my reasoning behind not > planning to go to the China meeting because it really isn't > restrictions around travel. This is likely inpolitic to say, but it's > because of how much of a waste of my time the LA meeting was. The LA > meeting contained numerous people who weren't and still aren't > engaged in this working group who felt that they should argue with > us repeatedly around how what we were doing was wrong and already > solved by Kerberos. That trip was only two days, but China will easily > be a week. So for me it is about what is the best use of my time, not > just how much it costs. > > I'd love to have another face to face meeting between people working > actively on deploying OAuth 2.0. I hope that IIW in a few weeks will > provide a venue for some of that. But if it's in Europe then I'll go > to Europe. For me it is about who is (and isn't) going to be there > rather than where the meeting is physically located. I fully agree with you. Unfortunately, I had assumed to meet the WG people at IETF meetings and it's to late for me to arrange for a travel to IIW (mainly du to administrative proccess). regards, Torsten. > > --David > > > On Fri, Oct 15, 2010 at 5:11 AM, Tschofenig, Hannes (NSN - FI/Espoo) > <hannes.tschofenig@nsn.com <mailto:hannes.tschofenig@nsn.com>> wrote: > > Hi Torsten, > > We have to figure out what the most efficient way is to get our work > done. > > With the Prague IETF we will see again whether there is a need for > face-to-face meeting. We had phone conference calls earlier this > year as > well. That's another option to make progress in addition to the > usage of > the mailing list. > > Attending the IETF meetings is useful to get a better understanding of > the big picture and that's why I go there. However, I understand that > others have travel restrictions. Meetings outside the US, like > this one, > are obviously more expensive for those who are based in the US. > > Ciao > Hannes > > > -----Original Message----- > > From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> > [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] > > On Behalf Of ext torsten@lodderstedt.net > <mailto:torsten@lodderstedt.net> > > Sent: Friday, October 15, 2010 2:13 PM > > To: Eliot Lear; igor.faynberg@alcatel-lucent.com > <mailto:igor.faynberg@alcatel-lucent.com> > > Cc: oauth@ietf.org <mailto:oauth@ietf.org> > > Subject: Re: [OAUTH-WG] OAuth session at IETF-79 > > > > What is the alternative from your point of view? > > > > Regards, > > Torsten. > > ------Originalnachricht------ > > Von: Eliot Lear > > An:igor.faynberg@alcatel-lucent.com > <mailto:An%3Aigor.faynberg@alcatel-lucent.com> > > Cc:Lodderstedt, Torsten > > Cc:oauth@ietf.org <mailto:Cc%3Aoauth@ietf.org> > > Betreff: Re: [OAUTH-WG] OAuth session at IETF-79 > > Gesendet: 15. Okt. 2010 13:10 > > > > I agree with Hannes' approach. What happened in Maastricht > > was that we > > ended up with bifurcated discussions- in the room and on the list. > > That didn't seem very productive. > > > > > > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > --------------000704000803070703020303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <title> Am 15.10.2010 19:52, schrieb David Recordon:
Hey Hannes, I'd like to at least explain my reasoning behind not planning to go to the China meeting because it really isn't restrictions around travel. This is likely inpolitic to say, but it's because of how much of a waste of my time the LA meeting was. The LA meeting contained numerous people who weren't and still aren't engaged in this working group who felt that they should argue with usrepeatedlyaround how what we were doing was wrong and already solved by Kerberos. That trip was only two days, but China will easily be a week.So for me it is about what is the best use of my time, not just how much it costs.

I'd love to have another face to face meeting between people working actively on deploying OAuth 2.0. I hope that IIW in a few weeks will provide a venue for some of that. But if it's in Europe then I'll go to Europe. For me it is about who is (and isn't) going to be there rather than where the meeting is physically located.

I fully agree with you. Unfortunately, I had assumed to meet the WG people at IETF meetings and it's to late for me to arrange for a travel to IIW (mainly du to administrative proccess).

regards,
Torsten.

--David


On Fri, Oct 15, 2010 at 5:11 AM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
Hi Torsten,

We have to figure out what the most efficient way is to get our work
done.

With the Prague IETF we will see again whether there is a need for
face-to-face meeting. We had phone conference calls earlier this year as
well. That's another option to make progress in addition to the usage of
the mailing list.

Attending the IETF meetings is useful to get a better understanding of
the big picture and that's why I go there. However, I understand that
others have travel restrictions. Meetings outside the US, like this one,
are obviously more expensive for those who are based in the US.

Ciao
Hannes

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> On Behalf Of ext torsten@lodderstedt.net
> Sent: Friday, October 15, 2010 2:13 PM
> To: Eliot Lear; igor.faynberg@alcatel-lucent.com
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth session at IETF-79
>
> What is the alternative from your point of view?
>
> Regards,
> Torsten.
> ------Originalnachricht------
> Von: Eliot Lear
> An:igor.faynberg@alcatel-lucent.com
> Cc:Lodderstedt, Torsten
> Cc:oauth@ietf.org
> Betreff: Re: [OAUTH-WG] OAuth session at IETF-79
> Gesendet: 15. Okt. 2010 13:10
>
> I agree with Hannes' approach. What happened in Maastricht
> was that we
> ended up with bifurcated discussions- in the room and on the list.
> That didn't seem very productive.
>
>
> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------000704000803070703020303-- From niklas.neumann@cs.uni-goettingen.de Mon Oct 18 09:01:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EE73A6DE3 for ; Mon, 18 Oct 2010 09:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeb9+ylO6TWo for ; Mon, 18 Oct 2010 09:01:46 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id 85EA83A6E12 for ; Mon, 18 Oct 2010 09:01:40 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P7sB2-0004z5-QX for oauth@ietf.org; Mon, 18 Oct 2010 18:03:08 +0200 Message-ID: <4CBC6FC0.5040708@cs.uni-goettingen.de> Date: Mon, 18 Oct 2010 18:03:12 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie Subject: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:01:46 -0000 Hello everybody, I am currently working on a projected related to authentication and secure token transfer between multiple devices. As such we are employing a simple protocol that handles token transfers independent of the actual type of token. We have adapted the protocol to be used with OAuth tokens and submitted it as an Internet Draft: http://tools.ietf.org/html/draft-neumann-oauth-token-transfer I was wondering if there is interest in employing such a protocol in cases where the HTTP redirection schemes of OAuth are not available or not working well (e.g. desktop applications without access to a user agent or authentication from a different device/application than the one accessing the consumer). Compared to other proposals such as draft-dehora-farrell-oauth-accesstoken-creds the STTP is more heavyweight but in turn it also has more options. With regards to authentication we didn't use SASL for complexity reasons in our work initialy but I don't see any reason not to include it if this is deemed more appropriate. The work that the draft is based on is still ongoing. Please understand the draft as no more than a discussion proposal on how OAuth could be opened to non-web-based environments and scenarios that involve multiple devices without overloading the OAuth specification itself. I am happy to further improve the draft if you think this might be a viable option. Best regards Niklas -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From jricher@mitre.org Mon Oct 18 09:14:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EC03A6E0B for ; Mon, 18 Oct 2010 09:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-rX86vl3dmR for ; Mon, 18 Oct 2010 09:14:31 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 752513A6E2E for ; Mon, 18 Oct 2010 09:13:36 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9IGF3Qe015677 for ; Mon, 18 Oct 2010 12:15:03 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9IGF2gq015651; Mon, 18 Oct 2010 12:15:02 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 18 Oct 2010 12:15:02 -0400 From: Justin Richer To: Niklas Neumann In-Reply-To: <4CBC6FC0.5040708@cs.uni-goettingen.de> References: <4CBC6FC0.5040708@cs.uni-goettingen.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Oct 2010 12:15:02 -0400 Message-ID: <1287418502.6627.640.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:14:34 -0000 The ability to securely transfer tokens between systems is the last missing part to the redelegation problem. Right now, we can have an authorized client request a new access token with an equal or lesser scope and be granted that with no user interaction. That token can then be handed, using the below or similar mechanism, to another system for its own access. I'm assuming this would work with tokens containing a secret part (to be used for signing) as well as plain bearer tokens, too. -- Justin On Mon, 2010-10-18 at 12:03 -0400, Niklas Neumann wrote: > Hello everybody, > > I am currently working on a projected related to authentication and > secure token transfer between multiple devices. As such we are employing > a simple protocol that handles token transfers independent of the actual > type of token. We have adapted the protocol to be used with OAuth tokens > and submitted it as an Internet Draft: > http://tools.ietf.org/html/draft-neumann-oauth-token-transfer > > I was wondering if there is interest in employing such a protocol in > cases where the HTTP redirection schemes of OAuth are not available or > not working well (e.g. desktop applications without access to a user > agent or authentication from a different device/application than the one > accessing the consumer). > > Compared to other proposals such as > draft-dehora-farrell-oauth-accesstoken-creds the STTP is more > heavyweight but in turn it also has more options. With regards to > authentication we didn't use SASL for complexity reasons in our work > initialy but I don't see any reason not to include it if this is deemed > more appropriate. > > The work that the draft is based on is still ongoing. Please understand > the draft as no more than a discussion proposal on how OAuth could be > opened to non-web-based environments and scenarios that involve multiple > devices without overloading the OAuth specification itself. I am happy > to further improve the draft if you think this might be a viable option. > > Best regards > Niklas > From igor.faynberg@alcatel-lucent.com Mon Oct 18 09:46:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AD73A6E34 for ; Mon, 18 Oct 2010 09:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wirKfu7Tt0tQ for ; Mon, 18 Oct 2010 09:46:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D49F13A6E33 for ; Mon, 18 Oct 2010 09:46:16 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9IGlerQ016493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Oct 2010 11:47:40 -0500 (CDT) Received: from [135.244.40.89] (faynberg.lra.lucent.com [135.244.40.89]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o9IGlcti024696; Mon, 18 Oct 2010 11:47:39 -0500 (CDT) Message-ID: <4CBC7A2A.70405@alcatel-lucent.com> Date: Mon, 18 Oct 2010 12:47:38 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Niklas Neumann References: <4CBC6FC0.5040708@cs.uni-goettingen.de> In-Reply-To: <4CBC6FC0.5040708@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:46:22 -0000 Niklas Neumann wrote: > ... > I was wondering if there is interest in employing such a protocol in > cases where the HTTP redirection schemes of OAuth are not available or > not working well (e.g. desktop applications without access to a user > agent or authentication from a different device/application than the > one accessing the consumer). A lot of interest on my part. Igor From mscurtescu@google.com Mon Oct 18 16:19:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182133A6B17 for ; Mon, 18 Oct 2010 16:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.088 X-Spam-Level: X-Spam-Status: No, score=-104.088 tagged_above=-999 required=5 tests=[AWL=1.889, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1WoA7W6IAay for ; Mon, 18 Oct 2010 16:18:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 086E93A6AB6 for ; Mon, 18 Oct 2010 16:18:42 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o9INKAPA012049 for ; Mon, 18 Oct 2010 16:20:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287444011; bh=ykSbik6gUo3bEg5xXqH+CYRexf4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=O60f0Qb+xR7o5xk+4OpiAf1vdupLXYKgblI6qBsTCmSBvcU90nc6cMolJrqm9E+j3 qqT01N+tyuQ/8f/avUr8g== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by kpbe11.cbf.corp.google.com with ESMTP id o9INK96A013094 for ; Mon, 18 Oct 2010 16:20:09 -0700 Received: by yxt3 with SMTP id 3so931377yxt.34 for ; Mon, 18 Oct 2010 16:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=jcwO8vSN+HmMYCNUjydMuERZ9JwwpkdnVNHgW0co6XQ=; b=hnaR7ONfOCn/M6f6/p5LmXLTHX6S/KHI0sFfA55G4iIWlF5I+nMBq1zZVRH8Mqy2EA +dZWypK1GDRUxmIwuzuA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=IcZ1yxhkbfdPvPmZOKgo4TwuAHIzOK+Q0JxMVvhSzO3BGvs2Fo+R0cAAoFRSaQbpSr lpI2D46C+1nw120pDzHg== Received: by 10.100.37.7 with SMTP id k7mr3340093ank.85.1287444008863; Mon, 18 Oct 2010 16:20:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.123.19 with HTTP; Mon, 18 Oct 2010 16:19:48 -0700 (PDT) In-Reply-To: <4CBC6FC0.5040708@cs.uni-goettingen.de> References: <4CBC6FC0.5040708@cs.uni-goettingen.de> From: Marius Scurtescu Date: Mon, 18 Oct 2010 16:19:48 -0700 Message-ID: To: Niklas Neumann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:19:04 -0000 Trying to imagine a real world use case. For example, section 2.2, how would the public terminal know that a user device exists, let alone where? Thanks, Marius On Mon, Oct 18, 2010 at 9:03 AM, Niklas Neumann wrote: > Hello everybody, > > I am currently working on a projected related to authentication and secur= e > token transfer between multiple devices. As such we are employing a simpl= e > protocol that handles token transfers independent of the actual type of > token. We have adapted the protocol to be used with OAuth tokens and > submitted it as an Internet Draft: > http://tools.ietf.org/html/draft-neumann-oauth-token-transfer > > I was wondering if there is interest in employing such a protocol in case= s > where the HTTP redirection schemes of OAuth are not available or not work= ing > well (e.g. desktop applications without access to a user agent or > authentication from a different device/application than the one accessing > the consumer). > > Compared to other proposals such as > draft-dehora-farrell-oauth-accesstoken-creds the STTP is more heavyweight > but in turn it also has more options. With regards to authentication we > didn't use SASL for complexity reasons in our work initialy but I don't s= ee > any reason not to include it if this is deemed more appropriate. > > The work that the draft is based on is still ongoing. Please understand t= he > draft as no more than a discussion proposal on how OAuth could be opened = to > non-web-based environments and scenarios that involve multiple devices > without overloading the OAuth specification itself. I am happy to further > improve the draft if you think this might be a viable option. > > Best regards > =A0Niklas > > -- > Niklas Neumann - University of Goettingen, Institute of Computer Science > http://user.informatik.uni-goettingen.de/~nneuman1/ > Tel: +49 551 39-172053 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From niklas.neumann@cs.uni-goettingen.de Tue Oct 19 00:40:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FF63A6C33 for ; Tue, 19 Oct 2010 00:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shxwtadVLqfC for ; Tue, 19 Oct 2010 00:40:42 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id 510B93A6C1E for ; Tue, 19 Oct 2010 00:40:41 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P86pg-00029G-V7; Tue, 19 Oct 2010 09:42:05 +0200 Message-ID: <4CBD4BD0.2030900@cs.uni-goettingen.de> Date: Tue, 19 Oct 2010 09:42:08 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Marius Scurtescu References: <4CBC6FC0.5040708@cs.uni-goettingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 07:40:45 -0000 In the project I am working on we are using discovery based on dynamic DNS but there probably are better ways. I felt that the discovery was rather application specific and didn't really fit into the draft but I am happy to expand if you think that will make things more clear. Currently our (project-specific) workflow is something like this: User wants to use (untrusted) public terminal to access a private resource. Instead of his username he inputs his authentication device address (i.e. DNS name of his mobile). Either the terminal or the server (depending on where the protocol is supported) uses the address to run STTP and then just substitutes the tokens STTP delivers as the user's credentials. The difference to a "normal" authentication is that all the "magic" is happening on the mobile device where the user is comfortable enough to use his actual credentials. For example, the device can use a service-specific API (or actually STTP again) to retrieve a one-time password that can be used (somewhat) safely on the public terminal. Facebook just started a service to send people otps to their mobile phone via text messages (http://blog.facebook.com/blog.php?post=436800707130) which could be easily expanded to a more seamless (and world-wide available) authentication scenario using STTP (I am not affiliated with Facebook in any way, it's just an example). Best regards Niklas On 10/19/2010 01:19 AM, Marius Scurtescu wrote: > Trying to imagine a real world use case. > > For example, section 2.2, how would the public terminal know that a > user device exists, let alone where? > > Thanks, > Marius > > > > On Mon, Oct 18, 2010 at 9:03 AM, Niklas Neumann > wrote: >> Hello everybody, >> >> I am currently working on a projected related to authentication and secure >> token transfer between multiple devices. As such we are employing a simple >> protocol that handles token transfers independent of the actual type of >> token. We have adapted the protocol to be used with OAuth tokens and >> submitted it as an Internet Draft: >> http://tools.ietf.org/html/draft-neumann-oauth-token-transfer >> >> I was wondering if there is interest in employing such a protocol in cases >> where the HTTP redirection schemes of OAuth are not available or not working >> well (e.g. desktop applications without access to a user agent or >> authentication from a different device/application than the one accessing >> the consumer). >> >> Compared to other proposals such as >> draft-dehora-farrell-oauth-accesstoken-creds the STTP is more heavyweight >> but in turn it also has more options. With regards to authentication we >> didn't use SASL for complexity reasons in our work initialy but I don't see >> any reason not to include it if this is deemed more appropriate. >> >> The work that the draft is based on is still ongoing. Please understand the >> draft as no more than a discussion proposal on how OAuth could be opened to >> non-web-based environments and scenarios that involve multiple devices >> without overloading the OAuth specification itself. I am happy to further >> improve the draft if you think this might be a viable option. >> >> Best regards >> Niklas >> >> -- >> Niklas Neumann - University of Goettingen, Institute of Computer Science >> http://user.informatik.uni-goettingen.de/~nneuman1/ >> Tel: +49 551 39-172053 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From gffletch@aol.com Tue Oct 19 11:14:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61153A6882 for ; Tue, 19 Oct 2010 11:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em0dVqGmTayN for ; Tue, 19 Oct 2010 11:14:27 -0700 (PDT) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by core3.amsl.com (Postfix) with ESMTP id 4D16A3A67AB for ; Tue, 19 Oct 2010 11:14:27 -0700 (PDT) Received: from mtaout-da02.r1000.mx.aol.com (mtaout-da02.r1000.mx.aol.com [172.29.51.130]) by imr-da02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o9JIFkYN024381; Tue, 19 Oct 2010 14:15:46 -0400 Received: from palantir.local (unknown [10.172.2.144]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1B3AAE0002AB; Tue, 19 Oct 2010 14:15:42 -0400 (EDT) Message-ID: <4CBDE04C.1000500@aol.com> Date: Tue, 19 Oct 2010 14:15:40 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: oauth@ietf.org References: <4CBC6FC0.5040708@cs.uni-goettingen.de> In-Reply-To: <4CBC6FC0.5040708@cs.uni-goettingen.de> Content-Type: multipart/alternative; boundary="------------020409070901000401020001" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:421673056:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33824cbde04e4019 X-AOL-IP: 10.172.2.144 Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:14:29 -0000 This is a multi-part message in MIME format. --------------020409070901000401020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Question on the Reflection-Key parameter when it is generated from the source IP and port pair. Is the server receiving the request supposed to verify that the data in the Reflection-Key matches the data of the inbound connection? If so, then I think NAT'ing firewalls, proxies and network SSL off-loaders (e.g. netscalers) will break the security mechanism. Thanks, George On 10/18/10 12:03 PM, Niklas Neumann wrote: > Hello everybody, > > I am currently working on a projected related to authentication and > secure token transfer between multiple devices. As such we are > employing a simple protocol that handles token transfers independent > of the actual type of token. We have adapted the protocol to be used > with OAuth tokens and submitted it as an Internet Draft: > http://tools.ietf.org/html/draft-neumann-oauth-token-transfer > > I was wondering if there is interest in employing such a protocol in > cases where the HTTP redirection schemes of OAuth are not available or > not working well (e.g. desktop applications without access to a user > agent or authentication from a different device/application than the > one accessing the consumer). > > Compared to other proposals such as > draft-dehora-farrell-oauth-accesstoken-creds the STTP is more > heavyweight but in turn it also has more options. With regards to > authentication we didn't use SASL for complexity reasons in our work > initialy but I don't see any reason not to include it if this is > deemed more appropriate. > > The work that the draft is based on is still ongoing. Please > understand the draft as no more than a discussion proposal on how > OAuth could be opened to non-web-based environments and scenarios that > involve multiple devices without overloading the OAuth specification > itself. I am happy to further improve the draft if you think this > might be a viable option. > > Best regards > Niklas > --------------020409070901000401020001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Question on the Reflection-Key parameter when it is generated from the source IP and port pair. Is the server receiving the request supposed to verify that the data in the Reflection-Key matches the data of the inbound connection? If so, then I think NAT'ing firewalls, proxies and network SSL off-loaders (e.g. netscalers) will break the security mechanism.

Thanks,
George

On 10/18/10 12:03 PM, Niklas Neumann wrote:
Hello everybody,

I am currently working on a projected related to authentication and secure token transfer between multiple devices. As such we are employing a simple protocol that handles token transfers independent of the actual type of token. We have adapted the protocol to be used with OAuth tokens and submitted it as an Internet Draft: http://tools.ietf.org/html/draft-neumann-oauth-token-transfer

I was wondering if there is interest in employing such a protocol in cases where the HTTP redirection schemes of OAuth are not available or not working well (e.g. desktop applications without access to a user agent or authentication from a different device/application than the one accessing the consumer).

Compared to other proposals such as draft-dehora-farrell-oauth-accesstoken-creds the STTP is more heavyweight but in turn it also has more options. With regards to authentication we didn't use SASL for complexity reasons in our work initialy but I don't see any reason not to include it if this is deemed more appropriate.

The work that the draft is based on is still ongoing. Please understand the draft as no more than a discussion proposal on how OAuth could be opened to non-web-based environments and scenarios that involve multiple devices without overloading the OAuth specification itself. I am happy to further improve the draft if you think this might be a viable option.

Best regards
  Niklas


--------------020409070901000401020001-- From beaton@google.com Wed Oct 20 10:12:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6003A68B8 for ; Wed, 20 Oct 2010 10:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.288 X-Spam-Level: X-Spam-Status: No, score=-104.288 tagged_above=-999 required=5 tests=[AWL=1.689, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuJlNafKIufK for ; Wed, 20 Oct 2010 10:12:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9CA3D3A68A4 for ; Wed, 20 Oct 2010 10:12:04 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o9KHDaq1020174 for ; Wed, 20 Oct 2010 10:13:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287594817; bh=xlIk0sY6ro6VFNvywkDTyK1m+uI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=wnTlBjvXQBK7K3V5eQpzo9dyu/W+IhBvgcXQL+Y81kmrvL3VzXE+x59qEsvia2xuY dB1xopVyOW1UUKLGa/CxQ== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by kpbe15.cbf.corp.google.com with ESMTP id o9KHDZgC010350 for ; Wed, 20 Oct 2010 10:13:35 -0700 Received: by pwi2 with SMTP id 2so222101pwi.8 for ; Wed, 20 Oct 2010 10:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wu4OmztEtAtN5VqH33jHqE9yA7BDitULVZCS6g42JWU=; b=Yqy/wg67QHDivrJ0kV0XYLyvSJ8aUn8SXXyLNJIY9fXC2NO0OmzClr19dmdtmJW4EM sxg4JX4jbq0GVAkKps9Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qDM3vHyPJirAHcGZz41+a9RVkY10N+/RLJjFvF1ovJbSSLBDLIDajS973RuRk8/hr4 MLTV0ftZ8t+RVdh8Ip4w== MIME-Version: 1.0 Received: by 10.142.166.4 with SMTP id o4mr1996525wfe.58.1287594815029; Wed, 20 Oct 2010 10:13:35 -0700 (PDT) Received: by 10.142.187.13 with HTTP; Wed, 20 Oct 2010 10:13:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> Date: Wed, 20 Oct 2010 10:13:34 -0700 Message-ID: From: Brian Eaton To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:12:08 -0000 On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones wrote: > I am willing to serve as editor for the bearer token specification and ha= ve my > management's approval to do so. =A0Furthermore, I believe that I am quali= fied, > having successfully served as an editor for several standards specificati= ons, > including the OASIS IMI specification and related SAML token profiles, th= e > OpenID PAPE specification, and (some time ago), the POSIX Threads standar= d. Thanks Mike! This sounds great. From igor.faynberg@alcatel-lucent.com Wed Oct 20 10:28:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7423A3A69E8 for ; Wed, 20 Oct 2010 10:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiOrCNaGONSx for ; Wed, 20 Oct 2010 10:28:01 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 882083A68F6 for ; Wed, 20 Oct 2010 10:28:01 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o9KHTWj4016747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 12:29:32 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o9KHTVVg005070; Wed, 20 Oct 2010 12:29:32 -0500 (CDT) Message-ID: <4CBF26FB.4080004@alcatel-lucent.com> Date: Wed, 20 Oct 2010 13:29:31 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:28:02 -0000 Hannes, As it might be expected, I am interested in discussing OAuth security, and this is one reason I have been looking forward to meeting OAuthers--Torsten in particular. Whether this is going to be a formal or informal meeting is of no real importance to me (and actually I don't know the difference, for even formal WG meetings don't make decisions). If we have more time, this is even better! Igor Hannes Tschofenig wrote: > Hi all, > > please drop me a mail if you plan to travel to Beijing and if you are interested to chat about OAuth. We have no time restrictions (unlike with working group meetings) and so we could go into the details of any topic. I personally would be interested to do some OAuth security work. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Wed Oct 20 11:53:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BE73A681B for ; Wed, 20 Oct 2010 11:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.187 X-Spam-Level: X-Spam-Status: No, score=-104.187 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C991YvcmZoP2 for ; Wed, 20 Oct 2010 11:53:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 284813A67D9 for ; Wed, 20 Oct 2010 11:53:44 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o9KItIZN008893 for ; Wed, 20 Oct 2010 11:55:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287600918; bh=WayEPV2bBj8iARtI5mRvRKzjwFE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=hVewtR51fGXp9mVR4ohUUBYtdb+/TEBCYnb2C0UB9AwIq+pJY1Z4rkAjgXncIi/Pu XyY046WpbK/n8oOBPizlQ== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by hpaq13.eem.corp.google.com with ESMTP id o9KIsGMl000817 for ; Wed, 20 Oct 2010 11:55:17 -0700 Received: by gyg8 with SMTP id 8so2792042gyg.26 for ; Wed, 20 Oct 2010 11:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=nzwBK1AEdwsko4C1EcFAJTPNRZGdkyInsoTdA+0/sqQ=; b=RD88DhRJ+NCuG7EtfDVepwVF7mX9eqYRhAAp4M/f8CeTD03mmxaMIBbxZR83whqah6 s1f6qa82rAKPNsqTA5Tw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=njkJ5H2/4k4+4Wv2IOri6HhTOkvUgGkKJLxv7rupdN6IjKSjByD7vO3vWS2GIkMj4y 8LaMTyJRyYApGfIEWq2A== Received: by 10.101.82.10 with SMTP id j10mr5715274anl.245.1287600916658; Wed, 20 Oct 2010 11:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.136.3 with HTTP; Wed, 20 Oct 2010 11:54:56 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Wed, 20 Oct 2010 11:54:56 -0700 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 18:53:46 -0000 +1 On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones wrote: > I am willing to serve as editor for the bearer token specification and ha= ve my management's approval to do so. =A0Furthermore, I believe that I am q= ualified, having successfully served as an editor for several standards spe= cifications, including the OASIS IMI specification and related SAML token p= rofiles, the OpenID PAPE specification, and (some time ago), the POSIX Thre= ads standard. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Blaine Cook > Sent: Wednesday, October 13, 2010 5:32 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for Consensus on Document Split > > Over the past few weeks, the working group debated the issues around the = introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current spec= ification into two parts: one including section 5 (bearer token) and the ot= her including the rest (how to obtain a token), with an additional specific= ation covering signature use cases. > > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if anyon= e has any concerns or objections against this proposal. > > In addition, the chairs are seeking a volunteer to take over the bearer t= oken specification (section 5) as editor. > > Please submit your comments by Wednesday, October 20th. > > - The OAuth Working Group Chairs From keith@nearlyfree.org Wed Oct 20 21:23:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8937F3A6944 for ; Wed, 20 Oct 2010 21:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzlkpByPLF8f for ; Wed, 20 Oct 2010 21:23:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3B0743A68CF for ; Wed, 20 Oct 2010 21:23:26 -0700 (PDT) Received: by bwz12 with SMTP id 12so113975bwz.31 for ; Wed, 20 Oct 2010 21:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.77.212 with SMTP id h20mr269351bkk.33.1287635100703; Wed, 20 Oct 2010 21:25:00 -0700 (PDT) Received: by 10.204.121.79 with HTTP; Wed, 20 Oct 2010 21:25:00 -0700 (PDT) Date: Wed, 20 Oct 2010 21:25:00 -0700 Message-ID: From: Keith Grennan To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001485f1e348c71afa049318e851 Subject: [OAUTH-WG] OAuth 2.0 Perl client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 04:23:28 -0000 --001485f1e348c71afa049318e851 Content-Type: text/plain; charset=ISO-8859-1 Hello, Just wanted to let you know that there's an OAuth client library available for Perl. It's a pretty close port of the Ruby 'oauth2' gem, so far supporting just the web server profile, and the authorization code method of getting the access token. Works great with the 37signals and Facebook APIs. Looking for more servers to test against - is there a list of them anywhere? For more information: GitHub: http://github.com/keeth/Net-OAuth2 CPAN: http://search.cpan.org/perldoc?Net::OAuth2 Very basic demo: http://oauth.kg23.com OAuth 2.0 is awesome! Thanks for all your hard work. Best, Keith --001485f1e348c71afa049318e851 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Just wanted to let you know that there's an O= Auth client library available for Perl.

It's a= pretty close port of the Ruby 'oauth2' gem, so far supporting just= the web server profile, and the=A0authorization=A0code method of getting t= he access token.

Works great with the 37signals and Facebook APIs. =A0Lo= oking for more servers to test against - is there a list of them anywhere?<= /div>

For more information:




OAuth 2.0 is awesome! =A0Tha= nks for all your hard work.

Best,
Keith<= /div>
--001485f1e348c71afa049318e851-- From eran@hueniverse.com Wed Oct 20 22:55:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729223A6987 for ; Wed, 20 Oct 2010 22:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+bYgji4aYCl for ; Wed, 20 Oct 2010 22:55:05 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7A7B33A6973 for ; Wed, 20 Oct 2010 22:55:05 -0700 (PDT) Received: (qmail 25026 invoked from network); 21 Oct 2010 05:56:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Oct 2010 05:56:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 20 Oct 2010 22:56:38 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Mike Jones Date: Wed, 20 Oct 2010 22:56:35 -0700 Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: ActwiFxzp9HdMnUmRay4Vt+jFE86wAAW9iuA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D46A5847D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 05:55:08 -0000 This is not a comment about Mike's generous offer. Choosing an editor is the sole discretion of the chairs. While the working = group can offer the chairs feedback, it is best done directly because of th= e personal nature of selecting people. At the end, the chairs choose the pe= rson they want for the role. I just want to make sure people understand how= this works, and to avoid debating roles in the same way we argue about tec= hnical details. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Wednesday, October 20, 2010 11:55 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >=20 > +1 >=20 >=20 > On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones > wrote: > > I am willing to serve as editor for the bearer token specification and = have > my management's approval to do so. =A0Furthermore, I believe that I am > qualified, having successfully served as an editor for several standards > specifications, including the OASIS IMI specification and related SAML to= ken > profiles, the OpenID PAPE specification, and (some time ago), the POSIX > Threads standard. > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Blaine Cook > > Sent: Wednesday, October 13, 2010 5:32 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Call for Consensus on Document Split > > > > Over the past few weeks, the working group debated the issues around > the introduction of signatures and the structure of the specification. > > The working group seems to endorse the proposal to split the current > specification into two parts: one including section 5 (bearer token) and = the > other including the rest (how to obtain a token), with an additional > specification covering signature use cases. > > > > This serves as a call for consensus on the proposed editorial work. > > Before we proceed with the changes, the chairs would like to ask if any= one > has any concerns or objections against this proposal. > > > > In addition, the chairs are seeking a volunteer to take over the bearer > token specification (section 5) as editor. > > > > Please submit your comments by Wednesday, October 20th. > > > > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From romeda@gmail.com Wed Oct 20 23:25:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C99D3A6954 for ; Wed, 20 Oct 2010 23:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iN4coFCKfam for ; Wed, 20 Oct 2010 23:25:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 324D33A6873 for ; Wed, 20 Oct 2010 23:25:11 -0700 (PDT) Received: by wwf26 with SMTP id 26so2155827wwf.13 for ; Wed, 20 Oct 2010 23:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=EjO6OHcXP5FaEA4YRdilUExzTt0LLR/zfKkBA5SuUX8=; b=iNeQcXArxznliulWwkL7sc3I/x9gMUxQBdkkpnVlmUUAOuFIlgmI5BVyW6JRPMy/eQ omJwro0bE7SsdSnXl5EWh4rI5lx2jWkME4fcd7Ti5nr9BKYR75PKQA4Fioi+36YW1lc/ FGElY3GTvISllVXoSHOEsBJA/qubXRmTPBaWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=GFSKS1JhT+DeDlhMx8wfYJpmB8mWLZXzr0GL5RZXki1S8Wa2144vWf/CHY2t3b/SIM rwu70+xd7gOF1ujDV04WnPMOZnP68MMSDPkmXjnuiZ2FS0ayeZUvwXUFN4AC5h2eWQjl wP+5XwHHG5CxUD6DBTxJldALVFKQ94rnouP9M= Received: by 10.216.138.65 with SMTP id z43mr520202wei.12.1287642400912; Wed, 20 Oct 2010 23:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.68.194 with HTTP; Wed, 20 Oct 2010 23:26:20 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D46A5847D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739431D4FCC3E@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D46A5847D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Wed, 20 Oct 2010 23:26:20 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 06:25:21 -0000 On that process note, does anyone OBJECT to splitting the draft as described? The call closes in about an hour, depending on which time zone you're in. If we don't hear objections by mid-day PST tomorrow (the 21st), I think it's safe to say we have consensus on this issue. b. On 20 October 2010 22:56, Eran Hammer-Lahav wrote: > This is not a comment about Mike's generous offer. > > Choosing an editor is the sole discretion of the chairs. While the workin= g group can offer the chairs feedback, it is best done directly because of = the personal nature of selecting people. At the end, the chairs choose the = person they want for the role. I just want to make sure people understand h= ow this works, and to avoid debating roles in the same way we argue about t= echnical details. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Wednesday, October 20, 2010 11:55 AM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >> >> +1 >> >> >> On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones >> wrote: >> > I am willing to serve as editor for the bearer token specification and= have >> my management's approval to do so. =C2=A0Furthermore, I believe that I a= m >> qualified, having successfully served as an editor for several standards >> specifications, including the OASIS IMI specification and related SAML t= oken >> profiles, the OpenID PAPE specification, and (some time ago), the POSIX >> Threads standard. >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike >> > >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Blaine Cook >> > Sent: Wednesday, October 13, 2010 5:32 PM >> > To: oauth@ietf.org >> > Subject: [OAUTH-WG] Call for Consensus on Document Split >> > >> > Over the past few weeks, the working group debated the issues around >> the introduction of signatures and the structure of the specification. >> > The working group seems to endorse the proposal to split the current >> specification into two parts: one including section 5 (bearer token) and= the >> other including the rest (how to obtain a token), with an additional >> specification covering signature use cases. >> > >> > This serves as a call for consensus on the proposed editorial work. >> > Before we proceed with the changes, the chairs would like to ask if an= yone >> has any concerns or objections against this proposal. >> > >> > In addition, the chairs are seeking a volunteer to take over the beare= r >> token specification (section 5) as editor. >> > >> > Please submit your comments by Wednesday, October 20th. >> > >> > - The OAuth Working Group Chairs >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From niklas.neumann@cs.uni-goettingen.de Thu Oct 21 02:06:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35A03A681A for ; Thu, 21 Oct 2010 02:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j0Au-otY24p for ; Thu, 21 Oct 2010 02:06:18 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id 108A73A689D for ; Thu, 21 Oct 2010 02:06:18 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P8r7l-0000E5-E0; Thu, 21 Oct 2010 11:07:49 +0200 Message-ID: <4CC002E4.9090701@cs.uni-goettingen.de> Date: Thu, 21 Oct 2010 11:07:48 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: George Fletcher References: <4CBC6FC0.5040708@cs.uni-goettingen.de> <4CBDE04C.1000500@aol.com> In-Reply-To: <4CBDE04C.1000500@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Transfer Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 09:06:20 -0000 Yes the server is supposed to verify the Reflection-Key. Regarding any middleboxes, the Reflection-Key from the server's perspective is a somewhat static value and therefore can be configured on an application level rather than being determined dynamically. Specifically, if load-balancers or off-loaders are used, the mechanism still works if the application has been configured to check the Reflection-Key against a list of valid source IP/port pairs or public certificate fingerprints that are externally or statically supplied rather than determining the values itself. I hope this clear things up. Best regards Niklas On 10/19/2010 08:15 PM, George Fletcher wrote: > Question on the Reflection-Key parameter when it is generated from the > source IP and port pair. Is the server receiving the request supposed to > verify that the data in the Reflection-Key matches the data of the > inbound connection? If so, then I think NAT'ing firewalls, proxies and > network SSL off-loaders (e.g. netscalers) will break the security mechanism. > > Thanks, > George > > On 10/18/10 12:03 PM, Niklas Neumann wrote: >> Hello everybody, >> >> I am currently working on a projected related to authentication and >> secure token transfer between multiple devices. As such we are >> employing a simple protocol that handles token transfers independent >> of the actual type of token. We have adapted the protocol to be used >> with OAuth tokens and submitted it as an Internet Draft: >> http://tools.ietf.org/html/draft-neumann-oauth-token-transfer >> >> I was wondering if there is interest in employing such a protocol in >> cases where the HTTP redirection schemes of OAuth are not available or >> not working well (e.g. desktop applications without access to a user >> agent or authentication from a different device/application than the >> one accessing the consumer). >> >> Compared to other proposals such as >> draft-dehora-farrell-oauth-accesstoken-creds the STTP is more >> heavyweight but in turn it also has more options. With regards to >> authentication we didn't use SASL for complexity reasons in our work >> initialy but I don't see any reason not to include it if this is >> deemed more appropriate. >> >> The work that the draft is based on is still ongoing. Please >> understand the draft as no more than a discussion proposal on how >> OAuth could be opened to non-web-based environments and scenarios that >> involve multiple devices without overloading the OAuth specification >> itself. I am happy to further improve the draft if you think this >> might be a viable option. >> >> Best regards >> Niklas >> > -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From zachary.zeltsan@alcatel-lucent.com Thu Oct 21 09:16:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B5C3A6870 for ; Thu, 21 Oct 2010 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6QMsLpO0Wca for ; Thu, 21 Oct 2010 09:16:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D1E8C3A6A16 for ; Thu, 21 Oct 2010 09:16:47 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o9LGILlo022112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 11:18:21 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9LGIKbd001647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Oct 2010 11:18:21 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 21 Oct 2010 11:18:20 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Hannes Tschofenig'" , "oauth@ietf.org" Date: Thu, 21 Oct 2010 11:18:19 -0500 Thread-Topic: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) Thread-Index: ActsaK20op4e8Is4S3ycplz2LVYsCAE0m5SA Message-ID: <5710F82C0E73B04FA559560098BF95B124FB23344A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:16:52 -0000 Hannes, I plan to be in Beijing and am interested in security topic. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, October 15, 2010 8:58 AM To: oauth@ietf.org Subject: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) Hi all,=20 please drop me a mail if you plan to travel to Beijing and if you are inter= ested to chat about OAuth. We have no time restrictions (unlike with workin= g group meetings) and so we could go into the details of any topic. I perso= nally would be interested to do some OAuth security work. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Martin.Thomson@andrew.com Thu Oct 21 15:34:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD073A672E for ; Thu, 21 Oct 2010 15:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qlAY-3leBLM for ; Thu, 21 Oct 2010 15:34:35 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1D2213A63EC for ; Thu, 21 Oct 2010 15:34:35 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:41938 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S459607Ab0JUWgL (ORCPT ); Thu, 21 Oct 2010 17:36:11 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 21 Oct 2010 17:36:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 22 Oct 2010 06:36:06 +0800 From: "Thomson, Martin" To: "oauth@ietf.org" , Blaine Cook Date: Fri, 22 Oct 2010 06:36:03 +0800 Thread-Topic: OAuth abstractions Thread-Index: ActxcFepJkAX4TmLREi76+eteSP7XQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EABAD@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [OAUTH-WG] OAuth abstractions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 22:34:38 -0000 QXQgdGhlIGxhc3QgbWVldGluZywgSSBwcm9taXNlZCBCbGFpbmUgdGhhdCBJJ2Qgc2hhcmUgYSBm ZXcgdGhvdWdodHMgb24gaG93IEkgdW5kZXJzdG9vZCBPQXV0aCB0byBvcGVyYXRlLiAgSXQncyB0 YWtlbiBtZSBhIHdoaWxlIHRvIGZpbmQgdGhlIHRpbWUgdG8gbWFyc2hhbCBteSB0aG91Z2h0cywg YnV0IGhlcmUgJ3Rpcy4NCg0KQWZ0ZXIgYXR0ZW5kaW5nIHRoZSBtZWV0aW5nIGFuZCB0dXRvcmlh bCwgaXQgd2FzIGNsZWFyIHRoYXQgdGhlIGFic3RyYWN0aW9uIGJlaGluZCBPQXV0aCBpcyBub3Qg YmVpbmcgZWZmZWN0aXZlbHkgY29tbXVuaWNhdGVkLiAgQSBzaW1wbGUgYWJzdHJhY3Rpb24gY2Fu IGJlIGEgcG93ZXJmdWwgdG9vbCBpbiBkZWFsaW5nIHdpdGggYSBjb21wbGV4IHNwZWNpZmljYXRp b24uICBJdCBzZWVtcyB0byBtZSB0aGF0IE9BdXRoIHN0cnVnZ2xlcyBhcyBhIHJlc3VsdCBvZiB0 cnlpbmcgdG8gY292ZXIgc28gbWFueSB1c2UgY2FzZXMgYXQgb25jZS4gIFRoaXMgbWlnaHQgYmUg ZWFzaWVyIGlmIHRoZSBhYnN0cmFjdCBtb2RlbCB3ZXJlIGJldHRlciB1bmRlcnN0b29kLg0KDQpJ IGJlbGlldmUgdGhhdCBPQXV0aCBoYXMgYSB2ZXJ5IHNpbXBsZSBhYnN0cmFjdGlvbi4gIFdoYXQg SSBhbSBnb2luZyB0byB0cnkgdG8gZG8gaXMgZGVzY3JpYmUgdGhhdCBhYnN0cmFjdGlvbi4gIA0K DQpUaGUgY3VubmluZyB0ZWNobmlxdWVzIGVtcGxveWVkIHRvIGNpcmN1bXZlbnQgdGVjaG5pY2Fs IGxpbWl0YXRpb25zIC0gcmVkaXJlY3Rpb24gd2l0aCBVUkkgZnJhZ21lbnRzIGFuZCBzbyBmb3J0 aCAtIGFyZSBub2lzZSBvbiB0aGUgd2lyZSBhdCB0aGlzIGxheWVyLiAgQXMgYSBuZWNlc3Nhcnkg cHJvZHVjdCBvZiBoYXZpbmcgdG8gcmVkdWNlIHRoZSBhYnN0cmFjdGlvbiB0byBwcmFjdGljZSwg dGhleSBoYXZlIGxpdHRsZSBiZWFyaW5nIG9uIHdoYXQgSSBhbSBnb2luZyB0byBhdHRlbXB0IHRv IGRlc2NyaWJlLg0KDQpJIGFwcHJlY2lhdGUgdGhhdCB0aGUgcHJvY2VzcyBpcyB3ZWxsIGJleW9u ZCB0aGlzIGFpcnktZmFpcnkgc3RhZ2UuICBJZiBub3RoaW5nIGVsc2UsIEkgaG9wZSB0aGF0IHRo aXMgam9zdGxlcyBhIGZldyBicmFpbiBjZWxscyBpbnRvIG5ldyB3YXlzIG9mIGxvb2tpbmcgYXQg T0F1dGguDQoNClRvIHByZWZhY2UgdGhpcyB3aXRoIGEgd2FybmluZzogVGhlcmUncyBiZWVuIGEg bG90IG9mIGRpc2N1c3Npb24gYWJvdXQgdGhlIE9BdXRoICJwcm90b2NvbCIgYW5kIGV4YW1pbmF0 aW9uIG9mIGl0cyBwcm9wZXJ0aWVzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGl0IGJlaW5nIGEg dGhpbmcgdGhhdCAidXNlcyBIVFRQIi4gIFRoZXJlJ3MgYSBsb3Qgb2YgSFRUUCBleHBlcmllbmNl IHRoYXQgdGVhY2hlcyB0aGUgbG9uZyB0ZXJtIGZvbGx5IG9mIHRyeWluZyB0byBidWlsZCBvbiB0 b3Agb2YgSFRUUC4gIEknbSBwcm9iYWJseSBnb2luZyB0byBiZWF0IG9uIGEgZGVhZCBob3JzZSBi eSBleHBsYWluaW5nIHdoZXJlIHdvcmtpbmcgX3dpdGhfIEhUVFAgKGFzIG9wcG9zZWQgdG8gX2Rl c3BpdGVfIGl0KSBoYXMgc2lnbmlmaWNhbnQgYWR2YW50YWdlcy4NCg0KDQo9PUZpcnN0IEFic3Ry YWN0aW9uDQoNCk9BdXRoIHNwZWNpZmllcyBhIHNlcGFyYXRpb24gYmV0d2VlbiBhdXRoZW50aWNh dGlvbiBhbmQgYXV0aG9yaXphdGlvbi4NCg0KTmV2ZXIgbWluZCB0aGF0IEhUVFAgZ290IHRoZXNl IG1peGVkIHVwIGVhcmx5IG9uLCBpdCBkb2Vzbid0IG5vdyAtIEhUVFAgb25seSBwcm92aWRlcyBh dXRoZW50aWNhdGlvbi4gIFRoZSAiQXV0aG9yaXphdGlvbiIgaGVhZGVyIGlzIGZvciBhdXRoZW50 aWNhdGlvbi4gIFRoYXQgbWlnaHQgYmUgaW1wbGljaXRseSB1c2VkIHRvIGluZmVyIGF1dGhvcml6 YXRpb24sIGJ1dCBpdCdzIHN0aWxsIGZ1bmRhbWVudGFsbHkganVzdCBhdXRoZW50aWNhdGlvbi4N Cg0KT0F1dGggbGV0cyBhIENsaWVudCBjb21lIHRvIGEgUmVzb3VyY2UgU2VydmVyIHdpdGggc2Vw YXJhdGUgZXZpZGVuY2UgZm9yIGlkZW50aXR5IGFuZCBhdXRob3JpemF0aW9uLg0KDQo9PUdvYWwN Cg0KQSBDbGllbnQncyBnb2FsIGlzIHRvIGFjcXVpcmUgYSByZXNvdXJjZSBmcm9tIHRoZSBSZXNv dXJjZSBTZXJ2ZXIuICBPciwgdG8gYmUgbW9yZSBnZW5lcmFsLCB0byBzdWNjZXNzZnVsbHkgY29t cGxldGUgYSBwYXJ0aWN1bGFyIHR5cGUgb2YgKEhUVFApIHJlcXVlc3QuDQoNCkluIG9yZGVyIHRv IGRvIHRoaXMsIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBzdWZmaWNpZW50LCB0aGUgQ2xpZW50IG11 c3QgYWxzbyBwcm92ZSB0aGF0IGl0IGlzIGF1dGhvcml6ZWQuDQoNClRoZSBDbGllbnQgbWlnaHQg YmUga25vd24gdG8gdGhlIFJlc291cmNlIFNlcnZlci4gIFRoaXMgaXMgdGhlIGF1dGhlbnRpY2F0 aW9uIHBhcnQuICBUaGVyZSBhcmUgZXhpc3RpbmcgbWVjaGFuaXNtcyBmb3IgdGhhdCAodGhlIGlk ZWEgdGhhdCB0aGVzZSBtaWdodCBiZSBpbXByb3ZlZCBpcyBhIHN1YmplY3QgdGhhdCBjb21lcyB1 cCBvbiBvY2Nhc2lvbikuICBbMV0NCg0KPT1Qcm92aW5nIEF1dGhvcml6YXRpb24NCg0KT25jZSB0 aGUgQ2xpZW50IGlzIGF1dGhlbnRpY2F0ZWQgKG9yIG5vdCkgdGhlIFJlc291cmNlIFNlcnZlciBt aWdodCBzdGlsbCByZWplY3QgdGhlIHJlcXVlc3QuICBUaGVyZSdzIGFuIEhUVFAgNDAzIChGb3Ji aWRkZW4pIHJlc3BvbnNlIGZvciB0aGlzIHB1cnBvc2UuDQoNCklmIHRoaXMgd2VyZSBhdCBhbGwg bGlrZSBhbiBIVFRQIDQwMSByZXNwb25zZSwgdGhhdCByZWplY3Rpb24gY291bGQgcHJvdmlkZSB0 aGUgY2x1ZXMgdGhhdCBjb3VsZCBiZSB1c2VkIGJ5IHRoZSBDbGllbnQgdG8gZGV0ZXJtaW5lIGhv dyB0byBhY3F1aXJlIGV2aWRlbmNlIG9mIGF1dGhvcml6YXRpb24gKHdoYXQgT0F1dGggY2FsbHMg dGhlIEFjY2VzcyBUb2tlbikuICANCg0KSSBkb24ndCBrbm93IGlmIGFueW9uZSBoYXMgcHJvcG9z ZWQgdGhpcywgYnV0IGl0IHNlZW1zIGxvZ2ljYWwgdG8gZXh0ZW5kIEhUVFAgYW5kIHdvcmsgd2l0 aGluIGl0cyBmcmFtZXdvcmssIHRodXM6DQoNCiAgMS4gQWRkIGEgaGVhZGVyIHRvIHRoZSA0MDMg KEZvcmJpZGRlbikgcmVzcG9uc2UuICBUaGlzIGhlYWRlciB3b3VsZCBpbmRpY2F0ZSB0aGF0IGly cmVzcGVjdGl2ZSBvZiB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCwgZnVydGhlciBldmlkZW5j ZSBvZiBhdXRob3JpemF0aW9uIGlzIHJlcXVpcmVkICh0aGF0IGlzLCBhbiBBY2Nlc3MgVG9rZW4p Lg0KDQogIDIuIEFkZCBhIHJlcXVlc3QgaGVhZGVyIHRoYXQgaXMgaW50ZW5kZWQgdG8gY2Fycnkg YW4gYWNjZXNzIHRva2VuLg0KDQpUaGUgZmlyc3QgbWlnaHQgYmUgYSBsaXR0bGUgY29tcGxleC4g IFVubGlrZSB0aGUgNDAxIHJlc3BvbnNlLCBPQXV0aCBoYXMgYSBudW1iZXIgb2YgdmFyaWF0aW9u cyBvbiBob3cgYW4gQWNjZXNzIFRva2VuIGlzIHJlcXVpcmVkIGFuZCB0aGlzIGNvbnN0cmFpbnMg dGhlIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHJldmVhbGVkIGF0IHRoaXMgcG9pbnQuICANCg0K VGhpcyA0MDMgaGVhZGVyIG1pZ2h0IGluY2x1ZGUgdmlydHVhbGx5IG5vIGNsdWVzIGF0IGFsbC4g IE1heWJlIHRoZSBlcXVpdmFsZW50IG9mICJyZWFsbSIgLSBzb21lIHByaXZhdGUgaWRlbnRpZmll ciB0aGF0IGhlbHBzIHRob3NlIGluIHRoZSBrbm93IGRpc3Rpbmd1aXNoIGJldHdlZW4gb25lIHNl dCBvZiBhdXRob3JpemF0aW9uIHJlcXVpcmVtZW50cyBmcm9tIGFub3RoZXIuICBXaGF0IGluZm9y bWF0aW9uIGlzIHJldmVhbGVkIGRlcGVuZHMgb24gdGhlIGRlc2lyZWQgc2VjdXJpdHkgcHJvcGVy dGllcy4NCg0KPT1BY2Nlc3MgVG9rZW4NCg0KSXQncyB0ZW1wdGluZyB0byBzYXkgdGhhdCB0aGUg QWNjZXNzIFRva2VuIGlzIGNvbXBsZXRlbHkgb3BhcXVlIHRvIGFsbCBidXQgdGhlIEF1dGhvcml6 YXRpb24gU2VydmVyIGFuZCB0aGUgUmVzb3VyY2UgU2VydmVyLiAgQSBwcml2YXRlIGFncmVlbWVu dCBiZXR3ZWVuIHRoZXNlIHBhcnRpZXMgY291bGQgYmUgdXNlZCB0byBkZXRlcm1pbmUgd2hhdCBp bmZvcm1hdGlvbiBpcyBpbmNsdWRlZC4NCg0KSW4gdGhlIGFic3RyYWN0IHNlbnNlLCB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgcmVxdWVzdCBoZWFkZXIgY291bGQganVzdCBwcm92aWRlIGEgYml0IGJ1 Y2tldCBmb3IgYSB0b2tlbi4gIEluIHRoZSBtYWNybywgdGhhdCdzIGFsbCB0aGUgc29sdXRpb24g cmVxdWlyZXMuDQoNCk9idmlvdXNseSwgdGhlIHdvcmsgZG9lc24ndCBzdG9wIHRoZXJlLiAgVG8g aWdub3JlIHRoZSBhY2Nlc3MgdG9rZW4gZW50aXJlbHkgd291bGQgYmUgdHJpdmlhbGl6aW5nIGFs bCB0aGUgd29yayB0aGF0IGhhcyBiZWVuIGRvbmUgaW4gdGhpcyBhcmVhLiAgQSBzZXBhcmF0ZSBh dXRob3JpemF0aW9uIGZ1bmN0aW9uIGlzIGFuIGltcG9ydGFudCBmZWF0dXJlLiAgU3RydWN0dXJl ZCBhZ3JlZW1lbnRzLCBzdWNoIGFzIHRoZSBTQU1MIGFzc2VydGlvbnMsIGhhdmUgYSBzaWduaWZp Y2FudCByb2xlIGFuZCBmb3JtYWxpemluZyBmb3JtYXRzIGNhbiBiZSBleHRyZW1lbHkgcG93ZXJm dWwuDQoNClRoZW4gdGhlcmUgYXJlIHRoZSBzZWN1cml0eSBjb25jZXJucyB0aGF0IGFyaXNlIHdo ZW4geW91IHdhdmUgeW91ciBoYW5kcy4gIFNheWluZyAibWFnaWMgaGFwcGVucyBoZXJlIiBtZWFu cyB0aGF0IHBlb3BsZSBjcmVhdGUgdGhlaXIgb3duIG1hZ2ljLiAgQW5kIHRoYXQgbmV2ZXIgcmVh bGx5IHdvcmtzIG91dCB3ZWxsLg0KDQpTbyBkZWZpbmUgdHdvIHRoaW5nczoNCiAtIGhvdyB0byBh Y3F1aXJlIGFuIGFjY2VzcyB0b2tlbg0KIC0gd2hhdCB0aGUgYWNjZXNzIHRva2VuIGxvb2tzIGxp a2UsIHdoYXQgZGF0YSBpdCBjb250YWlucywgbmVjZXNzYXJ5IGJpbmRpbmdzIGFuZCBzbyBmb3J0 aA0KDQpUaGUgYWNjZXNzIHRva2VuIGZvcm1hdCBpcyB3aGVyZSB5b3UgZ2V0IGludG8gc2lnbmF0 dXJlcyBhbmQgdGhlIGxpa2UuICBJdCBhbHNvIGRlcGVuZHMgYSBsb3Qgb24gd2hhdCB0aGUgdXNl IGNhc2VzIGFyZSBhbmQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhdCB5b3UgZGVzaXJlLiAg SSdtIGdvaW5nIHRvIGNvbmNlbnRyYXRlIG9uIHRoZSBhY3F1aXNpdGlvbiB0aGluZyBmaXJzdCBh bmQgZm9yZW1vc3QuICBUaGUgZm9ybWF0IHNob3VsZCBmb2xsb3cgZnJvbSB0aGF0Lg0KDQo9PUFj cXVpcmluZyBhbiBBY2Nlc3MgVG9rZW4NCg0KSWYgdGhlIEFjY2VzcyBUb2tlbiBpcyB2aWV3IGFz IGFuIG9wYXF1ZSBsdW1wIG9mIGRhdGEgWzJdLCB0aGVuIHRoZXJlJ3MgYW4gSFRUUCBtZXRob2Qg dGhhdCdzIHdlbGwgc3VpdGVkIHRvIHRoaXMgdGFzazogR0VULg0KDQpHRVQgZ29lcyBhIHN1cnBy aXNpbmdseSBsb25nIHdheSB0byBhY2NvbXBsaXNoaW5nIHRoaXMgdGFzay4NCg0KU2F5IHRoYXQg dGhlIDQwMyByZXNwb25zZSBpbmNsdWRlZCAtIGluIHRoZSByZXNwb25zZXMgaGVhZGVyLCBtYXli ZSBhIExpbmsgaGVhZGVyIC0gYSBVUkkuICBUaGF0IFVSSSBjb3VsZCBiZSB0aGUgVVJJIGZvciBh biBBY2Nlc3MgVG9rZW4gcmVzb3VyY2UuICBSZXF1aXJlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBD bGllbnQgaW4gb3JkZXIgdG8gc3VjY2Vzc2Z1bGx5IGFjcXVpcmUgdGhlIGNvbnRlbnRzIG9mIHRo aXMgcmVzb3VyY2UgYW5kIHlvdSBoYXZlIGRlYWx0IHdpdGggdGhlIGJhc2ljIHNjZW5hcmlvcyBz aG93biBpbiBGaWd1cmVzIDIgYW5kIDMgb2YgdGhlIC0xMCB2ZXJzaW9uIG9mIHRoZSBzcGVjLg0K DQpUaGlzIFVSSSBtaWdodCBub3QgZGlyZWN0bHkgcmVmZXIgdG8gdGhlIEFjY2VzcyBUb2tlbiBy ZXNvdXJjZS4gIEl0IGNvdWxkIGxlYWQgdG8gYSBjaGFpbiBvZiBIVE1MIHBhZ2VzIHRoYXQgbmVl ZCB0byBiZSBuYXZpZ2F0ZWQgc3VjY2Vzc2Z1bGx5IHRvIGdldCB0byB0aGUgdG9rZW4uDQoNClRo ZSBzYW1lIGJhc2ljIGFic3RyYWN0aW9uIGFsc28gYXBwbGllcyB0byB0aGUgQWNjZXNzIEdyYW50 LiAgVGhlIEFjY2VzcyBHcmFudCBhbmQgQWNjZXNzIFRva2VuIHNoYXJlIGEgc3VycHJpc2luZyBu dW1iZXIgb2YgY29tbW9uIGNoYXJhY3RlcmlzdGljcy4gIFRoZXkgYm90aCBjYXJyeSBhdXRob3Jp emF0aW9uIGluZm9ybWF0aW9uLCBpbmRlcGVuZGVudCBvZiBhdXRoZW50aWNhdGlvbi4gIFRoZSBv bmx5IGRpZmZlcmVuY2UgaXMgd2hlcmUgdGhleSBhcmUgYWNxdWlyZWQgZnJvbS4gIEFuIEFjY2Vz cyBHcmFudCBpcyBhbiBBY2Nlc3MgVG9rZW4gZm9yIHRoZSBBY2Nlc3MgVG9rZW4gcmVzb3VyY2Uu ICBCb3RoIGFyZSBvcHRpb25hbDogdGhlIG9ubHkgZGlmZmVyZW5jZSBiZWluZyB0aGF0IGlmIHlv dSBkb24ndCB1c2UgYW4gQWNjZXNzIFRva2VuLCB5b3UgYXJlbid0IHVzaW5nIE9BdXRoLg0KDQpX aGF0IGlmIHRoZSBBY2Nlc3MgR3JhbnQgYW5kIEFjY2VzcyBUb2tlbiB1c2VkIHRoZSBzYW1lIG1l Y2hhbmlzbT8gIFRoZW4geW91IGp1c3QgaGF2ZSBhIGNoYWluaW5nIG9mIHRoZSBzYW1lIHByb2Nl c3M6DQoNCiAgQ2xpZW50IGdvZXMgdG8gUmVzb3VyY2UgU2VydmVyLCBnZXRzIDQwMywgNDAzIHBv aW50cyB0byBBdXRob3JpemF0aW9uIFNlcnZlcg0KICBDbGllbnQgZ29lcyB0byBBdXRob3JpemF0 aW9uIFNlcnZlciwgZ2V0cyA0MDMsIDQwMyBwb2ludHMgdG8gUmVzb3VyY2UgT3duZXINCiAgQ2xp ZW50IGdvZXMgdG8gUmVzb3VyY2UgT3duZXIsIGdldHMgQWNjZXNzIFRva2VuIEEgKGFuIEFjY2Vz cyBHcmFudCkuDQogIENsaWVudCB0YWtlcyBBY2Nlc3MgVG9rZW4gQSB0byBBdXRob3JpemF0aW9u IFNlcnZlciB3aXRoIEFjY2VzcyBUb2tlbiBBLCBnZXRzIEFjY2VzcyBUb2tlbiBCDQogIENsaWVu dCB0YWtlcyBBY2Nlc3MgVG9rZW4gQiB0byBSZXNvdXJjZSBTZXJ2ZXIsIGdldHMgcmVzb3VyY2UN Cg0KWW91IGNvdWxkIHNlZSBob3cgdGhpcyBjb3VsZCByZWN1cnNlLiAgDQoNCihJdCBhbHNvIG9j Y3VycyB0aGF0IHlvdSBjb3VsZCBhbHNvIHBhcmFsbGVsaXplIHRoZSBwcm9jZXNzIHRvbyBhbmQg cmVxdWlyZSBtdWx0aXBsZSBBY2Nlc3MgVG9rZW5zLiAgVGhlIGFuYWxvZ3kgd291bGQgYmUgc29t ZXRoaW5nIGxpa2U6ICJ5b3UgbXVzdCBmaXJzdCBjb2xsZWN0IHRoZSBzd29yZCBvZiBLbm9yciwg dGhlIHNjZXB0cmUgb2YgTWFub3RoIGFuZCB0aGUgY3Jvd24gb2YgWmF4eCBiZWZvcmUgeW91IGNh biBjbGFpbSB0aGUgdGhyb25lIG9mIE9yaW9uIi4gIEkgZG9uJ3Qga25vdyBpZiB0aGlzIGZpdHMg aW50byB0aGUgZXhpc3RpbmcgbW9kZWwgYXQgYWxsLCBvciBldmVuIGlmIGl0IG1ha2VzIHNlbnNl IGF0IGFsbC4pDQoNCj09T3RoZXIgU3R1ZmY6IENyYXp5IE91dCBvZiBCYW5kIElkZWFzDQoNClRo YXQncyByZWFsbHkgdGhlIGNvcmUgb2YgdGhlIGlkZWEgdGhhdCBJIGhhZCwgYnV0IHRoZXJlIGFy ZSBhIGZldyB0aGluZ3MgdGhhdCBJIHRoaW5rIGFyZSB3b3J0aCBjb25zaWRlcmluZy4NCg0KSW1w bGljaXQgaW4gbXkgZGVzY3JpcHRpb24gaXMgdGhlIGZhY3QgdGhhdCB0aGUgZW50aXR5IHRoYXQg ZGVtYW5kcyBhbiBBY2Nlc3MgVG9rZW4gKFJlc291cmNlIFNlcnZlciwgQXV0aHogU2VydmVyKSBu ZWVkcyB0byBrbm93IGFib3V0IHRoZSBlbnRpdHkgdGhhdCBwcm9kdWNlcyBpdCAoQXV0aHogU2Vy dmVyLCBSZXNvdXJjZSBPd25lcikuICBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyBhbiB1bnJl YXNvbmFibGUgY29uc3RyYWludC4gIFRoZSBjb25zdW1lciBvZiB0aGUgQWNjZXNzIFRva2VuIGhh cyB0byBrbm93IHdobyBwcm9kdWNlZCBpdCB0byBjaGVjayB3aGV0aGVyIG9yIG5vdCB0aGUgVG9r ZW4gY2FuIGJlIHRydXN0ZWQgZW5vdWdoLg0KDQpUaGF0IGNvdWxkIGJlIHVzZWQgdG8gcHVzaCBh IG51bWJlciBvZiB0aGluZ3Mgb3V0IG9mIHNjb3BlIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4gIChB Z2Fpbiwgd2l0aCBkdWUgY2F1dGlvbiByZWdhcmRpbmcgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMg LSBpdCBtaWdodCBzdGlsbCBiZSBuZWNlc3NhcnkgdG8gZGVzY3JpYmUgdGhlc2UgdXNlcywgZXZl biBpZiB0aGUgb24tdGhlLXdpcmUgZm9ybWF0cyBhcmVuJ3QgZGVmaW5lZC4gIE9uLXRoZS13aXJl IGZvcm1hdHMgbWlnaHQgc3RpbGwgYmUgcGFydCBvZiBleHRlcm5hbCB3b3JrLikNCg0KQSBsb3Qg b2Ygc3BlY2lmaWNhdGlvbiBnb2VzIGludG8gc3BlY2lmeWluZyB0aGUgdGhpbmdzIHRoYXQgYXJl IGJlaW5nIGV4Y2hhbmdlZCBiZXR3ZWVuIFJlc291cmNlIFNlcnZlciBhbmQgQXV0aG9yaXphdGlv biBTZXJ2ZXIuICBUaGVzZSBjb3VsZCBhbG1vc3QgYWxsIGJlIGRlZmVycmVkIHRvIG90aGVyIHNw ZWNpZmljYXRpb25zIG9yIG9ubHkgdGFsa2VkIGFib3V0IGZyb20gdGhlIHNlY3VyaXR5IHBlcnNw ZWN0aXZlLg0KDQpGb3IgaW5zdGFuY2UsIHRoZSBjdXJyZW50IHJlcXVlc3QgZm9yIGFuIEFjY2Vz cyBUb2tlbiBpbmNsdWRlcyBhIGNsaWVudF9pZC4gIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgdG8g ZW5zdXJlIHRoYXQgdGhlIEFjY2VzcyBUb2tlbiBpcyBjb3JyZWN0bHkgYm91bmQgdG8gYSBzcGVj aWZpYyBDbGllbnQgLSBzbyB0aGF0IGFub3RoZXIgY2xpZW50IGNhbid0IHVzZSB0aGUgdG9rZW4g WzNdLiAgV2hlbiBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlIFJlc291cmNlIE93bmVyIGtub3dzIGFi b3V0IHRoZSBBdXRoeiBTZXJ2ZXIsIHdlIGNhbiBhbHNvIGFzc3VtZSB0aGF0IHRoZSBSZXNvdXJj ZSBPd25lciBpcyBhYmxlIHRvIGRpcmVjdCB0aGUgQ2xpZW50IHRvIHRoZSBBdXRoeiBTZXJ2ZXIg c28gdGhhdCB0aGUgQWNjZXNzIFRva2VuIGl0IHByb2R1Y2VzIGhhcyB0aGUgbmVjZXNzYXJ5IGJp bmRpbmdzLg0KDQpBbm90aGVyIGV4YW1wbGUgaXMgdGhlIHJlZGlyZWN0LiAgSWYgdGhlIGNsaWVu dCBmb2xsb3dzIHRoZSBsaW5rIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciwgYSBSZWZlcnJl ciBoZWFkZXIgbWlnaHQgYmUgb2JzZXJ2ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAg T25jZSB0aGUgQXV0aG9yaXphdGlvbiBpbnRlcmFjdGlvbiBpcyBjb21wbGV0ZSwgdGhlIEF1dGhv cml6YXRpb24gU2VydmVyIGNvdWxkIHJlZGlyZWN0IGJhY2sgdG8gdGhlIFVSSSBpdCBmaXJzdCBz YXcuICBBbHRlcm5hdGl2ZWx5LCB0aGlzIGluZm9ybWF0aW9uIG1pZ2h0IGJlIGJ1cmllZCBpbiB0 aGUgVVJJIHdpdGggdGhlIG90aGVyIGp1bmssIGFzIGRlc2NyaWJlZCBhYm92ZS4gIFRoZXJlJ3Mg bm8gbmVlZCB0byBmb3JtYWxpemUgdGhpcyBtZWNoYW5pc20gaWYgdGhlIGFncmVlbWVudCBpcyBw cml2YXRlLg0KDQpFLmcuDQogIENsaWVudCBnb2VzIHRvIFJlc291cmNlIFNlcnZlciwgZ2V0cyA0 MDMgcmVzcG9uc2UuICBUaGUgNDAzIGNvbnRhaW5zIGEgVVJJIHRoYXQsIGFsb25nIHdpdGggaWRl bnRpZnlpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLCBpbmNsdWRlcyBpbiBhbiBvcGFxdWUg cG9ydGlvbiB0aGF0IGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb246IHRoZSBjbGllbnQg aWRlbnRpdHksIHRoZSByZXNvdXJjZSB0aGUgY2xpZW50IGlzIHRyeWluZyB0byBhY2Nlc3MsIGFu ZCBvdGhlciBjb25zdHJhaW50cy4gIFRoZSBSZXNvdXJjZSBTZXJ2ZXIga25vd3MgaG93IHRvIGNv bnN0cnVjdCB0aGlzIFVSSSBzbyB0aGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBjYW4gbWFr ZSBzZW5zZSBvZiB0aGlzLiAgQnkgbmF2aWdhdGluZyB0byB0aGlzIHJlc291cmNlLCB0aGUgQ2xp ZW50IHVsdGltYXRlbHkgYWNxdWlyZXMgYW4gQWNjZXNzIFRva2VuIC0gcHJvYmFibHkgc29tZSBz b3J0IG9mIGRvY3VtZW50IHdpdGggYSBtZWRpYSB0eXBlIHRoYXQgaWRlbnRpZmllcyBpdCBhcyBh biBBY2Nlc3MgVG9rZW4uDQogIENsaWVudCBicmluZ3MgdGhlIEFjY2VzcyBUb2tlbiBiYWNrIHRv IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuICBUaGUgUmVzb3VyY2UgU2VydmVyIGNyYWNrcyB0aGF0IHRv a2VuIG9wZW4gYW5kIGNoZWNrcyBpdDogaXMgaXQgdmFsaWQ/IGlzIGl0IGZyb20gYW4gQXV0aG9y aXphdGlvbiBTZXJ2ZXIgdGhhdCBJIHRydXN0PyBpcyBpdCBmb3IgdGhlIGN1cnJlbnQgcmVzb3Vy Y2U/IGlzIGl0IGZvciB0aGUgY3VycmVudCByZXF1ZXN0ZXI/IGlzIGl0IHZhbGlkIHJpZ2h0IG5v dz8gIElmIGEgY2hlY2sgZmFpbHMsIHRoZSByZXF1ZXN0IGlzIHJlamVjdGVkOyBpZiB0aGV5IGFs bCBwYXNzLCB0aGUgcmVxdWVzdCBpcyBwZXJtaXR0ZWQuDQoNCkZvcm1hbGl6aW5nIHRoZSBleGNo YW5nZSBiZXR3ZWVuIFJlc291cmNlIFNlcnZlciBhbmQgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgbGV0 cyBhbiBhcmJpdHJhcnkgUmVzb3VyY2UgU2VydmVyIHVzZSBhbiBhcmJpdHJhcnkgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuICBUaGVyZSBhcmUgZ29vZCB1c2UgY2FzZXMgZm9yIHRoaXMsIGJ1dCB0aGV5 IGFyZSBzZWNvbmRhcnkgdG8gdGhlIGZ1bmN0aW9uIEkgZGVzY3JpYmUgYWJvdmUuICBTZXBhcmF0 aW5nIHRoYXQgbWFrZXMgYSBncmVhdCBkZWFsIG9mIHNlbnNlLg0KDQo9PU90aGVyIFN0dWZmOiBT bGlnaHRseSBXYWNreSBJZGVhcw0KDQpXaGF0IGlmIHRoZSByZXNvdXJjZSB0aGF0IHByb3ZpZGVz IHRoZSBBY2Nlc3MgVG9rZW4gcHJvdmlkZWQgdGhlIEFjY2VzcyBUb2tlbiB0byBhbnkgYW5kIGFs bCB3aG8gYXNrZWQ/ICBUaGF0J3Mgbm90IHVucmVhc29uYWJsZSBpZiB0aGUgdG9rZW4gY2FuIG9u bHkgYmUgdXNlZCBieSBhbiBhdXRoZW50aWNhdGVkIENsaWVudC4NCg0KSWYgdGhlIHJlc291cmNl IGRpZG4ndCBleGlzdCB1bnRpbCB0aGUgQ2xpZW50IHdhcyBhdXRob3JpemVkLCB0aGVuIHRoYXQg d291bGQgbWFrZSB0aGlzIG1vcmUgZWZmZWN0aXZlLg0KDQpPciwgbWF5YmUgYmV0dGVyIHlldCwg dGhlIHJlc291cmNlIG1pZ2h0IGV4aXN0IGFueXdheSwgYnV0IHRoZSBDbGllbnQgaXNuJ3QgdG9s ZCBhYm91dCB0aGUgcmVzb3VyY2UgdW50aWwgdGhleSBhcmUgYXV0aG9yaXplZC4gIEFueW9uZSB0 aGF0IGtub3dzIHRoZSBVUkkgY2FuIHVzZSBpdCBmcmVlbHksIGJ1dCBvbmx5IHRoZSBhdXRob3Jp emVkIGFyZSBldmVyIGdyYW50ZWQga25vd2xlZGdlIG9mIHRoZSBVUkkuICBUaGUgb25seSBjb25k aXRpb24gaXMgdGhhdCB0aGUgVVJJIGlzIGhhcmQgdG8gZ3Vlc3MuICAoU2VlIFJGQzU4MDggZm9y IGEgZGlmZmVyZW50IGFwcGxpY2F0aW9uIG9mIHRoaXMgY29uY2VwdCBhbmQgYSBkaXNjdXNzaW9u IG9mIHRoZSBsaW1pdGF0aW9ucy4gIEknbSBhbHNvIGF3YXJlIHRoYXQgdGhpcyBtaWdodCBoYXZl IG90aGVyIGlzc3VlcyBpbiBhIHdlYiBlbnZpcm9ubWVudCwgYmVjYXVzZSBVUklzIGRvbid0IHN0 YXkgc2VjcmV0IHdpdGggUmVmZXJyZXIgaGVhZGVycyBhbmQgdGhlIGxpa2UuKQ0KDQpJbiB0aGlz IG1vZGVsLCB0aGUgVVJJIGFuZCBBY2Nlc3MgVG9rZW4gYXJlIGludGVyY2hhbmdlYWJsZS4gIElm IHlvdSBoYXZlIHRoZSBVUkksIHlvdSBjYW4gZ2l2ZSBpdCB0byBzb21lb25lIGFuZCB0aGF0J3Mg anVzdCBhcyBnb29kIGFzIGdpdmluZyB0aGVtIGEgdG9rZW4uICBUaGlzIG1pZ2h0IGJlIHVzZWZ1 bCBmb3Igc29tZSBvZiB0aGUgbW9yZSBleHRyZW1lIHVzZSBjYXNlcy4NCg0KPT1Oby1zby10aGlu IENsaWVudA0KDQpBIGxvdCBvZiBmb2N1cyBoYXMgYmVlbiBwbGFjZWQgb24gdXNpbmcgYSBjbGll bnQgdGhhdCBkb2Vzbid0IHVuZGVyc3RhbmQgT0F1dGggZm9yIGVhY2ggb2YgdGhlIHVzZSBjYXNl cy4gIFRoZSB1c2Ugb2YgcmVkaXJlY3Rpb24sIHBhcnRpY3VsYXJseSB3aXRoIFVSSSBmcmFnbWVu dHMsIGJlbGllcyB0aGlzLiAgTm9uZSBvZiB3aGF0IEkndmUgc3VnZ2VzdGVkIGlzIGltcG9zc2li bGUsIGl0IGp1c3QgcmVxdWlyZXMgdGhhdCB0aGUgQ2xpZW50IGhhdmUgc29tZSBjb250cm9sIG92 ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIEhUVFAgcmVxdWVzdHMgdGhhdCBpdCBtYWtlcy4NCg0KVGhh dCBkb2Vzbid0IHJlcXVpcmUgZXhwbGljaXQgc3VwcG9ydCBmcm9tIGFuIEhUVFAgY2xpZW50LCBq dXN0IHRoZSBhYmlsaXR5IHRvIG1ha2UgcmVxdWVzdHMgYW5kIHNldCB0aGUgY29udGVudCBvZiBo ZWFkZXJzLiAgU3VjaCBzdXBwb3J0IGhhcyBiZWVuIHRhYmxlIHN0YWtlcyBmb3IgYSBsb25nIHRp bWUuDQoNClJlZ2FyZHMsDQpNYXJ0aW4NCg0KDQpbMV0gTm90ZSB0aGF0IGF1dGhlbnRpY2F0aW9u IGlzIG5vdCBzdHJpY3RseSBuZWNlc3NhcnksIGl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQgdG8gcHJv dmlkZSBldmlkZW5jZSBvZiBhdXRob3JpemF0aW9uIGFzIGRlc2NyaWJlZCBpbiB0aGUgY291bnRl ci1leGFtcGxlcyBoZXJlOiBodHRwOi8vYXJzdGVjaG5pY2EuY29tL3NlY3VyaXR5L2d1aWRlcy8y MDEwLzA5L3R3aXR0ZXItYS1jYXNlLXN0dWR5LW9uLWhvdy10by1kby1vYXV0aC13cm9uZy5hcnMv Mg0KDQpbMl0gQ29waW91cyBjYXZlYXRzIC0gYXMgSSBtZW50aW9uZWQsIHRyZWF0aW5nIHRoZSBB Y2Nlc3MgVG9rZW4gYXMgYW4gb3BhcXVlIGJsb2IgaXMgbWVyZWx5IGEgdXNlZnVsIGFic3RyYWN0 aW9uLiAgSXQgZ2V0cyB5b3UgYSBsb25nIHdheS4gIEJlZm9yZSB5b3UgaGF2ZSB0byB3b3JyeSBh Ym91dCBzcGVjaWZpY3MgeW91IGNhbiB1bmRlcnN0YW5kIGEgbG90IGFib3V0IHRoZSBnb2FscyBh bmQgaG93IHRob3NlIGdvYWxzIGFyZSBhY2hpZXZlZC4NCg0KWzNdIEl0J3MgaW50ZXJlc3Rpbmcg dGhhdCB0aGUgQWNjZXNzIFRva2VuIHByb2R1Y2VyIGRvZXNuJ3QgbmVlZCB0byB2YWxpZGF0ZSB0 aGUgY2xpZW50IGlkZW50aWZpZXIuICBBcyBsb25nIGFzIHRoZXkgYXJlbid0IGR1cGVkIGFib3V0 IHdobyB0aGV5IGFyZSBwcm9kdWNpbmcgdGhlIEFjY2VzcyBUb2tlbiBmb3IsIHRoZXkgZG9uJ3Qg Y2FyZSB0aGF0IHRoZSBlbnRpdHkgdGhhdCBpcyBhc2tpbmcgaXMgdGhlIHNhbWUgb3Igbm90IC0g b25seSB0aGUgY29uc3VtZXIgb2YgdGhlIHRva2VuIG5lZWRzIHRvIGNoZWNrIHRoYXQgaXQgaXMg T0suDQo= From torsten@lodderstedt.net Fri Oct 22 00:43:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E653A6407 for ; Fri, 22 Oct 2010 00:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbfJwlzeB+IP for ; Fri, 22 Oct 2010 00:43:24 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by core3.amsl.com (Postfix) with ESMTP id 8DEA13A67ED for ; Fri, 22 Oct 2010 00:43:23 -0700 (PDT) Received: from [80.187.147.233] (helo=[10.135.144.225]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1P9CJ8-0005O2-Ip; Fri, 22 Oct 2010 09:44:58 +0200 Message-ID: <4CC140F8.40106@lodderstedt.net> Date: Fri, 22 Oct 2010 09:44:56 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03F31EABAD@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EABAD@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth abstractions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 07:43:26 -0000 Martin, great to see you contributing to the WG! One question came into my mind: How do the other grant types (assertion, username/password, refresh token) fit into your abstractions? The grant type used also depends on the client and its capabilities, so just returning a single URL pointing to an access token resource might not be suffice. To give an example: Alice stores her contacts at contacts.example.com. She uses 2 clients, one on the PC and one on a mobile phone. The PC client uses the standard redirect-based process. The mobile phone client cannot use this process because of technical limitations (small screen size, sparse computing power, no integration API for embedding the browser or custom schemes). Therefore this client uses the username/password flow in order to get authorization and obtain a refresh token. The implications with respect to the flow: PC client: redirect to end-user authorization endpoint Mobile phone client: access to the tokens endpoint with the user's credentials So although the resource server's URL is the same in both cases, different URLs will be utilized to process the authorization flow. regards, Torsten. Am 22.10.2010 00:36, schrieb Thomson, Martin: > At the last meeting, I promised Blaine that I'd share a few thoughts on how I understood OAuth to operate. It's taken me a while to find the time to marshal my thoughts, but here 'tis. > > After attending the meeting and tutorial, it was clear that the abstraction behind OAuth is not being effectively communicated. A simple abstraction can be a powerful tool in dealing with a complex specification. It seems to me that OAuth struggles as a result of trying to cover so many use cases at once. This might be easier if the abstract model were better understood. > > I believe that OAuth has a very simple abstraction. What I am going to try to do is describe that abstraction. > > The cunning techniques employed to circumvent technical limitations - redirection with URI fragments and so forth - are noise on the wire at this layer. As a necessary product of having to reduce the abstraction to practice, they have little bearing on what I am going to attempt to describe. > > I appreciate that the process is well beyond this airy-fairy stage. If nothing else, I hope that this jostles a few brain cells into new ways of looking at OAuth. > > To preface this with a warning: There's been a lot of discussion about the OAuth "protocol" and examination of its properties from the perspective of it being a thing that "uses HTTP". There's a lot of HTTP experience that teaches the long term folly of trying to build on top of HTTP. I'm probably going to beat on a dead horse by explaining where working _with_ HTTP (as opposed to _despite_ it) has significant advantages. > > > ==First Abstraction > > OAuth specifies a separation between authentication and authorization. > > Never mind that HTTP got these mixed up early on, it doesn't now - HTTP only provides authentication. The "Authorization" header is for authentication. That might be implicitly used to infer authorization, but it's still fundamentally just authentication. > > OAuth lets a Client come to a Resource Server with separate evidence for identity and authorization. > > ==Goal > > A Client's goal is to acquire a resource from the Resource Server. Or, to be more general, to successfully complete a particular type of (HTTP) request. > > In order to do this, authentication is not sufficient, the Client must also prove that it is authorized. > > The Client might be known to the Resource Server. This is the authentication part. There are existing mechanisms for that (the idea that these might be improved is a subject that comes up on occasion). [1] > > ==Proving Authorization > > Once the Client is authenticated (or not) the Resource Server might still reject the request. There's an HTTP 403 (Forbidden) response for this purpose. > > If this were at all like an HTTP 401 response, that rejection could provide the clues that could be used by the Client to determine how to acquire evidence of authorization (what OAuth calls the Access Token). > > I don't know if anyone has proposed this, but it seems logical to extend HTTP and work within its framework, thus: > > 1. Add a header to the 403 (Forbidden) response. This header would indicate that irrespective of the identity of the client, further evidence of authorization is required (that is, an Access Token). > > 2. Add a request header that is intended to carry an access token. > > The first might be a little complex. Unlike the 401 response, OAuth has a number of variations on how an Access Token is required and this constrains the information that can be revealed at this point. > > This 403 header might include virtually no clues at all. Maybe the equivalent of "realm" - some private identifier that helps those in the know distinguish between one set of authorization requirements from another. What information is revealed depends on the desired security properties. > > ==Access Token > > It's tempting to say that the Access Token is completely opaque to all but the Authorization Server and the Resource Server. A private agreement between these parties could be used to determine what information is included. > > In the abstract sense, the definition of the request header could just provide a bit bucket for a token. In the macro, that's all the solution requires. > > Obviously, the work doesn't stop there. To ignore the access token entirely would be trivializing all the work that has been done in this area. A separate authorization function is an important feature. Structured agreements, such as the SAML assertions, have a significant role and formalizing formats can be extremely powerful. > > Then there are the security concerns that arise when you wave your hands. Saying "magic happens here" means that people create their own magic. And that never really works out well. > > So define two things: > - how to acquire an access token > - what the access token looks like, what data it contains, necessary bindings and so forth > > The access token format is where you get into signatures and the like. It also depends a lot on what the use cases are and the security properties that you desire. I'm going to concentrate on the acquisition thing first and foremost. The format should follow from that. > > ==Acquiring an Access Token > > If the Access Token is view as an opaque lump of data [2], then there's an HTTP method that's well suited to this task: GET. > > GET goes a surprisingly long way to accomplishing this task. > > Say that the 403 response included - in the responses header, maybe a Link header - a URI. That URI could be the URI for an Access Token resource. Require authentication of the Client in order to successfully acquire the contents of this resource and you have dealt with the basic scenarios shown in Figures 2 and 3 of the -10 version of the spec. > > This URI might not directly refer to the Access Token resource. It could lead to a chain of HTML pages that need to be navigated successfully to get to the token. > > The same basic abstraction also applies to the Access Grant. The Access Grant and Access Token share a surprising number of common characteristics. They both carry authorization information, independent of authentication. The only difference is where they are acquired from. An Access Grant is an Access Token for the Access Token resource. Both are optional: the only difference being that if you don't use an Access Token, you aren't using OAuth. > > What if the Access Grant and Access Token used the same mechanism? Then you just have a chaining of the same process: > > Client goes to Resource Server, gets 403, 403 points to Authorization Server > Client goes to Authorization Server, gets 403, 403 points to Resource Owner > Client goes to Resource Owner, gets Access Token A (an Access Grant). > Client takes Access Token A to Authorization Server with Access Token A, gets Access Token B > Client takes Access Token B to Resource Server, gets resource > > You could see how this could recurse. > > (It also occurs that you could also parallelize the process too and require multiple Access Tokens. The analogy would be something like: "you must first collect the sword of Knorr, the sceptre of Manoth and the crown of Zaxx before you can claim the throne of Orion". I don't know if this fits into the existing model at all, or even if it makes sense at all.) > > ==Other Stuff: Crazy Out of Band Ideas > > That's really the core of the idea that I had, but there are a few things that I think are worth considering. > > Implicit in my description is the fact that the entity that demands an Access Token (Resource Server, Authz Server) needs to know about the entity that produces it (Authz Server, Resource Owner). I don't think that this is an unreasonable constraint. The consumer of the Access Token has to know who produced it to check whether or not the Token can be trusted enough. > > That could be used to push a number of things out of scope for the specification. (Again, with due caution regarding the security properties - it might still be necessary to describe these uses, even if the on-the-wire formats aren't defined. On-the-wire formats might still be part of external work.) > > A lot of specification goes into specifying the things that are being exchanged between Resource Server and Authorization Server. These could almost all be deferred to other specifications or only talked about from the security perspective. > > For instance, the current request for an Access Token includes a client_id. The reason for this is to ensure that the Access Token is correctly bound to a specific Client - so that another client can't use the token [3]. When it is assumed that the Resource Owner knows about the Authz Server, we can also assume that the Resource Owner is able to direct the Client to the Authz Server so that the Access Token it produces has the necessary bindings. > > Another example is the redirect. If the client follows the link to the Authorization Server, a Referrer header might be observed by the Authorization Server. Once the Authorization interaction is complete, the Authorization Server could redirect back to the URI it first saw. Alternatively, this information might be buried in the URI with the other junk, as described above. There's no need to formalize this mechanism if the agreement is private. > > E.g. > Client goes to Resource Server, gets 403 response. The 403 contains a URI that, along with identifying the Authorization Server, includes in an opaque portion that contains additional information: the client identity, the resource the client is trying to access, and other constraints. The Resource Server knows how to construct this URI so that the Authorization Server can make sense of this. By navigating to this resource, the Client ultimately acquires an Access Token - probably some sort of document with a media type that identifies it as an Access Token. > Client brings the Access Token back to the Resource Server. The Resource Server cracks that token open and checks it: is it valid? is it from an Authorization Server that I trust? is it for the current resource? is it for the current requester? is it valid right now? If a check fails, the request is rejected; if they all pass, the request is permitted. > > Formalizing the exchange between Resource Server and Authorization Server lets an arbitrary Resource Server use an arbitrary Authorization Server. There are good use cases for this, but they are secondary to the function I describe above. Separating that makes a great deal of sense. > > ==Other Stuff: Slightly Wacky Ideas > > What if the resource that provides the Access Token provided the Access Token to any and all who asked? That's not unreasonable if the token can only be used by an authenticated Client. > > If the resource didn't exist until the Client was authorized, then that would make this more effective. > > Or, maybe better yet, the resource might exist anyway, but the Client isn't told about the resource until they are authorized. Anyone that knows the URI can use it freely, but only the authorized are ever granted knowledge of the URI. The only condition is that the URI is hard to guess. (See RFC5808 for a different application of this concept and a discussion of the limitations. I'm also aware that this might have other issues in a web environment, because URIs don't stay secret with Referrer headers and the like.) > > In this model, the URI and Access Token are interchangeable. If you have the URI, you can give it to someone and that's just as good as giving them a token. This might be useful for some of the more extreme use cases. > > ==No-so-thin Client > > A lot of focus has been placed on using a client that doesn't understand OAuth for each of the use cases. The use of redirection, particularly with URI fragments, belies this. None of what I've suggested is impossible, it just requires that the Client have some control over the content of the HTTP requests that it makes. > > That doesn't require explicit support from an HTTP client, just the ability to make requests and set the content of headers. Such support has been table stakes for a long time. > > Regards, > Martin > > > [1] Note that authentication is not strictly necessary, it might be sufficient to provide evidence of authorization as described in the counter-examples here: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/2 > > [2] Copious caveats - as I mentioned, treating the Access Token as an opaque blob is merely a useful abstraction. It gets you a long way. Before you have to worry about specifics you can understand a lot about the goals and how those goals are achieved. > > [3] It's interesting that the Access Token producer doesn't need to validate the client identifier. As long as they aren't duped about who they are producing the Access Token for, they don't care that the entity that is asking is the same or not - only the consumer of the token needs to check that it is OK. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun Oct 24 09:09:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2903A68D1 for ; Sun, 24 Oct 2010 09:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FRT_LITTLE=1.555, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH3YbWNTZ3yS for ; Sun, 24 Oct 2010 09:09:37 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 49B653A688D for ; Sun, 24 Oct 2010 09:09:36 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2010 16:11:18 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp040) with SMTP; 24 Oct 2010 18:11:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194599ZPSd4YwbpzQdprFPkUaFNL9S7DF2N+b5/xE gStUhQeNw7eFna Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Sun, 24 Oct 2010 19:11:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54F180F5-E3FB-44DF-894B-7412BD94F02B@gmx.net> References: <245536261-1287141188-cardhu_decombobulator_blackberry.rim.net-1893194191-@bda303.bisx.produk.on.blackberry> <3D3C75174CB95F42AD6BCC56E5555B45033374BA@FIESEXC015.nsn-intra.net> To: David Recordon X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth session at IETF-79 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 16:09:39 -0000 Hi David,=20 I believe that there is lot of other work in the IETF with relevance to = OAuth. For example, at this IETF meeting the topics of interest are:=20 * Web related working groups in the APPS area. * Security area, including the recently created ABFAB working group (see = http://datatracker.ietf.org/wg/abfab/). * O&M area particularly regarding AAA in context to ABFAB. =20 * I also believe it is useful to talk to the RAI area people since you = will find the cellular operator community there. There is a lot of = excitement for putting applications on mobile phones. Getting a better = idea how those people think may be helpful.=20 This list can easily grow if you are interested in work beyond OAuth = (for example on work related to the recent real-time communication in = the browser workshop). It may be worth mentioning that there is always the chance to talk to = lots of people who have a long history in the development of = communication protocols. =20 Ciao Hannes PS: You mentioned the Kerberos people showing up at an earlier meeting. = I still think it is very useful to take a look at the design of Kerberos = given the strong relationship between Kerberos and OAuth. I little while = ago I made an interview with two MIT folks about the Kerberos design: = http://www.tschofenig.priv.at/kerberos/Kerberos.mp3 On Oct 15, 2010, at 8:52 PM, David Recordon wrote: > Hey Hannes, I'd like to at least explain my reasoning behind not = planning to go to the China meeting because it really isn't restrictions = around travel. This is likely inpolitic to say, but it's because of how = much of a waste of my time the LA meeting was. The LA meeting contained = numerous people who weren't =96 and still aren't =96 engaged in this = working group who felt that they should argue with us repeatedly around = how what we were doing was wrong and already solved by Kerberos. That = trip was only two days, but China will easily be a week. So for me it is = about what is the best use of my time, not just how much it costs. >=20 > I'd love to have another face to face meeting between people working = actively on deploying OAuth 2.0. I hope that IIW in a few weeks will = provide a venue for some of that. But if it's in Europe then I'll go to = Europe. For me it is about who is (and isn't) going to be there rather = than where the meeting is physically located. >=20 > --David >=20 >=20 > On Fri, Oct 15, 2010 at 5:11 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: > Hi Torsten, >=20 > We have to figure out what the most efficient way is to get our work > done. >=20 > With the Prague IETF we will see again whether there is a need for > face-to-face meeting. We had phone conference calls earlier this year = as > well. That's another option to make progress in addition to the usage = of > the mailing list. >=20 > Attending the IETF meetings is useful to get a better understanding of > the big picture and that's why I go there. However, I understand that > others have travel restrictions. Meetings outside the US, like this = one, > are obviously more expensive for those who are based in the US. >=20 > Ciao > Hannes >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > On Behalf Of ext torsten@lodderstedt.net > > Sent: Friday, October 15, 2010 2:13 PM > > To: Eliot Lear; igor.faynberg@alcatel-lucent.com > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth session at IETF-79 > > > > What is the alternative from your point of view? > > > > Regards, > > Torsten. > > ------Originalnachricht------ > > Von: Eliot Lear > > An:igor.faynberg@alcatel-lucent.com > > Cc:Lodderstedt, Torsten > > Cc:oauth@ietf.org > > Betreff: Re: [OAUTH-WG] OAuth session at IETF-79 > > Gesendet: 15. Okt. 2010 13:10 > > > > I agree with Hannes' approach. What happened in Maastricht > > was that we > > ended up with bifurcated discussions- in the room and on the list. > > That didn't seem very productive. > > > > > > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Martin.Thomson@andrew.com Sun Oct 24 22:58:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CC83A6936 for ; Sun, 24 Oct 2010 22:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKSZlqg10ogk for ; Sun, 24 Oct 2010 22:58:41 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 93F553A694A for ; Sun, 24 Oct 2010 22:58:41 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:38519 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S460728Ab0JYGAY (ORCPT ); Mon, 25 Oct 2010 01:00:24 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 25 Oct 2010 01:00:24 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 25 Oct 2010 14:00:18 +0800 From: "Thomson, Martin" To: Torsten Lodderstedt Date: Mon, 25 Oct 2010 14:00:16 +0800 Thread-Topic: [OAUTH-WG] OAuth abstractions Thread-Index: ActxvQ/XokGE32wtSeqKFTVohhDrVACSdcRg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EADB2@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F31EABAD@SISPE7MB1.commscope.com> <4CC140F8.40106@lodderstedt.net> In-Reply-To: <4CC140F8.40106@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth abstractions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 05:58:42 -0000 SGkgVG9yc3RlbiwNCg0KT24gMjAxMC0xMC0yMiBhdCAxODo0NDo1NiwgVG9yc3RlbiBMb2RkZXJz dGVkdCB3cm90ZToNCj4gT25lIHF1ZXN0aW9uIGNhbWUgaW50byBteSBtaW5kOiBIb3cgZG8gdGhl IG90aGVyIGdyYW50IHR5cGVzDQo+IChhc3NlcnRpb24sDQo+IHVzZXJuYW1lL3Bhc3N3b3JkLCBy ZWZyZXNoIHRva2VuKSBmaXQgaW50byB5b3VyIGFic3RyYWN0aW9ucz8gVGhlIGdyYW50DQo+IHR5 cGUgdXNlZCBhbHNvIGRlcGVuZHMgb24gdGhlIGNsaWVudCBhbmQgaXRzIGNhcGFiaWxpdGllcywg c28ganVzdA0KPiByZXR1cm5pbmcgYSBzaW5nbGUgVVJMIHBvaW50aW5nIHRvIGFuIGFjY2VzcyB0 b2tlbiByZXNvdXJjZSBtaWdodCBub3QNCj4gYmUNCj4gc3VmZmljZS4NCg0KVGhlIGZvcm0gb2Yg Z3JhbnQgYmVjb21lcyBhIHNlY29uZGFyeSBjb25jZXJuLiAgV2hldGhlciB0aGUgcmVzb3VyY2Ug b3duZXIgcHJvdmlkZXMgYSB1c2VybmFtZS9wYXNzd29yZCwgU0FNTCBhc3NlcnRpb24sIG9yIHRo ZXkganVzdCByZWRpcmVjdCB0byBhIHNlY3JldCBVUkksIHRoZSBwcm9jZXNzIGlzIHRoZSBzYW1l LiAgDQoNClRoZSByZXNvdXJjZSBvd25lciBwYXNzZXMgaW5mb3JtYXRpb24gdG8gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHRoYXQgc2F5czogdGhpcyBwZXJzb24gd2hvIGlzIG1ha2luZyB0aGlz IHJlcXVlc3QgKG9wdGlvbmFsbHk6IHdobyBjYW4gYXV0aGVudGljYXRlIHRoYXQgdGhleSBhcmUg dGhpcyBpZGVudGl0eSkgaXMgYXV0aG9yaXplZCB0byBhY2Nlc3MgdGhpcyByZXNvdXJjZSAob3B0 aW9uYWxseTogdGhlIHJlc291cmNlIGlzIGV4cGxpY2l0bHkgaWRlbnRpZmllZCkuICBUaGF0IHJl c291cmNlIGluIHRoZSBjb250ZXh0IG9mIHlvdXIgcXVlc3Rpb24gaXMgdGhlIGFjY2VzcyB0b2tl bjsgaXQncyBubyBkaWZmZXJlbnQgZm9yIHRoZSByZXNvdXJjZSB0aGF0IGlzIHRoZSBnb2FsIG9m IHRoZSB3aG9sZSB0aGluZyBbMV0uDQoNCj4gQWxpY2Ugc3RvcmVzIGhlciBjb250YWN0cyBhdCBj b250YWN0cy5leGFtcGxlLmNvbS4NCj4gDQo+IFNoZSB1c2VzIDIgY2xpZW50cywgb25lIG9uIHRo ZSBQQyBhbmQgb25lIG9uIGEgbW9iaWxlIHBob25lLiBUaGUgUEMNCj4gY2xpZW50IHVzZXMgdGhl IHN0YW5kYXJkIHJlZGlyZWN0LWJhc2VkIHByb2Nlc3MuIFRoZSBtb2JpbGUgcGhvbmUNCj4gY2xp ZW50DQo+IGNhbm5vdCB1c2UgdGhpcyBwcm9jZXNzIGJlY2F1c2Ugb2YgdGVjaG5pY2FsIGxpbWl0 YXRpb25zIChzbWFsbCBzY3JlZW4NCj4gc2l6ZSwgc3BhcnNlIGNvbXB1dGluZyBwb3dlciwgbm8g aW50ZWdyYXRpb24gQVBJIGZvciBlbWJlZGRpbmcgdGhlDQo+IGJyb3dzZXIgb3IgY3VzdG9tIHNj aGVtZXMpLiBUaGVyZWZvcmUgdGhpcyBjbGllbnQgdXNlcyB0aGUNCj4gdXNlcm5hbWUvcGFzc3dv cmQgZmxvdyBpbiBvcmRlciB0byBnZXQgYXV0aG9yaXphdGlvbiBhbmQgb2J0YWluIGENCj4gcmVm cmVzaCB0b2tlbi4gVGhlIGltcGxpY2F0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhlIGZsb3c6DQo+ IFBDIGNsaWVudDogcmVkaXJlY3QgdG8gZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludA0K PiBNb2JpbGUgcGhvbmUgY2xpZW50OiBhY2Nlc3MgdG8gdGhlIHRva2VucyBlbmRwb2ludCB3aXRo IHRoZSB1c2VyJ3MNCj4gY3JlZGVudGlhbHMNCg0KTm90ZSB0aGF0IEknbSBzdGlsbCBkZWFsaW5n IHdpdGggYW4gYWJzdHJhY3Rpb24gYXQgdGhpcyBwb2ludC4gIFRoZSBmYWN0IHRoYXQgdGhpcyBp bmZvcm1hdGlvbiBpcyBwYXNzZWQgdmlhIHRoZSBjbGllbnQgaXMgdGhlIGltcG9ydGFudCBjb25j ZXJuLCBwYXJ0aWN1bGFybHkgZm9yIHNlY3VyaXR5IHJlYXNvbnMsIGJlY2F1c2UgdGhlIGNsaWVu dCBpcyBhIHNoaWZ0eSwgbmFzdHkgaW5kaXZpZHVhbCB0aGF0IGNhbid0IGJlIHRydXN0ZWQgYXQg YWxsLg0KDQpJZGVhbGx5LCB0aGUgbW9iaWxlIHBob25lIGNsaWVudCBkb2Vzbid0IG5lZWQgdG8g ZG8gYW55dGhpbmcgYW55IGRpZmZlcmVudGx5LCBvdGhlciB0aGFuIChwZXJoYXBzKSBwcm92aWRl IGEgZGlmZmVyZW50IFVJLiAgDQoNClVJIGlzIHRoZSBwcm9ibGVtLiAgVGhlIHJlYWwgY29uY2Vy biBpcyB0aGUgcG90ZW50aWFsIEhUTUwgVUkgdGhhdCBoYXMgdG8gYmUgbmF2aWdhdGVkIHRvIGdy YW50L2dhaW4gYXV0aG9yaXphdGlvbi4gIFRoZSBtb2JpbGUgY2FuJ3QgY29wZSB3aXRoIEhUTUws IHByZXN1bWFibHkuICBJZiB0aGlzIHdlcmUganVzdCBIVFRQLCBpdCB3b3VsZCBiZSBubyB0cm91 YmxlLg0KDQpUaGUgcmVzb3VyY2UgdGhhdCBwcm92aWRlcyB0aGUgYWNjZXNzIHRva2VuIG1pZ2h0 IGJlIGFjY2Vzc2libGUgdXNpbmcgdXNlcm5hbWUvcGFzc3dvcmQgYWxvbmUgKGkuZS4gcmVxdWly aW5nIGF1dGhlbnRpY2F0aW9uLCBidXQgbm90IGV4cGxpY2l0IGF1dGhvcml6YXRpb24pLCBidXQg YXMgbG9uZyBhcyB0aGlzIGlzIG9ubHkgSFRUUCwgaXQncyBub3QgYSBwcm9ibGVtLiBbMl0NCg0K PiBTbyBhbHRob3VnaCB0aGUgcmVzb3VyY2Ugc2VydmVyJ3MgVVJMIGlzIHRoZSBzYW1lIGluIGJv dGggY2FzZXMsDQo+IGRpZmZlcmVudCBVUkxzIHdpbGwgYmUgdXRpbGl6ZWQgdG8gcHJvY2VzcyB0 aGUgYXV0aG9yaXphdGlvbiBmbG93Lg0KDQpEaXJlY3RpbmcgYSBjb25zdHJhaW5lZCBjbGllbnQg dG8gYSBkaWZmZXJlbnQgVVJMIG1pZ2h0IGJlIG9uZSB3YXkgdG8gc29sdmUgdGhlIHByb2JsZW0u ICBBbm90aGVyIHBvc3NpYmxlIHdheSBpcyB0byB1c2UgY29ubmVnOiBoYXZlIHRoZSBQQyBjbGll bnQgc2VuZCAiQWNjZXB0OiAqL2h0bWwiIGluIHRoZSByZXF1ZXN0IHRvIGluZGljYXRlIHRoYXQg aXQncyB3aWxsaW5nIHRvIHRvbGVyYXRlIEhUTUwgVUkuICBXaGVuIHRoZSBtb2JpbGUgY2xpZW50 IGRvZXNuJ3QsIGl0IGdldHMgZGlmZmVyZW50IHRyZWF0bWVudC4NCg0KLS1NYXJ0aW4NCg0KWzFd IF9USEVfIHJlc291cmNlLiAgTWF5YmUgdGhpcyBuZWVkcyBhIHNwZWNpYWwgbmFtZSB0b28uDQoN ClsyXSBJJ2xsIGxlYXZlIGFzaWRlIHRoZSBwb2ludCB0aGF0IGEgdXNlciBtaWdodCBub3QgdHJ1 c3QgdGhlIGNsaWVudCB3aXRoIHRoZWlyIHVzZXJuYW1lL3Bhc3N3b3JkLCBidXQgSSBndWVzcyB0 aGF0IHdlIGNhbiBlYXNpbHkgY3JlYXRlIHRlbXBvcmFyeSBvbmVzIGZvciB0aGlzLi4uDQoNCj4g cmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4gDQo+IEFtIDIyLjEwLjIwMTAgMDA6MzYsIHNjaHJpZWIg VGhvbXNvbiwgTWFydGluOg0KPiA+IGJsYWggYmxhaCBibGFoLi4uDQoNCg== From dorothy.gellert@gmail.com Mon Oct 25 11:13:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E0B3A6774 for ; Mon, 25 Oct 2010 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqCESmvho5W1 for ; Mon, 25 Oct 2010 11:13:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 447FE3A63D3 for ; Mon, 25 Oct 2010 11:13:32 -0700 (PDT) Received: by gya6 with SMTP id 6so2526717gya.31 for ; Mon, 25 Oct 2010 11:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HJ6Hc2ZL8swxz37M1rDunBEIaY2AtLqDcfVRy2zd+ao=; b=iK8FXULUEAOEvHo+K7VzpoI4ZTJG/nQJZ0EU1u1ER4jAZkWUnVBk90pLZcULX/+GhB g0LF02ZtvvQdvLoJwolf940P3CaR/HSYLKoKkQsyaJn8M60ygWzCt1zlgpi+0p5Ehy5S 2a+tP6aRaEOHArPeEjVjgFBu9gdNXRRhHazrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ka9rlqX2v5vVSI7S5euItn7AllPttfjHH01Kt/AY1w/pbuo5A4cE37UhSsZFpSVmmc I9Iubo/OonTI8TcCk2EBbusPhM8O429PgxG5XpEldCDuPTOKTI7+bSI0JbfjBTrJgUSO 5Jte1isXCYXsIcrmZNxT8NRRpIvf33uRMpQlA= MIME-Version: 1.0 Received: by 10.42.228.67 with SMTP id jd3mr5465852icb.353.1288030517291; Mon, 25 Oct 2010 11:15:17 -0700 (PDT) Received: by 10.42.162.196 with HTTP; Mon, 25 Oct 2010 11:15:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Oct 2010 11:15:17 -0700 Message-ID: From: Dorothy Gellert To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=20cf30549e7b716b6b049374f9e0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Informal Meeting @ IETF#79 (Beijing) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:13:34 -0000 --20cf30549e7b716b6b049374f9e0 Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, I'm attending the next IETF and would be interested in getting a handle on OAuth since we are not formally meeting at IETF79. I'm specifically interested in Open ID Connect and discovery and security, and... well just call it Interested! Best Regards, Dorothy On Fri, Oct 15, 2010 at 5:58 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > please drop me a mail if you plan to travel to Beijing and if you are > interested to chat about OAuth. We have no time restrictions (unlike with > working group meetings) and so we could go into the details of any topic. I > personally would be interested to do some OAuth security work. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf30549e7b716b6b049374f9e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hannes,

I'm attending the next=A0 IETF and would be intereste= d in getting a handle on OAuth since we are not formally meeting at IETF79.= =A0=A0 I'm specifically interested in Open ID Connect and discovery and= security, and... well just call it Interested!

Best Regards,
Dorothy



On F= ri, Oct 15, 2010 at 5:58 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

please drop me a mail if you plan to travel to Beijing and if you are inter= ested to chat about OAuth. We have no time restrictions (unlike with workin= g group meetings) and so we could go into the details of any topic. I perso= nally would be interested to do some OAuth security work.

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf30549e7b716b6b049374f9e0-- From tonynad@microsoft.com Mon Oct 25 12:58:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88EB83A67B3 for ; Mon, 25 Oct 2010 12:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.323 X-Spam-Level: X-Spam-Status: No, score=-10.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mawk9VlNtoix for ; Mon, 25 Oct 2010 12:58:46 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7FA263A6893 for ; Mon, 25 Oct 2010 12:58:46 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Oct 2010 13:00:32 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.4]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Mon, 25 Oct 2010 13:00:31 -0700 From: Anthony Nadalin To: "oauth@ietf.org" Thread-Topic: Status ? Thread-Index: Act0fohEYdlRQu03RC+t+i0YJG0Bnw== Date: Mon, 25 Oct 2010 20:00:31 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE3A9B1@TK5EX14MBXC115.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18FE3A9B1TK5EX14MBXC115red_" MIME-Version: 1.0 Subject: [OAUTH-WG] Status ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 19:58:47 -0000 --_000_180155C5EA10854997314CA5E063D18FE3A9B1TK5EX14MBXC115red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It has been quiet here, so 1. Did we get agreement to the document split (assume so as I did not= see any negatives), if so when can we expect draft 11 or the core and the = 1st draft of the new document? 2. Did we get editor(s) assigned to the new document? 3. Will there be a get together in Beijing to work on the security co= nsiderations section? If so do we have a preliminary draft of the security = considerations section? --_000_180155C5EA10854997314CA5E063D18FE3A9B1TK5EX14MBXC115red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It has been quiet here, so

 

1.     &= nbsp; Did we get agreement to the document split (assume = so as I did not see any negatives), if so when can we expect draft 11 or th= e core and the 1st draft of the new document?

2.     &= nbsp; Did we get editor(s) assigned to the new document?<= o:p>

3.     &= nbsp; Will there be a get together in Beijing to work on = the security considerations section? If so do we have a preliminary draft o= f the security considerations section?

 

--_000_180155C5EA10854997314CA5E063D18FE3A9B1TK5EX14MBXC115red_-- From Michael.Jones@microsoft.com Mon Oct 25 17:01:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193983A6C16 for ; Mon, 25 Oct 2010 17:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZAf6IEEsgvA for ; Mon, 25 Oct 2010 17:01:32 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 717E23A6C0E for ; Mon, 25 Oct 2010 17:01:29 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Oct 2010 17:03:15 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.185]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0255.003; Mon, 25 Oct 2010 17:03:14 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JSON token draft based upon a convergence proposal Thread-Index: Act0oS7NGc2KiqWMSi6mXz79GnRB9w== Date: Tue, 26 Oct 2010 00:03:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394324589908@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/mixed; boundary="_005_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_" MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" Subject: [OAUTH-WG] JSON token draft based upon a convergence proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 00:01:33 -0000 --_005_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_" --_000_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've produced a new JSON token draft (attached and also at http://self-issu= ed.info/docs/draft-jones-json-web-token-00.html) based on a convergence pro= posal discussed with the authors of the other JSON signing proposals. I bo= rrowed portions of this draft with permission from Dirk Balfanz, John Bradl= ey, John Panzer, and Nat Sakimura, and so listed them as co-authors. (You = shouldn't take their being listed as authors as their blanket endorsement o= f its content, but I appreciate their willingness to let me build upon thei= r work.) There are still open issues. In particular, while I call out the need for = including mechanism(s) for retrieving public keys that are not encoded in X= .509 certificates in the Open Issues (Section 11), I have not yet incorpora= ted them into the draft. For one thing, there was a comment that we should= consider publishing public keys as JWTs, which I haven't had the time to i= nvestigate yet. I'd also like to discuss whether we should assume that the= issuer claim can always be used to retrieve a simple public key or whether= we need to define a new claim or envelope parameter for that. Hopefully we can develop consensus positions on these and any other issues = found during IIW. This doc is intended as a further step in that direction= . A detailed comparison of the precursor documents, which led to the converge= nce proposal incorporated in this draft, is as follows: Feature JSON Tokens JSON Simple Sign (JSS) Canvas Application Signatures JSON Web Token (JWT) Proposed Resolution Envelope distinct from payload Yes Yes No No Yes Reserved claims defined for use in payload Yes No Yes Yes Yes - for optional use Overhead of encoding Medium High Low Low Low Signature algorithms supported (recommended marked +, optional marked *) HMAC SHA-256, RSA SHA-256 HMAC SHA-256, RSA SHA-256, ECDSA-SHA256 HMAC SHA-256 HMAC SHA-256, RSA SHA-256+, ECDSA-SHA256+, larger key sizes* HMAC SHA-256, RSA SHA-256, ECDSA-SHA256+, larger key sizes* Signing required Yes Yes Yes No Yes (but = "none" algorithm could be separately defined) Location of algorithm parameter Envelope Envelope Payload Payload Envelope Key ID parameter Optional in Envelope Optional in Envelope for HMAC SHA-256 N/A None Optional in Envelope Key location parameter Discovery method defined for RSA keys Required in envelope for RSA SHA-256 N/A None Optional key location or public key in Envelope; any key discovery in separ= ate specification(s) Key representation specified Yes - Magic Keys for RSA Yes - X.509 certificates for RSA SHA-256 N/A No Optional use of X.509 certificates specified; also specify non-X.509 method= (s) of public key retrieval; methods not in core spec can also be used Type description for envelope No Required type URI No No Optional using concise representation Type description for payload Optional in Envelope Optional in Payload No No Optional in Payload Encoding algorithm Base64url with padding Base64url without padding Base64url without padding Base64url without padding Base64url without padding Token representations Base64url encodings separated by periods; (JSON serialization specified in Magic Sig= natures) Base64url encodings separated by periods; JSON serialization Base64url encodings separated by periods Base64url encodings separated by periods Base64url encodings separated by periods Multiple signatures No (but supported by Magic Signatures) Yes No No Not in ba= se spec, but could be defined as an extension Encryption supported No In related specification No No In related specification Hope to see many of you next week! -- Mike --_000_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve produced a new JSON token draft (attached= and also at http://self-issued.info/docs/draft-jones-json-web-token-00.html) based = on a convergence proposal discussed with the authors of the other JSON sign= ing proposals.  I borrowed portions of this draft with permission from= Dirk Balfanz, John Bradley, John Panzer, and Nat Sakimura, and so listed them as co-authors.  (You shouldnR= 17;t take their being listed as authors as their blanket endorsement of its= content, but I appreciate their willingness to let me build upon their wor= k.)

 

There are still open issues.  In particular, wh= ile I call out the need for including mechanism(s) for retrieving public ke= ys that are not encoded in X.509 certificates in the Open Issues (Section 1= 1), I have not yet incorporated them into the draft.  For one thing, there was a comment that we should conside= r publishing public keys as JWTs, which I haven’t had the time to inv= estigate yet.  I’d also like to discuss whether we should assume= that the issuer claim can always be used to retrieve a simple public key or whether we need to define a new claim or envelope p= arameter for that.

 

Hopefully we can develop consensus positions on thes= e and any other issues found during IIW.  This doc is intended as a fu= rther step in that direction.

 

A detailed comparison of the precursor documents, wh= ich led to the convergence proposal incorporated in this draft, is as follo= ws:

 

Feature

JSON Tokens

JSON Simple Sign (JSS)

Canvas Application Signatures=

JSON Web Token (JWT)

Proposed Resolu= tion

Envelope distinct from payload

Yes

Yes

No

No

Yes

Reserved claims defined for use in payload

Yes

No

Yes

Yes

Yes – for= optional use

Overhead of encoding

Medium

High

Low

Low

Low

Signature algorithms supported (recommended marked +, optional marked *)<= span style=3D"color:black">

HMAC SHA-256, RSA SHA-256

HMAC SHA-256, RSA SHA-256, ECDSA-SHA256

HMAC SHA-256

HMAC SHA-256, RSA SHA-256+, ECDSA-SHA256+, larger key sizes*

HMAC SHA-256, RSA SHA-256, ECDSA-SHA256+, larger key sizes*

Signing required

Yes

Yes

Yes

No

Yes (but “none” algorithm co= uld be separately defined)

Location of algorithm parameter<= /p>

Envelope

Envelope

Payload

Payload

Envelope

Key ID parameter

Optional in Envelope

Optional in Envelope for HMAC SHA-256<= /span>

N/A

None

Optional in Envelope

Key location parameter<= /p>

Discovery method defined for RSA keys

Required in envelope for RSA SHA-256

N/A

None

Optional key location or public key in Envelope; any key discovery in separate specific= ation(s)

Key representation specified<= /p>

Yes - Magic Keys for RSA

Yes – X.509 certificates = for RSA SHA-256

N/A

No

Optional use of X.509 certificates specified; also specify non-X.509 method(s) of publi= c key retrieval; methods not in core spec can also be used

Type description for envelope

No

Required type URI

No

No

Optional using concise representation<= /o:p>

Type description for payload

Optional in Envelope

Optional in Payload

No

No

Optional in Payload

Encoding algorithm

Base64url with padding

Base64url without padding

Base64url without padding

Base64url without padding

Base64url without padding

Token representations

Base64url encodings separated by periods; (JSON serialization specified in Magic= Signatures)

Base64url encodings separated by periods; JSON serialization

Base64url encodings separated by periods

Base64url encodings separated by periods

Base64url encodings separated by periods

Multiple signatures

No (but supported by Magic Signatures)

Yes

No

No

Not in base spec, but could be defined as an extension

Encryption supported

No

In related specification

No

No

In related specification

 

Hope to see many of you next week!

 

        &nbs= p;            &= nbsp;            &nb= sp;            =              --= Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_-- --_005_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_ Content-Type: text/html; name="draft-jones-json-web-token-00.html" Content-Description: draft-jones-json-web-token-00.html Content-Disposition: attachment; filename="draft-jones-json-web-token-00.html"; size=103341; creation-date="Mon, 25 Oct 2010 23:30:01 GMT"; modification-date="Mon, 25 Oct 2010 21:09:14 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+SlNPTiBXZWIgVG9rZW4gKEpXVCk8L3RpdGxlPgo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ CjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJKU09OIFdlYiBUb2tlbiAoSldUKSI+ CjxtZXRhIG5hbWU9ImtleXdvcmRzIiBjb250ZW50PSJSRkMsIFJlcXVlc3QgZm9yIENvbW1lbnRz LCBJLUQsIEludGVybmV0LURyYWZ0LCBBc3NlcnRpb24sIENsYWltLCBTaW1wbGUgV2ViIFRva2Vu LCBTZWN1cml0eSBUb2tlbiwgU1dULCBKU09OIFdlYiBUb2tlbiwgSldULCBKYXZhU2NyaXB0IE9i amVjdCBOb3RhdGlvbiwgSlNPTiI+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0ieG1s MnJmYyB2MS4zNSAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvKSI+CjxzdHlsZSB0eXBlPSd0ZXh0 L2Nzcyc+PCEtLQogICAgICAgIGJvZHkgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IHZl cmRhbmEsIGNoYXJjb2FsLCBoZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNlcmlmOwogICAgICAgICAg ICAgICAgZm9udC1zaXplOiBzbWFsbDsgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNG RkY7CiAgICAgICAgICAgICAgICBtYXJnaW46IDJlbTsKICAgICAgICB9CiAgICAgICAgaDEsIGgy LCBoMywgaDQsIGg1LCBoNiB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNh LCBtb25hY28sICJNUyBTYW5zIFNlcmlmIiwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAgICAgICAg ICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zdHlsZTogbm9ybWFsOwogICAgICAgIH0KICAg ICAgICBoMSB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgdGV4 dC1hbGlnbjogcmlnaHQ7IH0KICAgICAgICBoMyB7IGNvbG9yOiAjMzMzOyBiYWNrZ3JvdW5kLWNv bG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICB0ZC5SRkNidWcgewogICAgICAgICAgICAgICAg Zm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7CiAgICAgICAgICAgICAg ICB3aWR0aDogMzBweDsgaGVpZ2h0OiAzMHB4OyBwYWRkaW5nLXRvcDogMnB4OwogICAgICAgICAg ICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVydGljYWwtYWxpZ246IG1pZGRsZTsKICAgICAg ICAgICAgICAgIGJhY2tncm91bmQtY29sb3I6ICMwMDA7CiAgICAgICAgfQogICAgICAgIHRkLlJG Q2J1ZyBzcGFuLlJGQyB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFy Y29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1z ZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBjb2xvcjogIzY2NjsKICAg ICAgICB9CiAgICAgICAgdGQuUkZDYnVnIHNwYW4uaG90VGV4dCB7CiAgICAgICAgICAgICAgICBm b250LWZhbWlseTogY2hhcmNvYWwsIG1vbmFjbywgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhl bHZldGljYSwgdmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0 OiBub3JtYWw7IHRleHQtYWxpZ246IGNlbnRlcjsgY29sb3I6ICNGRkY7CiAgICAgICAgfQoKICAg ICAgICB0YWJsZS5UT0NidWcgeyB3aWR0aDogMzBweDsgaGVpZ2h0OiAxNXB4OyB9CiAgICAgICAg dGQuVE9DYnVnIHsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGNlbnRlcjsgd2lkdGg6IDMw cHg7IGhlaWdodDogMTVweDsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5k LWNvbG9yOiAjOTAwOwogICAgICAgIH0KICAgICAgICB0ZC5UT0NidWcgYSB7CiAgICAgICAgICAg ICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJp ZiIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBi b2xkOyBmb250LXNpemU6IHgtc21hbGw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICAg ICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsKICAgICAg ICB9CgogICAgICAgIHRkLmhlYWRlciB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogYXJp YWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiB4LXNtYWxsOwogICAgICAgICAg ICAgICAgdmVydGljYWwtYWxpZ246IHRvcDsgd2lkdGg6IDMzJTsKICAgICAgICAgICAgICAgIGNv bG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjNjY2OwogICAgICAgIH0KICAgICAgICB0ZC5h dXRob3IgeyBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyBtYXJnaW4tbGVm dDogNGVtOyB9CiAgICAgICAgdGQuYXV0aG9yLXRleHQgeyBmb250LXNpemU6IHgtc21hbGw7IH0K CiAgICAgICAgLyogaW5mbyBjb2RlIGZyb20gU2FudGFLbGF1c3MgYXQgaHR0cDovL3d3dy5tYWRh Ym91dHN0eWxlLmNvbS90b29sdGlwMi5odG1sICovCiAgICAgICAgYS5pbmZvIHsKICAgICAgICAg ICAgICAgIC8qIFRoaXMgaXMgdGhlIGtleS4gKi8KICAgICAgICAgICAgICAgIHBvc2l0aW9uOiBy ZWxhdGl2ZTsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI0OwogICAgICAgICAgICAgICAgdGV4 dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgIH0KICAgICAgICBhLmluZm86aG92ZXIgewogICAg ICAgICAgICAgICAgei1pbmRleDogMjU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFj a2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgYS5pbmZvIHNwYW4geyBkaXNw bGF5OiBub25lOyB9CiAgICAgICAgYS5pbmZvOmhvdmVyIHNwYW4uaW5mbyB7CiAgICAgICAgICAg ICAgICAvKiBUaGUgc3BhbiB3aWxsIGRpc3BsYXkganVzdCBvbiA6aG92ZXIgc3RhdGUuICovCiAg ICAgICAgICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICAgICAgICAgIHBvc2l0aW9uOiBh YnNvbHV0ZTsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGxlcjsKICAgICAgICAgICAg ICAgIHRvcDogMmVtOyBsZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsKICAgICAgICAgICAgICAgIHBh ZGRpbmc6IDJweDsgYm9yZGVyOiAxcHggc29saWQgIzMzMzsKICAgICAgICAgICAgICAgIGNvbG9y OiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOwogICAgICAgICAgICAgICAgdGV4dC1hbGln bjogbGVmdDsKICAgICAgICB9CgogICAgICAgIGEgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAg ICAgIGE6bGluayAgICB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVu dDsgfQogICAgICAgIGE6dmlzaXRlZCB7IGNvbG9yOiAjNjMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgfQogICAgICAgIGE6YWN0aXZlICB7IGNvbG9yOiAjNjMzOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICBwIHsgbWFyZ2luLWxlZnQ6IDJlbTsgbWFy Z2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBwLmNvcHlyaWdodCB7IGZvbnQtc2l6ZTogeC1zbWFs bDsgfQogICAgICAgIHAudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6IGJvbGQ7 IG1hcmdpbi1sZWZ0OiAzZW07IH0KICAgICAgICB0YWJsZS50b2MgeyBtYXJnaW46IDAgMCAwIDNl bTsgcGFkZGluZzogMDsgYm9yZGVyOiAwOyB2ZXJ0aWNhbC1hbGlnbjogdGV4dC10b3A7IH0KICAg ICAgICB0ZC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdodDogYm9sZDsgdmVydGlj YWwtYWxpZ246IHRleHQtdG9wOyB9CgogICAgICAgIG9sLnRleHQgeyBtYXJnaW4tbGVmdDogMmVt OyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIHVsLnRleHQgeyBtYXJnaW4tbGVmdDogMmVt OyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIGxpICAgICAgeyBtYXJnaW4tbGVmdDogM2Vt OyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDxzcGFueD5zIGFuZCA8YXJ0d29yaz5zLiAqLwogICAg ICAgIGVtICAgICB7IGZvbnQtc3R5bGU6IGl0YWxpYzsgfQogICAgICAgIHN0cm9uZyB7IGZvbnQt d2VpZ2h0OiBib2xkOyB9CiAgICAgICAgZGZuICAgIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQt c3R5bGU6IG5vcm1hbDsgfQogICAgICAgIGNpdGUgICB7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZv bnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAgIHR0ICAgICB7IGNvbG9yOiAjMDM2OyB9CiAgICAg ICAgdHQsIHByZSwgcHJlIGRmbiwgcHJlIGVtLCBwcmUgY2l0ZSwgcHJlIHNwYW4gewogICAgICAg ICAgICAgICAgZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyIsIENvdXJpZXIsIG1vbm9zcGFjZTsg Zm9udC1zaXplOiBzbWFsbDsKICAgICAgICB9CiAgICAgICAgcHJlIHsKICAgICAgICAgICAgICAg IHRleHQtYWxpZ246IGxlZnQ7IHBhZGRpbmc6IDRweDsKICAgICAgICAgICAgICAgIGNvbG9yOiAj MDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAgIH0KICAgICAgICBwcmUgZGZuICB7 IGNvbG9yOiAjOTAwOyB9CiAgICAgICAgcHJlIGVtICAgeyBjb2xvcjogIzY2RjsgYmFja2dyb3Vu ZC1jb2xvcjogI0ZGQzsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgfQogICAgICAgIHByZSAua2V5IHsg Y29sb3I6ICMzM0M7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAgcHJlIC5pZCAgeyBjb2xv cjogIzkwMDsgfQogICAgICAgIHByZSAuc3RyIHsgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29s b3I6ICNDRkY7IH0KICAgICAgICBwcmUgLnZhbCB7IGNvbG9yOiAjMDY2OyB9CiAgICAgICAgcHJl IC5yZXAgeyBjb2xvcjogIzkwOTsgfQogICAgICAgIHByZSAub3RoIHsgY29sb3I6ICMwMDA7IGJh Y2tncm91bmQtY29sb3I6ICNGQ0Y7IH0KICAgICAgICBwcmUgLmVyciB7IGJhY2tncm91bmQtY29s b3I6ICNGQ0M7IH0KCiAgICAgICAgLyogUkZDLTI2MjkgPHRleHR0YWJsZT5zLiAqLwogICAgICAg IHRhYmxlLmFsbCwgdGFibGUuZnVsbCwgdGFibGUuaGVhZGVycywgdGFibGUubm9uZSB7CiAgICAg ICAgICAgICAgICBmb250LXNpemU6IHNtYWxsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGJvcmRlci13 aWR0aDogMnB4OwogICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246IHRvcDsgYm9yZGVyLWNv bGxhcHNlOiBjb2xsYXBzZTsKICAgICAgICB9CiAgICAgICAgdGFibGUuYWxsLCB0YWJsZS5mdWxs IHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsgYm9yZGVyLWNvbG9yOiBibGFjazsgfQogICAgICAgIHRh YmxlLmhlYWRlcnMsIHRhYmxlLm5vbmUgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KICAgICAgICB0 aCB7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgYm9yZGVyLWNvbG9yOiBibGFj azsKICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDogMnB4IDJweCAzcHggMnB4OwogICAgICAg IH0KICAgICAgICB0YWJsZS5hbGwgdGgsIHRhYmxlLmZ1bGwgdGggeyBib3JkZXItc3R5bGU6IHNv bGlkOyB9CiAgICAgICAgdGFibGUuaGVhZGVycyB0aCB7IGJvcmRlci1zdHlsZTogbm9uZSBub25l IHNvbGlkIG5vbmU7IH0KICAgICAgICB0YWJsZS5ub25lIHRoIHsgYm9yZGVyLXN0eWxlOiBub25l OyB9CiAgICAgICAgdGFibGUuYWxsIHRkIHsKICAgICAgICAgICAgICAgIGJvcmRlci1zdHlsZTog c29saWQ7IGJvcmRlci1jb2xvcjogIzMzMzsKICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDog MXB4IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuZnVsbCB0ZCwgdGFibGUuaGVhZGVycyB0 ZCwgdGFibGUubm9uZSB0ZCB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQoKICAgICAgICBociB7IGhl aWdodDogMXB4OyB9CiAgICAgICAgaHIuaW5zZXJ0IHsKICAgICAgICAgICAgICAgIHdpZHRoOiA4 MCU7IGJvcmRlci1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiAwOwogICAgICAgICAgICAgICAg Y29sb3I6ICNDQ0M7IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7CiAgICAgICAgfQotLT48L3N0eWxl Pgo8L2hlYWQ+Cjxib2R5Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSI2NiUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkPjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0i MSI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+TmV0d29yayBXb3JraW5nIEdyb3VwPC90ZD48dGQg Y2xhc3M9ImhlYWRlciI+TS4gSm9uZXMgKGVkaXRvcik8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImhlYWRlciI+SW50ZXJuZXQtRHJhZnQ8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5NaWNyb3NvZnQ8 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2s8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ELiBCYWxmYW56PC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPkV4cGlyZXM6IEFwcmlsIDI4LCAyMDExPC90ZD48dGQgY2xhc3M9 ImhlYWRlciI+R29vZ2xlPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwv dGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkouIEJyYWRsZXk8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+aW5kZXBlbmRlbnQ8L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+ WS4gR29sYW5kPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRk IGNsYXNzPSJoZWFkZXIiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVy Ij4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5KLiBQYW56ZXI8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+R29vZ2xlPC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNsYXNzPSJoZWFk ZXIiPk4uIFNha2ltdXJhPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwv dGQ+PHRkIGNsYXNzPSJoZWFkZXIiPk5vbXVyYSBSZXNlYXJjaCBJbnN0aXR1dGU8L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+T2N0 b2JlciAyNSwgMjAxMDwvdGQ+PC90cj4KPC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KPGgxPjxi ciAvPkpTT04gV2ViIFRva2VuIChKV1QpPGJyIC8+ZHJhZnQtam9uZXMtanNvbi13ZWItdG9rZW4t MDA8L2gxPgoKPGgzPkFic3RyYWN0PC9oMz4KCjxwPkpTT04gV2ViIFRva2VuIChKV1QpIGRlZmlu ZXMgYSB0b2tlbiBmb3JtYXQgdGhhdCBjYW4gZW5jb2RlCiAgICAgIGNsYWltcyB0cmFuc2ZlcnJl ZCBiZXR3ZWVuIHR3byBwYXJ0aWVzLiBUaGUgY2xhaW1zIGluIGEgSldUIGFyZQogICAgICBlbmNv ZGVkIGFzIGEgSlNPTiBvYmplY3QgdGhhdCBpcyBkaWdpdGFsbHkgc2lnbmVkLgo8L3A+CjxoMz5S ZXF1aXJlbWVudHMgTGFuZ3VhZ2U8L2gzPgoKPHA+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNU IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAgICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cwogICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjExOSc+UkZDIDIxMTk8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QnJhZG5lciwgUy4sICZsZHF1bztLZXkgd29yZHMgZm9yIHVzZSBpbiBS RkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscywmcmRxdW87IE1hcmNoJm5ic3A7MTk5 Ny48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMyMTE5XS4KPC9wPgo8aDM+U3RhdHVzIG9m IHRoaXMgTWVtbzwvaDM+CjxwPgpUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCAgaW4g ZnVsbApjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCZuYnNwOzc4IGFuZCBC Q1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhh dCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQp3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50CkludGVybmV0LURyYWZ0cyBpcyBh dCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvcD4KPHA+Cklu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhl ciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDI4LCAyMDExLjwvcD4KCjxoMz5Db3B5 cmlnaHQgTm90aWNlPC9oMz4KPHA+CkNvcHlyaWdodCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQpkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC48L3A+CjxwPgpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsClByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMKKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9u IHRoZSBkYXRlIG9mCnB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50cwpjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMg YW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKdG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21w b25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAppbmNsdWRlIFNpbXBsaWZp ZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFz CmRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3A+CjxhIG5hbWU9InRv YyI+PC9hPjxiciAvPjxociAvPgo8aDM+VGFibGUgb2YgQ29udGVudHM8L2gzPgo8cCBjbGFzcz0i dG9jIj4KPGEgaHJlZj0iI2FuY2hvcjEiPjEuPC9hPiZuYnNwOwpJbnRyb2R1Y3Rpb248YnIgLz4K PGEgaHJlZj0iI2FuY2hvcjIiPjIuPC9hPiZuYnNwOwpUZXJtaW5vbG9neTxiciAvPgo8YSBocmVm PSIjYW5jaG9yMyI+My48L2E+Jm5ic3A7CkpTT04gV2ViIFRva2VuIChKV1QpIE92ZXJ2aWV3PGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0Ij4zLjEuPC9hPiZu YnNwOwpFeGFtcGxlIEpXVDxiciAvPgo8YSBocmVmPSIjYW5jaG9yNSI+NC48L2E+Jm5ic3A7CkpX VCBDbGFpbXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI1Jlc2VydmVk Q2xhaW1OYW1lIj40LjEuPC9hPiZuYnNwOwpSZXNlcnZlZCBDbGFpbSBOYW1lczxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjUHVibGljQ2xhaW1OYW1lIj40LjIuPC9hPiZu YnNwOwpQdWJsaWMgQ2xhaW0gTmFtZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI1ByaXZhdGVDbGFpbU5hbWUiPjQuMy48L2E+Jm5ic3A7ClByaXZhdGUgQ2xhaW0gTmFt ZXM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjYiPjUuPC9hPiZuYnNwOwpKV1QgRW52ZWxvcGU8YnIg Lz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI1Jlc2VydmVkRW52ZWxvcGVQYXJh bWV0ZXJOYW1lIj41LjEuPC9hPiZuYnNwOwpSZXNlcnZlZCBFbnZlbG9wZSBQYXJhbWV0ZXIgTmFt ZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI1B1YmxpY0VudmVsb3Bl UGFyYW1ldGVyTmFtZSI+NS4yLjwvYT4mbmJzcDsKUHVibGljIEVudmVsb3BlIFBhcmFtZXRlciBO YW1lczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjUHJpdmF0ZUVudmVs b3BlUGFyYW1ldGVyTmFtZSI+NS4zLjwvYT4mbmJzcDsKUHJpdmF0ZSBFbnZlbG9wZSBQYXJhbWV0 ZXIgTmFtZXM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjciPjYuPC9hPiZuYnNwOwpHZW5lcmFsIFJ1 bGVzIGZvciBDcmVhdGluZyBhbmQgVmFsaWRhdGluZyBhIEpXVDxiciAvPgo8YSBocmVmPSIjYmFz ZTY0dXJsbG9naWMiPjcuPC9hPiZuYnNwOwpCYXNlNjR1cmwgZW5jb2RpbmcgYXMgdXNlZCBieSBK V1RzPGJyIC8+CjxhIGhyZWY9IiNTaWduaW5nIj44LjwvYT4mbmJzcDsKU2lnbmluZyBKV1RzIHdp dGggQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG1zPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNTaWduaW5nV2l0aEhNQUNTSEEyNTYiPjguMS48L2E+Jm5ic3A7ClNpZ25pbmcg YSBKV1Qgd2l0aCBITUFDIFNIQS0yNTY8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI0RlZmluaW5nUlNBIj44LjIuPC9hPiZuYnNwOwpTaWduaW5nIGEgSldUIHdpdGggUlNB IFNIQS0yNTY8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI0RlZmluaW5n RUNEU0EiPjguMy48L2E+Jm5ic3A7ClNpZ25pbmcgYSBKV1Qgd2l0aCBFQ0RTQSBQLTI1NiBTSEEt MjU2PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I4Ij44LjQu PC9hPiZuYnNwOwpBZGRpdGlvbmFsIEFsZ29yaXRobXM8YnIgLz4KPGEgaHJlZj0iI0lBTkEiPjku PC9hPiZuYnNwOwpJQU5BIENvbnNpZGVyYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNTZWN1cml0eSI+ MTAuPC9hPiZuYnNwOwpTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yOSI+MTAuMS48L2E+Jm5ic3A7ClVuaWNvZGUgQ29t cGFyaXNvbiBTZWN1cml0eSBJc3N1ZXM8YnIgLz4KPGEgaHJlZj0iI09wZW5Jc3N1ZXMiPjExLjwv YT4mbmJzcDsKT3BlbiBJc3N1ZXM8YnIgLz4KPGEgaHJlZj0iI0Fja25vd2xlZGdlbWVudHMiPjEy LjwvYT4mbmJzcDsKQWNrbm93bGVkZ2VtZW50czxiciAvPgo8YSBocmVmPSIjSldURXhhbXBsZXMi PjEzLjwvYT4mbmJzcDsKQXBwZW5kaXggLSBOb24tTm9ybWF0aXZlIC0gSldUIEV4YW1wbGVzPGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNITUFDU0hBMjU2RXhhbXBsZSI+ MTMuMS48L2E+Jm5ic3A7CkpXVCB1c2luZyBITUFDIFNIQS0yNTY8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjEwIj4x My4xLjEuPC9hPiZuYnNwOwpFbmNvZGluZzxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTEiPjEzLjEuMi48L2E+Jm5i c3A7CkRlY29kaW5nPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMiI+MTMuMS4zLjwvYT4mbmJzcDsKVmFsaWRhdGlu ZzxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTMiPjEzLjIu PC9hPiZuYnNwOwpKV1QgdXNpbmcgUlNBIFNIQS0yNTY8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE0Ij4xMy4yLjEu PC9hPiZuYnNwOwpFbmNvZGluZzxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTUiPjEzLjIuMi48L2E+Jm5ic3A7CkRl Y29kaW5nPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3IxNiI+MTMuMi4zLjwvYT4mbmJzcDsKVmFsaWRhdGluZzxiciAv PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTciPjEzLjMuPC9hPiZu YnNwOwpKV1QgdXNpbmcgRUNEU0EgUC0yNTYgU0hBLTI1NjxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTgiPjEzLjMu MS48L2E+Jm5ic3A7CkVuY29kaW5nPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxOSI+MTMuMy4yLjwvYT4mbmJzcDsK RGVjb2Rpbmc8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjIwIj4xMy4zLjMuPC9hPiZuYnNwOwpWYWxpZGF0aW5nPGJy IC8+CjxhIGhyZWY9IiNiYXNlNjR1cmxub3RlcyI+MTQuPC9hPiZuYnNwOwpBcHBlbmRpeCAtIE5v bi1Ob3JtYXRpdmUgLSBOb3RlcyBvbiBpbXBsZW1lbnRpbmcgYmFzZTY0dXJsIGVuY29kaW5nIHdp dGhvdXQgcGFkZGluZzxiciAvPgo8YSBocmVmPSIjYW5jaG9yMjEiPjE1LjwvYT4mbmJzcDsKQXBw ZW5kaXggLSBOb24tTm9ybWF0aXZlIC0gUmVsYXRpb25zaGlwIG9mIEpXVHMgdG8gU0FNTCBUb2tl bnM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjIyIj4xNi48L2E+Jm5ic3A7CkFwcGVuZGl4IC0gTm9u LU5vcm1hdGl2ZSAtIFJlbGF0aW9uc2hpcCBvZiBKV1RzIHRvIFNpbXBsZSBXZWIgVG9rZW5zIChT V1RzKTxiciAvPgo8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4xNy48L2E+Jm5ic3A7ClJlZmVy ZW5jZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5yZWZlcmVu Y2VzMSI+MTcuMS48L2E+Jm5ic3A7Ck5vcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczIiPjE3LjIuPC9hPiZuYnNw OwpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CjxhIGhyZWY9IiNyZmMuYXV0aG9ycyI+JiMx Njc7PC9hPiZuYnNwOwpBdXRob3JzJyBBZGRyZXNzZXM8YnIgLz4KPC9wPgo8YnIgY2xlYXI9ImFs bCIgLz4KCjxhIG5hbWU9ImFuY2hvcjEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xIj48 L2E+PGgzPjEuJm5ic3A7CkludHJvZHVjdGlvbjwvaDM+Cgo8cD5KU09OIFdlYiBUb2tlbiAoSldU KSBpcyBhIHNpbXBsZSB0b2tlbiBmb3JtYXQgaW50ZW5kZWQgZm9yCiAgICAgIHNwYWNlIGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cyBzdWNoIGFzIEhUVFAgQXV0aG9yaXphdGlvbgogICAgICBoZWFk ZXJzIGFuZCBVUkkgcXVlcnkgcGFyYW1ldGVycy4gSldUcyBlbmNvZGUgdGhlIGNsYWltcyB0byBi ZQogICAgICB0cmFuc21pdHRlZCBhcyBhIEpTT04gb2JqZWN0IChhcyBkZWZpbmVkIGluIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjUkZDNDYyNyc+UkZDIDQ2Mjc8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+Q3JvY2tmb3JkLCBELiwgJmxkcXVvO1RoZSBhcHBsaWNhdGlvbi9qc29uIE1l ZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKSwmcmRxdW87IEp1 bHkmbmJzcDsyMDA2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzQ2MjddKSB0aGF0IGlz IGJhc2U2NHVybCBlbmNvZGVkIGFuZAogICAgICBkaWdpdGFsbHkgc2lnbmVkLgo8L3A+CjxwPlRo ZSBzdWdnZXN0ZWQgcHJvbnVuY2lhdGlvbiBvZiBKV1QgaXMgdGhlIHNhbWUgYXMgdGhlIEVuZ2xp c2ggd29yZCAiam90Ii4KPC9wPgo8YSBuYW1lPSJhbmNob3IyIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uMiI+PC9hPjxoMz4yLiZuYnNwOwpUZXJtaW5vbG9neTwvaDM+Cgo8cD48L3A+Cjxi bG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5KU09OIFdlYiBUb2tlbiAoSldUKTwvZHQ+ CjxkZD5BIHN0cmluZyBjb25zaXN0aW5nIG9mCiAgICAgICAgICB0aHJlZSBKV1QgVG9rZW4gU2Vn bWVudHM6IHRoZSBKV1QgRW52ZWxvcGUgU2VnbWVudCwgdGhlIEpXVAogICAgICAgICAgQ2xhaW0g U2VnbWVudCwgYW5kIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQsIGluIHRoYXQgb3JkZXIsCiAgICAg ICAgICB3aXRoIHRoZSBzZWdtZW50cyBiZWluZyBzZXBhcmF0ZWQgYnkgcGVyaW9kICgnLicpCiAg ICAgICAgICBjaGFyYWN0ZXJzLgo8L2RkPgo8ZHQ+SldUIFRva2VuIFNlZ21lbnQ8L2R0Pgo8ZGQ+ T25lIG9mIHRoZSB0aHJlZSBwYXJ0cyB0aGF0CiAgICAgICAgICBtYWtlIHVwIGEgSlNPTiBXZWIg VG9rZW4gKEpXVCkuICBKV1QgVG9rZW4gU2VnbWVudHMgYXJlCiAgICAgICAgICBhbHdheXMgYmFz ZTY0dXJsIGVuY29kZWQgdmFsdWVzLgo8L2RkPgo8ZHQ+SldUIEVudmVsb3BlIFNlZ21lbnQ8L2R0 Pgo8ZGQ+QSBKV1QgVG9rZW4gU2VnbWVudAogICAgICAgICAgY29udGFpbmluZyBhIGJhc2U2NHVy bCBlbmNvZGVkIEpTT04gb2JqZWN0IHRoYXQgZGVzY3JpYmVzCiAgICAgICAgICB0aGUgc2lnbmF0 dXJlIGFwcGxpZWQgdG8gdGhlIEpXVCBDbGFpbSBTZWdtZW50Lgo8L2RkPgo8ZHQ+SldUIENsYWlt IFNlZ21lbnQ8L2R0Pgo8ZGQ+QSBKV1QgVG9rZW4gU2VnbWVudAogICAgICAgICAgY29udGFpbmlu ZyBhIGJhc2U2NHVybCBlbmNvZGVkIEpTT04gb2JqZWN0IHRoYXQgZW5jb2RlcyB0aGUKICAgICAg ICAgIGNsYWltcyByZXByZXNlbnRlZCBieSB0aGUgSldULgo8L2RkPgo8ZHQ+SldUIENyeXB0byBT ZWdtZW50PC9kdD4KPGRkPkEgSldUIFRva2VuIFNlZ21lbnQKICAgICAgICAgIGNvbnRhaW5pbmcg YmFzZTY0dXJsIGVuY29kZWQgY3J5cHRvZ3JhcGhpYyBzaWduYXR1cmUKICAgICAgICAgIG1hdGVy aWFsIHRoYXQgc2VjdXJlcyB0aGUgSldUIENyeXB0byBTZWdtZW50J3MgY29udGVudHMuCjwvZGQ+ CjxkdD5EZWNvZGVkIEpXVCBFbnZlbG9wZSBTZWdtZW50PC9kdD4KPGRkPkEgSldUIEVudmVsb3Bl IFNlZ21lbnQgdGhhdAogICAgICAgICAgaGFzIGJlZW4gYmFzZTY0dXJsIGRlY29kZWQgYmFjayBp bnRvIGEgSlNPTiBvYmplY3QuCjwvZGQ+CjxkdD5EZWNvZGVkIEpXVCBDbGFpbSBTZWdtZW50PC9k dD4KPGRkPkEgSldUIENsYWltIFNlZ21lbnQgdGhhdAogICAgICAgICAgaGFzIGJlZW4gYmFzZTY0 dXJsIGRlY29kZWQgYmFjayBpbnRvIGEgSlNPTiBvYmplY3QuCjwvZGQ+CjxkdD5EZWNvZGVkIEpX VCBDcnlwdG8gU2VnbWVudDwvZHQ+CjxkZD5BIEpXVCBDcnlwdG8gU2VnbWVudCB0aGF0CiAgICAg ICAgICBoYXMgYmVlbiBiYXNlNjR1cmwgZGVjb2RlZCBiYWNrIGludG8gY3J5cHRvZ3JhcGhpYyBt YXRlcmlhbC4KPC9kZD4KPGR0PkJhc2U2NHVybCBFbmNvZGluZzwvZHQ+CjxkZD5Gb3IgdGhlIHB1 cnBvc2VzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgCiAgICAgICAgICB0aGlzIHRlcm0gYWx3YXlz IHJlZmVycyB0byB0aGUgaGUgVVJMLSBhbmQgZmlsZW5hbWUtc2FmZSBCYXNlNjQKICAgICAgICAg IGVuY29kaW5nIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzQ2NDgnPlJG QyA0NjQ4PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvc2Vmc3NvbiwgUy4sICZs ZHF1bztUaGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3MsJnJkcXVv OyBPY3RvYmVyJm5ic3A7MjAwNi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM0NjQ4XSwg U2VjdGlvbiA1LAogICAgICAgICAgd2l0aCB0aGUgJz0nIHBhZGRpbmcgY2hhcmFjdGVycyBvbWl0 dGVkLCBhcyBwZXJtaXR0ZWQgYnkgU2VjdGlvbiAzLjI7CiAgICAgICAgICBzZWUgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNiYXNlNjR1cmxsb2dpYyc+U2VjdGlvbiZuYnNwOzc8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+QmFzZTY0dXJsIGVuY29kaW5nIGFzIHVzZWQgYnkgSldUczwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZm9yIG1vcmUgZGV0YWlscy4KPC9kZD4KPC9kbD48L2Js b2NrcXVvdGU+Cgo8YSBuYW1lPSJhbmNob3IzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u MyI+PC9hPjxoMz4zLiZuYnNwOwpKU09OIFdlYiBUb2tlbiAoSldUKSBPdmVydmlldzwvaDM+Cgo8 cD5KV1RzIHJlcHJlc2VudCBhIHNldCBvZiBjbGFpbXMgYXMgYSBKU09OIG9iamVjdCB0aGF0IGlz CiAgICAgIGJhc2U2NHVybCBlbmNvZGVkIGFuZCBkaWdpdGFsbHkgc2lnbmVkLiAgQXMgcGVyIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNDYyNyc+UkZDIDQ2Mjc8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+Q3JvY2tmb3JkLCBELiwgJmxkcXVvO1RoZSBhcHBsaWNhdGlvbi9qc29u IE1lZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKSwmcmRxdW87 IEp1bHkmbmJzcDsyMDA2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzQ2MjddIFNlY3Rp b24gMi4yLCB0aGUgSlNPTiBvYmplY3QKICAgICAgY29uc2lzdHMgb2YgemVybyBvciBtb3JlIG5h bWUvdmFsdWUgcGFpcnMgKG9yIG1lbWJlcnMpLCB3aGVyZQogICAgICB0aGUgbmFtZXMgYXJlIHN0 cmluZ3MgYW5kIHRoZSB2YWx1ZXMgYXJlIGFyYml0cmFyeSBKU09OIHZhbHVlcy4KICAgICAgVGhl c2UgbWVtYmVycyBhcmUgdGhlIGNsYWltcyByZXByZXNlbnRlZCBieSB0aGUgSldULiAgVGhlIEpT T04KICAgICAgb2JqZWN0IGlzIGJhc2U2NHVybCBlbmNvZGVkIHRvIHByb2R1Y2UgdGhlIEpXVCBD bGFpbSBTZWdtZW50LiBBbgogICAgICBhY2NvbXBhbnlpbmcgYmFzZTY0dXJsIGVuY29kZWQgSlNP TiBlbnZlbG9wZSBvYmplY3QgZGVzY3JpYmVzCiAgICAgIHRoZSBzaWduYXR1cmUgbWV0aG9kIHVz ZWQuCjwvcD4KPHA+VGhlIG5hbWVzIHdpdGhpbiB0aGUgb2JqZWN0IE1VU1QgYmUgdW5pcXVlLiAg VGhlIG5hbWVzIHdpdGhpbgogICAgICB0aGUgSlNPTiBvYmplY3QgYXJlIHJlZmVycmVkIHRvIGFz IENsYWltIE5hbWVzLiAgVGhlCiAgICAgIGNvcnJlc3BvbmRpbmcgdmFsdWVzIGFyZSByZWZlcnJl ZCB0byBhcyBDbGFpbSBWYWx1ZXMuCjwvcD4KPHA+SldUcyBjb250YWluIGEgc2lnbmF0dXJlIHRo YXQgZW5zdXJlcyB0aGUgaW50ZWdyaXR5IG9mIHRoZQogICAgICBjb250ZW50IG9mIHRoZSBKU09O IENsYWltIFNlZ21lbnQuICBUaGlzIHNpZ25hdHVyZSB2YWx1ZSBpcwogICAgICBjYXJyaWVkIGlu IHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQuICBUaGUgSlNPTiBFbnZlbG9wZSBvYmplY3QKICAgICAg TVVTVCBjb250YWluIGFuICJhbGciIHBhcmFtZXRlciwgdGhlIHZhbHVlIG9mIHdoaWNoIGlzIGEg c3RyaW5nCiAgICAgIHRoYXQgdW5hbWJpZ3VvdXNseSBpZGVudGlmaWVzIHRoZSBhbGdvcml0aG0g dXNlZCB0byBzaWduIHRoZSBKV1QKICAgICAgQ2xhaW0gU2VnbWVudCB0byBwcm9kdWNlIHRoZSBK V1QgQ3J5cHRvIFNlZ21lbnQuCjwvcD4KPGEgbmFtZT0iYW5jaG9yNCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjMuMSI+PC9hPjxoMz4zLjEuJm5ic3A7CkV4YW1wbGUgSldUPC9oMz4KCjxw PlRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSBvZiBhIEpTT04gb2JqZWN0IHRoYXQgY2FuIGJl CiAgICAgIGVuY29kZWQgdG8gcHJvZHVjZSBhIEpXVDoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPnsiaXNzIjoiam9lIiwKICJleHAiOjEzMDA4MTkzODAsCiAiaHR0cDovL2V4YW1wbGUuY29t L2lzX3Jvb3QiOnRydWV9PC9wcmU+PC9kaXY+CjxwPkJhc2U2NHVybCBlbmNvZGluZyB0aGUgVVRG LTggcmVwcmVzZW50YXRpb24gb2YgdGhlIEpTT04KICAgICAgb2JqZWN0IHlpZWxkcyB0aGlzIEpX VCBDbGFpbSBTZWdtZW50IHZhbHVlOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdp ZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ZXlKcGMz TWlPaUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTlsZUdG dGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUTwvcHJlPjwvZGl2Pgo8cD5UaGUgZm9sbG93 aW5nIGV4YW1wbGUgSlNPTiBlbnZlbG9wZSBvYmplY3QgZGVjbGFyZXMgdGhhdCB0aGUKICAgICAg ZW5jb2RlZCBvYmplY3QgaXMgYSBKU09OIFdlYiBUb2tlbiAoSldUKSBhbmQgdGhlIEpXVCBDbGFp bQogICAgICBTZWdtZW50IGlzIHNpZ25lZCB1c2luZyB0aGUgSE1BQyBTSEEtMjU2IGFsZ29yaXRo bToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnsidHlwIjoiSldUIiwKICJhbGciOiJIUzI1 NiJ9PC9wcmU+PC9kaXY+CjxwPkJhc2U2NHVybCBlbmNvZGluZyB0aGUgVVRGLTggcmVwcmVzZW50 YXRpb24gb2YgdGhlIEpTT04gZW52ZWxvcGUKICAgICAgb2JqZWN0IHlpZWxkcyB0aGlzIEpXVCBF bnZlbG9wZSBTZWdtZW50IHZhbHVlOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdp ZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ZXlKMGVY QWlPaUpLVjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOTwvcHJlPjwvZGl2Pgo8cD5TaWduaW5n IHRoZSBKV1QgQ2xhaW0gU2VnbWVudCB3aXRoIHRoZSBITUFDIFNIQS0yNTYgYWxnb3JpdGhtCiAg ICAgIGFuZCBiYXNlNjR1cmwgZW5jb2RpbmcgdGhlIHJlc3VsdCwgYXMgcGVyIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjU2lnbmluZ1dpdGhITUFDU0hBMjU2Jz5TZWN0aW9uJm5ic3A7OC4xPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlNpZ25pbmcgYSBKV1Qgd2l0aCBITUFDIFNIQS0y NTY8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCB5aWVsZHMgdGhpcyBKV1QgQ3J5cHRvIFNlZ21l bnQgdmFsdWU6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4zNXVzV2o5WDhId0dTLUNEY3gx SlAyTm1xY3JMd1o0RUtwOHNOVGhmM2NZPC9wcmU+PC9kaXY+CjxwPkNvbWJpbmluZyB0aGVzZSBz ZWdtZW50cyBpbiB0aGUgb3JkZXIKICAgICAgRW52ZWxvcGUuQ2xhaW1zLlNpZ25hdHVyZSB3aXRo IHBlcmlvZCBjaGFyYWN0ZXJzIGJldHdlZW4gdGhlCiAgICAgIHNlZ21lbnRzIHlpZWxkcyB0aGlz IGNvbXBsZXRlIEpXVCAod2l0aCBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheQogICAgICBwdXJwb3Nl cyBvbmx5KToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2lu LWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPmV5SjBlWEFpT2lKS1YxUWlMQTBL SUNKaGJHY2lPaUpJVXpJMU5pSjkKLgpleUpwYzNNaU9pSnFiMlVpTEEwS0lDSmxlSEFpT2pFek1E QTRNVGt6T0RBc0RRb2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAwY25W bGZRCi4KMzV1c1dqOVg4SHdHUy1DRGN4MUpQMk5tcWNyTHdaNEVLcDhzTlRoZjNjWTwvcHJlPjwv ZGl2Pgo8cD5UaGlzIGNvbXB1dGF0aW9uIGlzIGlsbHVzdHJhdGVkIGluIG1vcmUgZGV0YWlsIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjSE1BQ1NIQTI1NkV4YW1wbGUnPlNlY3Rpb24mbmJzcDsx My4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpXVCB1c2luZyBITUFDIFNIQS0y NTY8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L3A+CjxhIG5hbWU9ImFuY2hvcjUiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40Ij48L2E+PGgzPjQuJm5ic3A7CkpXVCBDbGFpbXM8L2gz PgoKPHA+VGhlIG1lbWJlcnMgb2YgdGhlIEpTT04gb2JqZWN0IHJlcHJlc2VudGVkIGJ5IHRoZSBE ZWNvZGVkIEpXVAogICAgICBDbGFpbSBTZWdtZW50IGNvbnRhaW4gdGhlIGNsYWltcy4gTm90ZSBo b3dldmVyLCB0aGF0IHRoZSBzZXQgb2YKICAgICAgY2xhaW1zIGEgSldUIG11c3QgY29udGFpbiB0 byBiZSBjb25zaWRlcmVkIHZhbGlkIGlzCiAgICAgIGNvbnRleHQtZGVwZW5kZW50IGFuZCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgICAgIHNwZWNpZmljYXRpb24uCjwvcD4KPHA+VGhl cmUgYXJlIHRocmVlIGNsYXNzZXMgb2YgSldUIENsYWltIE5hbWVzOiAgUmVzZXJ2ZWQgQ2xhaW0g TmFtZXMsIFB1YmxpYyBDbGFpbSBOYW1lcywgYW5kIFByaXZhdGUgQ2xhaW0gTmFtZXMuCjwvcD4K PGEgbmFtZT0iUmVzZXJ2ZWRDbGFpbU5hbWUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40 LjEiPjwvYT48aDM+NC4xLiZuYnNwOwpSZXNlcnZlZCBDbGFpbSBOYW1lczwvaDM+Cgo8cD5UaGUg Zm9sbG93aW5nIGNsYWltIG5hbWVzIGFyZSByZXNlcnZlZC4gTm9uZSBvZiB0aGUgY2xhaW1zCglk ZWZpbmVkIGluIHRoZSB0YWJsZSBiZWxvdyBhcmUgaW50ZW5kZWQgdG8gYmUgbWFuZGF0b3J5LCBi dXQKCXJhdGhlciwgcHJvdmlkZSBhIHN0YXJ0aW5nIHBvaW50IGZvciBhIHNldCBvZiB1c2VmdWws CglpbnRlcm9wZXJhYmxlIGNsYWltcy4gIEFsbCB0aGUgbmFtZXMgYXJlIHNob3J0IGJlY2F1c2Ug YSBjb3JlCglnb2FsIG9mIEpXVHMgaXMgZm9yIHRoZSB0b2tlbnMgdGhlbXNlbHZlcyB0byBiZSBz aG9ydC4KPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJDbGFpbVRhYmxl Ij48L2E+Cjx0YWJsZSBjbGFzcz0iZnVsbCIgYWxpZ249ImNlbnRlciIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjIiPgo8Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWdu PSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij4KPHRyPjx0aCBhbGln bj0ibGVmdCI+Q2xhaW0gTmFtZTwvdGg+PHRoIGFsaWduPSJsZWZ0Ij5KU09OIFZhbHVlIFR5cGU8 L3RoPjx0aCBhbGlnbj0ibGVmdCI+Q2xhaW0gU3ludGF4PC90aD48dGggYWxpZ249ImxlZnQiPkNs YWltIFNlbWFudGljczwvdGg+PC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPmV4cDwvdGQ+Cjx0 ZCBhbGlnbj0ibGVmdCI+aW50ZWdlcjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SW50RGF0ZTwvdGQ+ Cjx0ZCBhbGlnbj0ibGVmdCI+VGhlICJleHAiIChleHBpcmF0aW9uIHRpbWUpIGNsYWltIGlkZW50 aWZpZXMgdGhlCgkgIGV4cGlyYXRpb24gdGltZSBvbiBvciBhZnRlciB3aGljaCB0aGUgdG9rZW4g TVVTVCBOT1QgYmUKCSAgYWNjZXB0ZWQgZm9yIHByb2Nlc3NpbmcuICBUaGUgcHJvY2Vzc2luZyBv ZiB0aGUgImV4cCIgY2xhaW0KCSAgcmVxdWlyZXMgdGhhdCB0aGUgY3VycmVudCBkYXRlL3RpbWUg TVVTVCBiZSBiZWZvcmUgdGhlCgkgIGV4cGlyYXRpb24gZGF0ZS90aW1lIGxpc3RlZCBpbiB0aGUg ImV4cCIgY2xhaW0uIEltcGxlbWVudGVycwoJICBNQVkgcHJvdmlkZSBmb3Igc29tZSBzbWFsbCBs ZWV3YXksIHVzdWFsbHkgbm8gbW9yZSB0aGFuIGEKCSAgZmV3IG1pbnV0ZXMsIHRvIGFjY291bnQg Zm9yIGNsb2NrIHNrZXcuICBUaGlzIGNsYWltIGlzCgkgIE9QVElPTkFMLjwvdGQ+CjwvdHI+Cjx0 cj4KPHRkIGFsaWduPSJsZWZ0Ij5pc3M8L3RkPgo8dGQgYWxpZ249ImxlZnQiPnN0cmluZzwvdGQ+ Cjx0ZCBhbGlnbj0ibGVmdCI+U3RyaW5nQW5kVVJJPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5UaGUg ImlzcyIgKGlzc3VlcikgY2xhaW0gaWRlbnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQKCSAgaXNz dWVkIHRoZSBKV1QuICBUaGUgcHJvY2Vzc2luZyBvZiB0aGlzIGNsYWltIGlzIGdlbmVyYWxseQoJ ICBhcHBsaWNhdGlvbiBzcGVjaWZpYy4gIFRoaXMgY2xhaW0gaXMgT1BUSU9OQUwuPC90ZD4KPC90 cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPmF1ZDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+c3RyaW5n PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TdHJpbmdBbmRVUkk8L3RkPgo8dGQgYWxpZ249ImxlZnQi PlRoZSAiYXVkIiAoYXVkaWVuY2UpIGNsYWltIGlkZW50aWZpZXMgdGhlIGF1ZGllbmNlIHRoYXQK CSAgdGhlIEpXVCBpcyBpbnRlbmRlZCBmb3IuICBUaGUgcHJvY2Vzc2luZyBvZiB0aGlzIGNsYWlt CgkgIHJlcXVpcmVzIHRoYXQgaWYgYSBKV1QgY29uc3VtZXIgcmVjZWl2ZXMgYSBKV1Qgd2l0aCBh biAiYXVkIgoJICB2YWx1ZSB0aGF0IGRvZXMgbm90IGlkZW50aWZ5IGl0c2VsZiBhcyB0aGUgSldU IGF1ZGllbmNlLAoJICB0aGVuIHRoZSBKV1QgTVVTVCBiZSByZWplY3RlZC4gIFRoZSBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUKCSAgYXVkaWVuY2UgdmFsdWUgaXMgZ2VuZXJhbGx5IGFwcGxpY2F0aW9u IHNwZWNpZmljLiAgVGhpcwoJICBjbGFpbSBpcyBPUFRJT05BTC48L3RkPgo8L3RyPgo8dHI+Cjx0 ZCBhbGlnbj0ibGVmdCI+dHlwPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5zdHJpbmc8L3RkPgo8dGQg YWxpZ249ImxlZnQiPlN0cmluZ0FuZFVSSTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+VGhlICJ0eXAi ICh0eXBlKSBjbGFpbSBpcyB1c2VkIHRvIGRlY2xhcmUgYSB0eXBlIGZvciB0aGUKCSAgY29udGVu dHMgdGhpcyBKV1QuICBUaGUgdmFsdWUgTUFZIGJlIGEgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNS RkMyMDQ1Jz5NSU1FPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZyZWVkLCBOLiBh bmQgTi4gQm9yZW5zdGVpbiwgJmxkcXVvO011bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVu c2lvbnMgKE1JTUUpIFBhcnQgT25lOiBGb3JtYXQgb2YgSW50ZXJuZXQgTWVzc2FnZSBCb2RpZXMs JnJkcXVvOyBOb3ZlbWJlciZuYnNwOzE5OTYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZD MjA0NV0gdHlwZS4gIFRoaXMgY2xhaW0gaXMKCSAgT1BUSU9OQUwuPC90ZD4KPC90cj4KPC90YWJs ZT4KPGJyIGNsZWFyPSJhbGwiIC8+Cjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9u dCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO1RhYmxlIDE6 IFJlc2VydmVkIENsYWltIERlZmluaXRpb25zJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwv dHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPkFkZGl0aW9uYWwgcmVzZXJ2ZWQg Y2xhaW0gbmFtZXMgTUFZIGJlIGRlZmluZWQgdmlhIHRoZSBJQU5BCglKU09OIFdlYiBUb2tlbiBD bGFpbXMgcmVnaXN0cnksIGFzIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0lBTkEnPlNlY3Rp b24mbmJzcDs5PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPklBTkEgQ29uc2lkZXJh dGlvbnM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiAgVGhlIHN5bnRheGVzIHJlZmVycmVkIHRv IGFib3ZlCglhcmU6CjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0iU3lu dGF4RGVmaW5pdGlvbnMiPjwvYT4KPHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVyIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+Cjxjb2wgYWxpZ249Imxl ZnQiPjxjb2wgYWxpZ249ImxlZnQiPgo8dHI+PHRoIGFsaWduPSJsZWZ0Ij5TeW50YXggTmFtZTwv dGg+PHRoIGFsaWduPSJsZWZ0Ij5TeW50YXggRGVmaW5pdGlvbjwvdGg+PC90cj4KPHRyPgo8dGQg YWxpZ249ImxlZnQiPlN0cmluZ0FuZFVSSTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+QW55IHN0cmlu ZyB2YWx1ZSBNQVkgYmUgdXNlZCBidXQgYSB2YWx1ZSBjb250YWluaW5nIGEgIjoiCgkgIGNoYXJh Y3RlciBNVVNUIGJlIGEgVVJJIGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNS RkMzOTg2Jz5SRkMgMzk4NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CZXJuZXJz LUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRxdW87VW5pZm9ybSBS ZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRxdW87IEphbnVhcnkm bmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzM5ODZdLjwvdGQ+CjwvdHI+ Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5VUkk8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkEgVVJJIGFz IGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzOTg2Jz5SRkMgMzk4NjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBS LiwgYW5kIEwuIE1hc2ludGVyLCAmbGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChV UkkpOiBHZW5lcmljIFN5bnRheCwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4gW1JGQzM5ODZdLjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0 Ij5JbnREYXRlPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5UaGUgbnVtYmVyIG9mIHNlY29uZHMgZnJv bSAxOTcwLTAxLTAxVDA6MDowWiBhcyBtZWFzdXJlZAoJICBpbiBVVEMgdW50aWwgdGhlIGRlc2ly ZWQgZGF0ZS90aW1lLiBTZWUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMzM5Jz5SRkMgMzMz OTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5LbHluZSwgRy4sIEVkLiBhbmQgQy4g TmV3bWFuLCAmbGRxdW87RGF0ZSBhbmQgVGltZSBvbiB0aGUgSW50ZXJuZXQ6IFRpbWVzdGFtcHMs JnJkcXVvOyBKdWx5Jm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMzMzM5 XSBmb3IgZGV0YWlscyByZWdhcmRpbmcKCSAgZGF0ZS90aW1lcyBpbiBnZW5lcmFsIGFuZCBVVEMg aW4gcGFydGljdWxhci48L3RkPgo8L3RyPgo8L3RhYmxlPgo8YnIgY2xlYXI9ImFsbCIgLz4KPHRh YmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2Vu dGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBT ZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7VGFibGUgMiZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90 ZD48L3RyPjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8YSBuYW1lPSJQdWJsaWNDbGFp bU5hbWUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjIiPjwvYT48aDM+NC4yLiZuYnNw OwpQdWJsaWMgQ2xhaW0gTmFtZXM8L2gzPgoKPHA+Q2xhaW0gbmFtZXMgY2FuIGJlIGRlZmluZWQg YXQgd2lsbCBieSB0aG9zZSB1c2luZwogICAgICAgIEpXVHMuIEhvd2V2ZXIsIGluIG9yZGVyIHRv IHByZXZlbnQgY29sbGlzaW9ucywgYW55IG5ldyBjbGFpbQogICAgICAgIG5hbWUgU0hPVUxEIGVp dGhlciBiZSBkZWZpbmVkIGluIHRoZSBJQU5BCiAgICAgICAgSlNPTiBXZWIgVG9rZW4gQ2xhaW1z IHJlZ2lzdHJ5IG9yIGJlIGRlZmluZWQgYXMKICAgICAgICBhIFVSSSB0aGF0IGNvbnRhaW5zIGEg Y29sbGlzaW9uIHJlc2lzdGFudCBuYW1lc3BhY2UuIEV4YW1wbGVzCiAgICAgICAgb2YgY29sbGlz aW9uIHJlc2lzdGFudCBuYW1lc3BhY2VzIGluY2x1ZGU6CgogICAgICAgICAgPC9wPgo8dWwgY2xh c3M9InRleHQiPgo8bGk+RG9tYWluIE5hbWVzLAo8L2xpPgo8bGk+T2JqZWN0IElkZW50aWZpZXJz IChPSURzKSBhcyBkZWZpbmVkIGluIHRoZSBJVFUtVCBYIDY2MCBhbmQgWAogICAgICAgICAgICA2 NzAgUmVjb21tZW5kYXRpb24gc2VyaWVzIG9yCjwvbGk+CjxsaT5Vbml2ZXJzYWxseSBVbmlxdWUg SURlbnRpZmllciAoVVVJRCkgYXMgZGVmaW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzQxMjInPlJGQyA0MTIyPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkxlYWNoLCBQ LiwgTWVhbGxpbmcsIE0uLCBhbmQgUi4gU2FseiwgJmxkcXVvO0EgVW5pdmVyc2FsbHkgVW5pcXVl IElEZW50aWZpZXIgKFVVSUQpIFVSTiBOYW1lc3BhY2UsJnJkcXVvOyBKdWx5Jm5ic3A7MjAwNS48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM0MTIyXS4KPC9saT4KPC91bD48cD4KICAgICAg ICBJbiBlYWNoIGNhc2UsIHRoZSBkZWZpbmVyIG9mIHRoZSBuYW1lIG9yIHZhbHVlIE1VU1QgdGFr ZQogICAgICAgIHJlYXNvbmFibGUgcHJlY2F1dGlvbnMgdG8gbWFrZSBzdXJlIHRoZXkgYXJlIGlu IGNvbnRyb2wgb2YgdGhlIHBhcnQgb2YKICAgICAgICB0aGUgbmFtZXNwYWNlIHRoZXkgdXNlIHRv IGRlZmluZSB0aGUgY2xhaW0gbmFtZS4KPC9wPgo8YSBuYW1lPSJQcml2YXRlQ2xhaW1OYW1lIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4zIj48L2E+PGgzPjQuMy4mbmJzcDsKUHJpdmF0 ZSBDbGFpbSBOYW1lczwvaDM+Cgo8cD5BIHByb2R1Y2VyIGFuZCBjb25zdW1lciBvZiBhIEpXVCBt YXkgYWdyZWUgdG8gYW55IGNsYWltCiAgICAgICAgIG5hbWUgdGhhdCBpcyBub3QgYSBSZXNlcnZl ZCBOYW1lIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUmVzZXJ2ZWRDbGFpbU5hbWUnPlNlY3Rpb24m bmJzcDs0LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVzZXJ2ZWQgQ2xhaW0g TmFtZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Cgkgb3IgYSBQdWJsaWMgTmFtZSA8YSBjbGFz cz0naW5mbycgaHJlZj0nI1B1YmxpY0NsYWltTmFtZSc+U2VjdGlvbiZuYnNwOzQuMjxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5QdWJsaWMgQ2xhaW0gTmFtZXM8L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LiBVbmxpa2UKICAgICAgICAgUHVibGljIE5hbWVzLCB0aGVzZSBwcml2YXRl IG5hbWVzIGFyZSBzdWJqZWN0IHRvIGNvbGxpc2lvbiBhbmQKICAgICAgICAgc2hvdWxkIGJlIHVz ZWQgd2l0aCBjYXV0aW9uLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjYiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi41Ij48L2E+PGgzPjUuJm5ic3A7CkpXVCBFbnZlbG9wZTwvaDM+Cgo8cD5UaGUg bWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3QgcmVwcmVzZW50ZWQgYnkgdGhlIERlY29kZWQgSldU CiAgICAgIEVudmVsb3BlIFNlZ21lbnQgZGVzY3JpYmUgdGhlIHNpZ25hdHVyZSBhcHBsaWVkIHRv IHRoZSBKV1QgQ2xhaW0KICAgICAgU2VnbWVudCBhbmQgb3B0aW9uYWxseSBhZGRpdGlvbmFsIHBy b3BlcnRpZXMgb2YgdGhlIEpXVC4KICAgICAgSW1wbGVtZW50YXRpb25zIE1VU1QgdW5kZXJzdGFu ZCB0aGUgZW50aXJlIGNvbnRlbnRzIG9mIHRoZQogICAgICBlbnZlbG9wZTsgb3RoZXJ3aXNlLCB0 aGUgSldUIE1VU1QgYmUgcmVqZWN0ZWQgZm9yCiAgICAgIHByb2Nlc3NpbmcuCjwvcD4KPGEgbmFt ZT0iUmVzZXJ2ZWRFbnZlbG9wZVBhcmFtZXRlck5hbWUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi41LjEiPjwvYT48aDM+NS4xLiZuYnNwOwpSZXNlcnZlZCBFbnZlbG9wZSBQYXJhbWV0ZXIg TmFtZXM8L2gzPgoKPHA+VGhlIGZvbGxvd2luZyBlbnZlbG9wZSBwYXJhbWV0ZXIgbmFtZXMgYXJl IHJlc2VydmVkLiAgQWxsCgl0aGUgbmFtZXMgYXJlIHNob3J0IGJlY2F1c2UgYSBjb3JlIGdvYWwg b2YgSldUcyBpcyBmb3IgdGhlCgl0b2tlbnMgdGhlbXNlbHZlcyB0byBiZSBzaG9ydC4KPC9wPjxi ciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJFbnZlbG9wZVBhcmFtZXRlclRhYmxl Ij48L2E+Cjx0YWJsZSBjbGFzcz0iZnVsbCIgYWxpZ249ImNlbnRlciIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjIiPgo8Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWdu PSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij4KPHRyPjx0aCBhbGln bj0ibGVmdCI+RW52ZWxvcGUgUGFyYW1ldGVyIE5hbWU8L3RoPjx0aCBhbGlnbj0ibGVmdCI+SlNP TiBWYWx1ZSBUeXBlPC90aD48dGggYWxpZ249ImxlZnQiPkVudmVsb3BlIFBhcmFtZXRlciBTeW50 YXg8L3RoPjx0aCBhbGlnbj0ibGVmdCI+RW52ZWxvcGUgUGFyYW1ldGVyIFNlbWFudGljczwvdGg+ PC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPmFsZzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+c3Ry aW5nPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TdHJpbmdBbmRVUkk8L3RkPgo8dGQgYWxpZ249Imxl ZnQiPlRoZSAiYWxnIiAoYWxnb3JpdGhtKSBlbnZlbG9wZSBwYXJhbWV0ZXIgaWRlbnRpZmllcyB0 aGUKCSAgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gdXNlZCB0byBzZWN1cmUgdGhlIEpXVC4gIEEg bGlzdCBvZgoJICByZXNlcnZlZCBhbGcgdmFsdWVzIGlzIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjQWxnVGFibGUnPlRhYmxlJm5ic3A7NDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5KU09OIFdlYiBUb2tlbiBSZXNlcnZlZCBBbGdvcml0aG0gVmFsdWVzPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KCSAgVGhlIHByb2Nlc3Npbmcgb2YgdGhlICJhbGciIChhbGdvcml0aG0pIGVu dmVsb3BlIHBhcmFtZXRlciwKCSAgaWYgcHJlc2VudCwgcmVxdWlyZXMgdGhhdCB0aGUgdmFsdWUg b2YgdGhlICJhbGciIGVudmVsb3BlCgkgIHBhcmFtZXRlciBNVVNUIGJlIG9uZSB0aGF0IGlzIGJv dGggc3VwcG9ydGVkIGFuZCBmb3Igd2hpY2gKCSAgdGhlcmUgZXhpc3RzIGEga2V5IGZvciB1c2Ug d2l0aCB0aGF0IGFsZ29yaXRobSBhc3NvY2lhdGVkCgkgIHdpdGggdGhlIGlzc3VlciBvZiB0aGUg SldULiAgTm90ZSBob3dldmVyLCB0aGF0IGlmIHRoZSAiaXNzIgoJICAoaXNzdWVyKSBjbGFpbSBp cyBub3QgaW5jbHVkZWQgaW4gdGhlIEpXVCBDbGFpbSBTZWdtZW50LAoJICB0aGVuIHRoZSBtYW5u ZXIgaW4gd2hpY2ggdGhlIGlzc3VlciBpcyBkZXRlcm1pbmVkIGlzCgkgIGFwcGxpY2F0aW9uIHNw ZWNpZmljLiBUaGlzIGVudmVsb3BlIHBhcmFtZXRlciBpcwoJICBSRVFVSVJFRC48L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+dHlwPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5zdHJpbmc8 L3RkPgo8dGQgYWxpZ249ImxlZnQiPlN0cmluZ0FuZFVSSTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ VGhlICJ0eXAiICh0eXBlKSBlbnZlbG9wZSBwYXJhbWV0ZXIgaXMgdXNlZCB0byBkZWNsYXJlCgkg IHRoYXQgdGhpcyBkYXRhIHN0cnVjdHVyZSBpcyBhIEpXVC4gIElmIGEgInR5cCIgcGFyYW1ldGVy IGlzCgkgIHByZXNlbnQsIGl0cyB2YWx1ZSBNVVNUIGJlICJKV1QiLiAgVGhpcyBlbnZlbG9wZSBw YXJhbWV0ZXIKCSAgaXMgT1BUSU9OQUwuICAoTm9uLW5vcm1hdGl2ZSBub3RlOiBPdGhlciB2YWx1 ZXMgY291bGQgYmUKCSAgdXNlZCBieSBvdGhlciBzcGVjaWZpY2F0aW9ucyB0byBkZWNsYXJlIGRh dGEgc3RydWN0dXJlcwoJICBvdGhlciB0aGFuIEpXVHMsIGZvciBpbnN0YW5jZSwgZW5jcnlwdGVk IEpTT04gdG9rZW5zLik8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+a2V5aWQ8L3Rk Pgo8dGQgYWxpZ249ImxlZnQiPnN0cmluZzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+U3RyaW5nPC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5UaGUgImtleWlkIiAoa2V5IElEKSBlbnZlbG9wZSBwYXJhbWV0 ZXIgaXMgYSBoaW50CgkgIGluZGljYXRpbmcgd2hpY2ggc3BlY2lmaWMga2V5IG93bmVkIGJ5IHRo ZSBzaWduZXIgc2hvdWxkIGJlCgkgIHVzZWQgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZS4gIFRo aXMgYWxsb3dzIHNpZ25lcnMgdG8KCSAgZXhwbGljaXRseSBzaWduYWwgYSBjaGFuZ2Ugb2Yga2V5 IHRvIHJlY2lwaWVudHMuIE9taXR0aW5nCgkgIHRoaXMgcGFyYW1ldGVyIGlzIGVxdWl2YWxlbnQg dG8gc2V0dGluZyBpdCB0byBhbiBlbXB0eQoJICBzdHJpbmcuIFRoZSBmb3JtYXQgb2YgdGhpcyBw YXJhbWV0ZXIgaXMgdW5zcGVjaWZpZWQuICBUaGlzCgkgIGVudmVsb3BlIHBhcmFtZXRlciBpcyBP UFRJT05BTC48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+Y3VyaTwvdGQ+Cjx0ZCBh bGlnbj0ibGVmdCI+c3RyaW5nPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5VUkk8L3RkPgo8dGQgYWxp Z249ImxlZnQiPlRoZSAiY3VyaSIgKGNlcnRpZmljYXRlcyBVUkkpIGVudmVsb3BlIHBhcmFtZXRl ciBpcyBhIFVSSQoJICB0aGF0IHBvaW50cyB0byBYLjUwOSBwdWJsaWMga2V5IGNlcnRpZmljYXRl cyB0aGF0IGNhbiBiZQoJICB1c2VkIHRvIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUuICBUaGlzIGVu dmVsb3BlIHBhcmFtZXRlciBpcwoJICBPUFRJT05BTC48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGln bj0ibGVmdCI+Y3RwPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5zdHJpbmc8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPlN0cmluZzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+VGhlICJjdHAiIChjZXJ0aWZpY2F0 ZSB0aHVtYnByaW50KSBlbnZlbG9wZSBwYXJhbWV0ZXIKCSAgcHJvdmlkZXMgYSBiYXNlNjR1cmwg ZW5jb2RlZCBTSEEtMSB0aHVtYnByaW50IG9mIHRoZSBERVIKCSAgZW5jb2Rpbmcgb2YgYSBjZXJ0 aWZpY2F0ZSB0aGF0IGNhbiBiZSB1c2VkIHRvIHZhbGlkYXRlIHRoZQoJICBzaWduYXR1cmUuICBU aGlzIGVudmVsb3BlIHBhcmFtZXRlciBpcyBPUFRJT05BTC48L3RkPgo8L3RyPgo8L3RhYmxlPgo8 YnIgY2xlYXI9ImFsbCIgLz4KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZh Y2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7VGFibGUgMzogUmVz ZXJ2ZWQgRW52ZWxvcGUgUGFyYW1ldGVyIERlZmluaXRpb25zJm5ic3A7PC9iPjwvZm9udD48YnIg Lz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPkFkZGl0aW9uYWwg cmVzZXJ2ZWQgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWVzIE1BWSBiZSBkZWZpbmVkCgl2aWEgdGhl IElBTkEgSlNPTiBXZWIgVG9rZW4gRW52ZWxvcGUgUGFyYW1ldGVycyByZWdpc3RyeSwgYXMKCXBl ciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0lBTkEnPlNlY3Rpb24mbmJzcDs5PHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPklBTkEgQ29uc2lkZXJhdGlvbnM8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LiAgVGhlIGVudmVsb3BlIHZhbHVlIHN5bnRheGVzCglyZWZlcnJlZCB0byBhYm92 ZSBhcmUgZGVmaW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1N5bnRheERlZmluaXRpb25z Jz5UYWJsZSZuYnNwOzI8L2E+Lgo8L3A+CjxhIG5hbWU9IlB1YmxpY0VudmVsb3BlUGFyYW1ldGVy TmFtZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMiI+PC9hPjxoMz41LjIuJm5ic3A7 ClB1YmxpYyBFbnZlbG9wZSBQYXJhbWV0ZXIgTmFtZXM8L2gzPgoKPHA+QWRkaXRpb25hbCBlbnZl bG9wZSBwYXJhbWV0ZXIgbmFtZXMgY2FuIGJlIGRlZmluZWQgYnkgdGhvc2UgdXNpbmcKICAgICAg ICBKV1RzLiBIb3dldmVyLCBpbiBvcmRlciB0byBwcmV2ZW50IGNvbGxpc2lvbnMsIGFueSBuZXcg ZW52ZWxvcGUgcGFyYW1ldGVyCiAgICAgICAgbmFtZSBvciBhbGdvcml0aG0gdmFsdWUgU0hPVUxE IGVpdGhlciBiZSBkZWZpbmVkIGluIHRoZSBJQU5BCiAgICAgICAgSlNPTiBXZWIgVG9rZW4gRW52 ZWxvcGUgUGFyYW1ldGVycyByZWdpc3RyeSBvciBiZSBkZWZpbmVkIGFzCiAgICAgICAgYSBVUkkg dGhhdCBjb250YWlucyBhIGNvbGxpc2lvbiByZXNpc3RhbnQgbmFtZXNwYWNlLgogICAgICAgIElu IGVhY2ggY2FzZSwgdGhlIGRlZmluZXIgb2YgdGhlIG5hbWUgb3IgdmFsdWUgTVVTVCB0YWtlCiAg ICAgICAgcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0byBtYWtlIHN1cmUgdGhleSBhcmUgaW4gY29u dHJvbCBvZiB0aGUgcGFydCBvZgogICAgICAgIHRoZSBuYW1lc3BhY2UgdGhleSB1c2UgdG8gZGVm aW5lIHRoZSBlbnZlbG9wZSBwYXJhbWV0ZXIgbmFtZS4KPC9wPgo8cD5OZXcgZW52ZWxvcGUgcGFy YW1ldGVycyBzaG91bGQgYmUgaW50cm9kdWNlZCBzcGFyaW5nbHksIGFzCgl0aGV5IGNhbiByZXN1 bHQgaW4gbm9uLWludGVyb3BlcmFibGUgSldUcy4gIE5vbmV0aGVsZXNzLCBzb21lCglleHRlbnNp b25zIG5lZWRlZCBmb3Igc29tZSB1c2UgY2FzZXMgbWF5IHJlcXVpcmUgdGhlbSwgc3VjaCBhcwoJ YW4gZXh0ZW5zaW9uIHRvIGVuYWJsZSB0aGUgaW5jbHVzaW9uIG9mIG11bHRpcGxlCglzaWduYXR1 cmVzLgo8L3A+CjxhIG5hbWU9IlByaXZhdGVFbnZlbG9wZVBhcmFtZXRlck5hbWUiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi41LjMiPjwvYT48aDM+NS4zLiZuYnNwOwpQcml2YXRlIEVudmVs b3BlIFBhcmFtZXRlciBOYW1lczwvaDM+Cgo8cD5BIHByb2R1Y2VyIGFuZCBjb25zdW1lciBvZiBh IEpXVCBtYXkgYWdyZWUgdG8gYW55IGVudmVsb3BlIHBhcmFtZXRlcgogICAgICAgICBuYW1lIHRo YXQgaXMgbm90IGEgUmVzZXJ2ZWQgTmFtZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1Jlc2VydmVk RW52ZWxvcGVQYXJhbWV0ZXJOYW1lJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPlJlc2VydmVkIEVudmVsb3BlIFBhcmFtZXRlciBOYW1lczwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4KCSBvciBhIFB1YmxpYyBOYW1lIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjUHVibGljRW52ZWxvcGVQYXJhbWV0ZXJOYW1lJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlB1YmxpYyBFbnZlbG9wZSBQYXJhbWV0ZXIgTmFtZXM8 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBVbmxpa2UKICAgICAgICAgUHVibGljIE5hbWVzLCB0 aGVzZSBwcml2YXRlIG5hbWVzIGFyZSBzdWJqZWN0IHRvIGNvbGxpc2lvbiBhbmQKICAgICAgICAg c2hvdWxkIGJlIHVzZWQgd2l0aCBjYXV0aW9uLgo8L3A+CjxwPk5ldyBlbnZlbG9wZSBwYXJhbWV0 ZXJzIHNob3VsZCBiZSBpbnRyb2R1Y2VkIHNwYXJpbmdseSwgYXMKCXRoZXkgY2FuIHJlc3VsdCBp biBub24taW50ZXJvcGVyYWJsZSBKV1RzLgo8L3A+CjxhIG5hbWU9ImFuY2hvcjciPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi42Ij48L2E+PGgzPjYuJm5ic3A7CkdlbmVyYWwgUnVsZXMgZm9y IENyZWF0aW5nIGFuZCBWYWxpZGF0aW5nIGEgSldUPC9oMz4KCjxwPlRvIGNyZWF0ZSBhIEpXVCBv bmUgTVVTVCBmb2xsb3cgdGhlc2Ugc3RlcHM6CiAgICAgICAgPC9wPgo8b2wgY2xhc3M9InRleHQi Pgo8bGk+Q3JlYXRlIGEgSlNPTiBvYmplY3QgY29udGFpbmluZyB0aGUgZGVzaXJlZCBjbGFpbXMu ICBOb3RlCiAgICAgICAgICB0aGF0IHdoaXRlIHNwYWNlIGlzIGV4cGxpY2l0bHkgYWxsb3dlZCBp biB0aGUgcmVwcmVzZW50YXRpb24KICAgICAgICAgIGFuZCBubyBjYW5vbmljYWxpemF0aW9uIGlz IHBlcmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuCjwvbGk+CjxsaT5UcmFuc2xhdGUgdGhpcyBKU09O IG9iamVjdCdzIFVuaWNvZGUgY29kZSBwb2ludHMgaW50bwogICAgICAgICAgVVRGLTgsIGFzIGRl ZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzNjI5Jz5SRkMKICAgICAgICAgIDM2 Mjk8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+WWVyZ2VhdSwgRi4sICZsZHF1bztV VEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQgb2YgSVNPIDEwNjQ2LCZyZHF1bzsgTm92ZW1i ZXImbmJzcDsyMDAzLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzM2MjldLgo8L2xpPgo8 bGk+QmFzZTY0dXJsIGVuY29kZSB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24gb2YgdGhpcwogICAg ICAgICAgSlNPTiBvYmplY3QgYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24gKHdpdGhv dXQKICAgICAgICAgIHBhZGRpbmcpLiBUaGlzIGVuY29kaW5nIGJlY29tZXMgdGhlIEpXVCBDbGFp bSBTZWdtZW50Lgo8L2xpPgo8bGk+Q3JlYXRlIGEgZGlmZmVyZW50IEpTT04gb2JqZWN0IGNvbnRh aW5pbmcgdGhlIGRlc2lyZWQKCSAgZW52ZWxvcGUgcGFyYW1ldGVycy4gIE5vdGUgdGhhdCB3aGl0 ZSBzcGFjZSBpcyBleHBsaWNpdGx5CgkgIGFsbG93ZWQgaW4gdGhlIHJlcHJlc2VudGF0aW9uIGFu ZCBubyBjYW5vbmljYWxpemF0aW9uIGlzCgkgIHBlcmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuCjwv bGk+CjxsaT5UcmFuc2xhdGUgdGhpcyBKU09OIG9iamVjdCdzIFVuaWNvZGUgY29kZSBwb2ludHMg aW50bwogICAgICAgICAgVVRGLTgsIGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkMzNjI5Jz5SRkMKICAgICAgICAgIDM2Mjk8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+WWVyZ2VhdSwgRi4sICZsZHF1bztVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQg b2YgSVNPIDEwNjQ2LCZyZHF1bzsgTm92ZW1iZXImbmJzcDsyMDAzLjwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4gW1JGQzM2MjldLgo8L2xpPgo8bGk+QmFzZTY0dXJsIGVuY29kZSB0aGUgVVRGLTgg cmVwcmVzZW50YXRpb24gb2YgdGhpcyBKU09OCiAgICAgICAgICBvYmplY3QgYXMgZGVmaW5lZCBp biB0aGlzIHNwZWNpZmljYXRpb24gKHdpdGhvdXQKICAgICAgICAgIHBhZGRpbmcpLiBUaGlzIGVu Y29kaW5nIGJlY29tZXMgdGhlIEpXVCBFbnZlbG9wZQogICAgICAgICAgU2VnbWVudC4KPC9saT4K PGxpPkNvbnN0cnVjdCB0aGUgSldUIENyeXB0byBTZWdtZW50IGFzIGRlZmluZWQgZm9yIHRoZQog ICAgICAgICAgcGFydGljdWxhciBhbGdvcml0aG0gYmVpbmcgdXNlZC4gIFRoZSAiYWxnIiBlbnZl bG9wZQogICAgICAgICAgcGFyYW1ldGVyIE1VU1QgYmUgcHJlc2VudCBpbiB0aGUgSlNPTiBFbnZl bG9wZSBTZWdtZW50LCB3aXRoCiAgICAgICAgICB0aGUgYWxnb3JpdGhtIHZhbHVlIGFjY3VyYXRl bHkgcmVwcmVzZW50aW5nIHRoZSBhbGdvcml0aG0KICAgICAgICAgIHVzZWQgdG8gY29uc3RydWN0 IHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQuCjwvbGk+CjxsaT5Db21iaW5lIHRoZSBKV1QgRW52ZWxv cGUgU2VnbWVudCwgdGhlIEpXVCBDbGFpbSBTZWdtZW50CiAgICAgICAgICBhbmQgdGhlbiB0aGUg SldUIENyeXB0byBTZWdtZW50IGluIHRoYXQgb3JkZXIsIHNlcGFyYXRpbmcKICAgICAgICAgIGVh Y2ggYnkgcGVyaW9kIGNoYXJhY3RlcnMsIHRvIGNyZWF0ZSB0aGUgSldULgo8L2xpPgo8L29sPgoK PHA+V2hlbiB2YWxpZGF0aW5nIGEgSldUIHRoZSBmb2xsb3dpbmcgc3RlcHMgTVVTVCBiZSB0YWtl bi4gSWYKICAgICAgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgdG9rZW4g TVVTVCBiZSByZWplY3RlZAogICAgICBmb3IgcHJvY2Vzc2luZy4KPC9wPgo8cD48L3A+CjxvbCBj bGFzcz0idGV4dCI+CjxsaT5UaGUgSldUIE1VU1QgY29udGFpbiB0d28gcGVyaW9kIGNoYXJhY3Rl cnMuCjwvbGk+CjxsaT5UaGUgSldUIE1VU1QgYmUgc3BsaXQgb24gdGhlIHR3byBwZXJpb2QgY2hh cmFjdGVycwogICAgICAgICAgcmVzdWx0aW5nIGluIHRocmVlIG5vbi1lbXB0eSBzZWdtZW50cy4g IFRoZSBmaXJzdCBzZWdtZW50IGlzCiAgICAgICAgICB0aGUgSldUIEVudmVsb3BlIFNlZ21lbnQ7 IHRoZSBzZWNvbmQgaXMgdGhlIEpXVCBDbGFpbQogICAgICAgICAgU2VnbWVudDsgdGhlIHRoaXJk IGlzIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQuCjwvbGk+CjxsaT5UaGUgSldUIEVudmVsb3BlIFNl Z21lbnQgTVVTVCBiZSBzdWNjZXNzZnVsbHkgYmFzZTY0dXJsCiAgICAgICAgICBkZWNvZGVkIGZv bGxvd2luZyB0aGUgcmVzdHJpY3Rpb24gZ2l2ZW4gaW4gdGhpcyBzcGVjIHRoYXQgbm8KICAgICAg ICAgIHBhZGRpbmcgY2hhcmFjdGVycyBtYXkgaGF2ZSBiZWVuIHVzZWQuCjwvbGk+CjxsaT5UaGUg RGVjb2RlZCBKV1QgRW52ZWxvcGUgU2VnbWVudCBNVVNUIGJlIGNvbXBsZXRlbHkgdmFsaWQKICAg ICAgICAgIEpTT04gc3ludGF4Lgo8L2xpPgo8bGk+VGhlIEpXVCBDbGFpbSBTZWdtZW50IE1VU1Qg YmUgc3VjY2Vzc2Z1bGx5IGJhc2U2NHVybAogICAgICAgICAgZGVjb2RlZCBmb2xsb3dpbmcgdGhl IHJlc3RyaWN0aW9uIGdpdmVuIGluIHRoaXMgc3BlYyB0aGF0IG5vCiAgICAgICAgICBwYWRkaW5n IGNoYXJhY3RlcnMgbWF5IGhhdmUgYmVlbiB1c2VkLgo8L2xpPgo8bGk+VGhlIERlY29kZWQgSldU IENsYWltIFNlZ21lbnQgTVVTVCBiZSBjb21wbGV0ZWx5IHZhbGlkCiAgICAgICAgICBKU09OIHN5 bnRheC4KPC9saT4KPGxpPlRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQgTVVTVCBiZSBzdWNjZXNzZnVs bHkgYmFzZTY0dXJsCiAgICAgICAgICBkZWNvZGVkIGZvbGxvd2luZyB0aGUgcmVzdHJpY3Rpb24g Z2l2ZW4gaW4gdGhpcyBzcGVjIHRoYXQgbm8KICAgICAgICAgIHBhZGRpbmcgY2hhcmFjdGVycyBt YXkgaGF2ZSBiZWVuIHVzZWQuCjwvbGk+CjxsaT5UaGUgSldUIEVudmVsb3BlIFNlZ21lbnQgTVVT VCBiZSB2YWxpZGF0ZWQgdG8gb25seQogICAgICAgICAgaW5jbHVkZSBwYXJhbWV0ZXJzIGFuZCB2 YWx1ZXMgd2hvc2Ugc3ludGF4IGFuZCBzZW1hbnRpY3MgYXJlCiAgICAgICAgICBib3RoIHVuZGVy c3Rvb2QgYW5kIHN1cHBvcnRlZC4KPC9saT4KPGxpPldoZW4gdXNlZCBpbiBhIHNlY3VyaXR5LXJl bGF0ZWQgY29udGV4dCwgdGhlIEpXVCBDbGFpbQogICAgICAgICAgU2VnbWVudCBNVVNUIGJlIHZh bGlkYXRlZCB0byBvbmx5IGluY2x1ZGUgY2xhaW1zIHdob3NlCiAgICAgICAgICBzeW50YXggYW5k IHNlbWFudGljcyBhcmUgYm90aCB1bmRlcnN0b29kIGFuZCBzdXBwb3J0ZWQuCjwvbGk+CjxsaT5U aGUgSldUIENyeXB0byBTZWdtZW50IE1VU1QgYmUgc3VjY2Vzc2Z1bGx5IHZhbGlkYXRlZAogICAg ICAgICAgYWdhaW5zdCB0aGUgSldUIENsYWltIFNlZ21lbnQgaW4gdGhlIG1hbm5lciBkZWZpbmVk IGZvciB0aGUKICAgICAgICAgIGFsZ29yaXRobSBiZWluZyB1c2VkLCB3aGljaCBNVVNUIGJlIGFj Y3VyYXRlbHkgcmVwcmVzZW50ZWQKICAgICAgICAgIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgImFsZyIg ZW52ZWxvcGUgcGFyYW1ldGVyLCB3aGljaCBNVVNUIGJlCiAgICAgICAgICBwcmVzZW50Lgo8L2xp Pgo8L29sPgoKPHA+UHJvY2Vzc2luZyBhIEpXVCBpbmV2aXRhYmx5IHJlcXVpcmVzIGNvbXBhcmlu ZyBrbm93biBzdHJpbmdzCiAgICAgIHRvIHZhbHVlcyBpbiB0aGUgdG9rZW4uIEZvciBleGFtcGxl LCBpbiBjaGVja2luZyB3aGF0IHRoZQogICAgICBhbGdvcml0aG0gaXMsIHRoZSBVbmljb2RlIHN0 cmluZyBlbmNvZGluZyAiYWxnIiB3aWxsIGJlIGNoZWNrZWQKICAgICAgYWdhaW5zdCB0aGUgbWVt YmVyIG5hbWVzIGluIHRoZSBEZWNvZGVkIEpXVCBFbnZlbG9wZSBTZWdtZW50IHRvCiAgICAgIHNl ZSBpZiB0aGVyZSBpcyBhIG1hdGNoaW5nIGVudmVsb3BlIHBhcmFtZXRlciBuYW1lLiBBIHNpbWls YXIKICAgICAgcHJvY2VzcyBvY2N1cnMgd2hlbiBkZXRlcm1pbmluZyBpZiB0aGUgdmFsdWUgb2Yg dGhlICJhbGciCiAgICAgIGVudmVsb3BlIHBhcmFtZXRlciByZXByZXNlbnRzIGEgc3VwcG9ydGVk IGFsZ29yaXRobS4gQ29tcGFyaW5nCiAgICAgIFVuaWNvZGUgc3RyaW5ncywgaG93ZXZlciwgaGFz IHNpZ25pZmljYW50IHNlY3VyaXR5IGltcGxpY2F0aW9ucywKICAgICAgYXMgcGVyIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjU2VjdXJpdHknPlNlY3Rpb24mbmJzcDsxMDxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5TZWN1cml0eSBDb25zaWRlcmF0aW9uczwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uCjwvcD4KPHA+Q29tcGFyaXNvbnMgYmV0d2VlbiBKU09OIHN0cmluZ3MgYW5kIG90 aGVyIFVuaWNvZGUgc3RyaW5ncwogICAgICBNVVNUIGJlIHBlcmZvcm1lZCBhcyBzcGVjaWZpZWQg YmVsb3c6CjwvcD4KPHA+PC9wPgo8b2wgY2xhc3M9InRleHQiPgo8bGk+UmVtb3ZlIGFueSBKU09O IGFwcGxpZWQgZXNjYXBpbmcgdG8gcHJvZHVjZSBhbiBhcnJheSBvZgogICAgICAgICAgVW5pY29k ZSBjb2RlIHBvaW50cy4KPC9saT4KPGxpPjxhIGNsYXNzPSdpbmZvJyBocmVmPScjVVNBMTUnPlVu aWNvZGUgTm9ybWFsaXphdGlvbjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EYXZp cywgTS4sIFdoaXN0bGVyLCBLLiwgYW5kIE0uIEQmdXVtbDtyc3QsICZsZHF1bztVbmljb2RlIE5v cm1hbGl6YXRpb24gRm9ybXMsJnJkcXVvOyAwOSZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiBbVVNBMTVdIE1VU1QKICAgICAgICAgIE5PVCBiZSBhcHBsaWVkIGF0IGFueSBwb2lu dCB0byBlaXRoZXIgdGhlIEpTT04gc3RyaW5nIG9yIHRvCiAgICAgICAgICB0aGUgc3RyaW5nIGl0 IGlzIHRvIGJlIGNvbXBhcmVkIGFnYWluc3QuCjwvbGk+CjxsaT5Db21wYXJpc29ucyBiZXR3ZWVu IHRoZSB0d28gc3RyaW5ncyBNVVNUIGJlIHBlcmZvcm1lZCBhcwogICAgICAgICAgYSBVbmljb2Rl IGNvZGUgcG9pbnQgdG8gY29kZSBwb2ludCBlcXVhbGl0eSBjb21wYXJpc29uLgo8L2xpPgo8L29s PgoKPGEgbmFtZT0iYmFzZTY0dXJsbG9naWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43 Ij48L2E+PGgzPjcuJm5ic3A7CkJhc2U2NHVybCBlbmNvZGluZyBhcyB1c2VkIGJ5IEpXVHM8L2gz PgoKPHA+SldUcyBtYWtlIHVzZSBvZiB0aGUgYmFzZTY0dXJsIGVuY29kaW5nIGFzIGRlZmluZWQg aW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjQ4Jz5SRkMgNDY0ODxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5Kb3NlZnNzb24sIFMuLCAmbGRxdW87VGhlIEJhc2UxNiwgQmFz ZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2RpbmdzLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIwMDYu PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNDY0OF0uIEFzIGFsbG93ZWQgYnkgU2VjdGlv biAzLjIgb2YgdGhlCiAgICAgIFJGQywgdGhpcyBzcGVjaWZpY2F0aW9uIG1hbmRhdGVzIHRoYXQg YmFzZTY0dXJsIGVuY29kaW5nCiAgICAgIHdoZW4gdXNlZCB3aXRoIEpXVHMgTVVTVCBOT1QgdXNl IHBhZGRpbmcuIFRoZSByZWFzb24gZm9yIHRoaXMKICAgICAgcmVzdHJpY3Rpb24gaXMgdGhhdCB0 aGUgcGFkZGluZyBjaGFyYWN0ZXIgKCc9JykgaXMgbm90IFVSTAogICAgICBzYWZlLgo8L3A+Cjxw PkZvciBub3RlcyBvbiBpbXBsZW1lbnRpbmcgYmFzZTY0dXJsIGVuY29kaW5nIHdpdGhvdXQgcGFk ZGluZywKICAgICAgc2VlIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjYmFzZTY0dXJsbm90ZXMnPlNl Y3Rpb24mbmJzcDsxNDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BcHBlbmRpeCAt IE5vbi1Ob3JtYXRpdmUgLSBOb3RlcyBvbiBpbXBsZW1lbnRpbmcgYmFzZTY0dXJsIGVuY29kaW5n IHdpdGhvdXQgcGFkZGluZzwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCjwvcD4KPGEgbmFtZT0i U2lnbmluZyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjgiPjwvYT48aDM+OC4mbmJzcDsK U2lnbmluZyBKV1RzIHdpdGggQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG1zPC9oMz4KCjxwPkpXVHMg dXNlIHNwZWNpZmljIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB0byBzaWduIHRoZSBjb250ZW50 cwogICAgb2YgdGhlIEpXVCBDbGFpbSBTZWdtZW50LiAgVGhlIHVzZSBvZiB0aGUgZm9sbG93aW5n IGFsZ29yaXRobXMgZm9yCiAgICBwcm9kdWNpbmcgSldUcyBpcyBkZWZpbmVkIGluIHRoaXMgc2Vj dGlvbi4gIFRoZSB0YWJsZSBiZWxvdyBpcyB0aGUKICAgIGxpc3Qgb2YgImFsZyIgZW52ZWxvcGUg cGFyYW1ldGVyIHZhbHVlcyByZXNlcnZlZCBieSB0aGlzCiAgICBzcGVjaWZpY2F0aW9uLCBlYWNo IG9mIHdoaWNoIGlzIGV4cGxhaW5lZCBpbiBtb3JlIGRldGFpbCBpbiB0aGUKICAgIGZvbGxvd2lu ZyBzZWN0aW9uczoKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJBbGdU YWJsZSI+PC9hPgo8dGFibGUgY2xhc3M9ImZ1bGwiIGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjIiIGNlbGxzcGFjaW5nPSIyIj4KPGNvbCBhbGlnbj0ibGVmdCI+PGNvbCBh bGlnbj0ibGVmdCI+Cjx0cj48dGggYWxpZ249ImxlZnQiPkFsZyBDbGFpbSBWYWx1ZTwvdGg+PHRo IGFsaWduPSJsZWZ0Ij5BbGdvcml0aG08L3RoPjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5I UzI1NjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SE1BQyB1c2luZyBTSEEtMjU2IGhhc2ggYWxnb3Jp dGhtPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPkhTMzg0PC90ZD4KPHRkIGFsaWdu PSJsZWZ0Ij5ITUFDIHVzaW5nIFNIQS0zODQgaGFzaCBhbGdvcml0aG08L3RkPgo8L3RyPgo8dHI+ Cjx0ZCBhbGlnbj0ibGVmdCI+SFM1MTI8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkhNQUMgdXNpbmcg U0hBLTUxMiBoYXNoIGFsZ29yaXRobTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5S UzI1NjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+UlNBIHVzaW5nIFNIQS0yNTYgaGFzaCBhbGdvcml0 aG08L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+UlMzODQ8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPlJTQSB1c2luZyBTSEEtMzg0IGhhc2ggYWxnb3JpdGhtPC90ZD4KPC90cj4KPHRyPgo8 dGQgYWxpZ249ImxlZnQiPlJTNTEyPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5SU0EgdXNpbmcgU0hB LTUxMiBoYXNoIGFsZ29yaXRobTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5FUzI1 NjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+RUNEU0EgdXNpbmcgUC0yNTYgY3VydmUgYW5kIFNIQS0y NTYgaGFzaCBhbGdvcml0aG08L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+RVMzODQ8 L3RkPgo8dGQgYWxpZ249ImxlZnQiPkVDRFNBIHVzaW5nIFAtMzg0IGN1cnZlIGFuZCBTSEEtMzg0 IGhhc2ggYWxnb3JpdGhtPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPkVTNTEyPC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5FQ0RTQSB1c2luZyBQLTUyMSBjdXJ2ZSBhbmQgU0hBLTUxMiBo YXNoIGFsZ29yaXRobTwvdGQ+CjwvdHI+CjwvdGFibGU+CjxiciBjbGVhcj0iYWxsIiAvPgo8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50 ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNl cmlmIiBzaXplPSIxIj48Yj4mbmJzcDtUYWJsZSA0OiBKU09OIFdlYiBUb2tlbiBSZXNlcnZlZCBB bGdvcml0aG0gVmFsdWVzJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48 aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPk9mIHRoZXNlIGFsZ29yaXRobXMsIG9ubHkgSE1BQyBT SEEtMjU2IGFuZCBSU0EgU0hBLTI1NiBNVVNUIGJlCiAgICBpbXBsZW1lbnRlZC4gIEl0IGlzIFJF Q09NTUVOREVEIHRoYXQgaW1wbGVtZW50YXRpb25zIGFsc28KICAgIGltcGxlbWVudCBhdCBsZWFz dCB0aGUgRUNEU0EgUC0yNTYgU0hBLTI1NiBhbGdvcml0aG0uCjwvcD4KPGEgbmFtZT0iU2lnbmlu Z1dpdGhITUFDU0hBMjU2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4xIj48L2E+PGgz PjguMS4mbmJzcDsKU2lnbmluZyBhIEpXVCB3aXRoIEhNQUMgU0hBLTI1NjwvaDM+Cgo8cD5IYXNo IGJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMgKEhNQUNzKSBlbmFibGUgb25lIHRv CiAgICAgIHVzZSBhIHNlY3JldCBwbHVzIGEgY3J5cHRvZ3JhcGhpYyBoYXNoIGZ1bmN0aW9uIHRv IGdlbmVyYXRlIGEKICAgICAgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChNQUMpLiBUaGlz IGNhbiBiZSB1c2VkIHRvCiAgICAgIGRlbW9uc3RyYXRlIHRoYXQgdGhlIE1BQyBtYXRjaGVzIHRo ZSBoYXNoZWQgY29udGVudCwgaW4gdGhpcwogICAgICBjYXNlIHRoZSBKV1QgQ2xhaW0gU2VnbWVu dCwgd2hpY2ggdGhlcmVmb3JlIGRlbW9uc3RyYXRlcyB0aGF0CiAgICAgIHdob2V2ZXIgZ2VuZXJh dGVkIHRoZSBNQUMgd2FzIGluIHBvc3Nlc3Npb24gb2YgdGhlCiAgICAgIHNlY3JldC4KPC9wPgo8 cD5UaGUgYWxnb3JpdGhtIGZvciBpbXBsZW1lbnRpbmcgYW5kIHZhbGlkYXRpbmcgSE1BQ3MgaXMK ICAgICAgcHJvdmlkZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMTA0Jz5SRkMgMjEw NDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5LcmF3Y3p5aywgSC4sIEJlbGxhcmUs IE0uLCBhbmQgUi4gQ2FuZXR0aSwgJmxkcXVvO0hNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3Nh Z2UgQXV0aGVudGljYXRpb24sJnJkcXVvOyBGZWJydWFyeSZuYnNwOzE5OTcuPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiBbUkZDMjEwNF0uIEFsdGhvdWdoIGFueQogICAgICBITUFDIGNhbiBiZSB1 c2VkIHdpdGggSldUcywgdGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiB0aGUKICAgICAg U0hBLTI1NiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gYXMgZGVmaW5lZCBpbiA8YSBjbGFz cz0naW5mbycgaHJlZj0nI0ZJUFMuMTgwLTMnPkZJUFMgMTgwLTM8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgICAgICAg ICAgICAgVGVjaG5vbG9neSwgJmxkcXVvO1NlY3VyZSBIYXNoIFN0YW5kYXJkIChTSFMpLCZyZHF1 bzsgT2N0b2JlciZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbRklQUy4xODAm IzgyMDk7M10uIFRoZSByZXNlcnZlZCAiYWxnIgogICAgICBlbnZlbG9wZSBwYXJhbWV0ZXIgdmFs dWUgIkhTMjU2IiBpcyB1c2VkIGluIHRoZSBKV1QgRW52ZWxvcGUKICAgICAgU2VnbWVudCB0byBp bmRpY2F0ZSB0aGF0IHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQgY29udGFpbnMgYQogICAgICBiYXNl NjR1cmwgZW5jb2RlZCBITUFDIFNIQS0yNTYgSE1BQyB2YWx1ZS4KPC9wPgo8cD5UaGUgSE1BQyBT SEEtMjU2IE1BQyBpcyBnZW5lcmF0ZWQgYXMgZm9sbG93czoKICAgICAgICA8L3A+CjxvbCBjbGFz cz0idGV4dCI+CjxsaT5UYWtlIHRoZSBieXRlcyBvZiB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24g b2YgdGhlIEpXVAogICAgICAgICAgQ2xhaW0gU2VnbWVudCBhbmQgZXhlY3V0ZSB0aGUgSE1BQyBT SEEtMjU2IGFsZ29yaXRobSBvbiB0aGVtCiAgICAgICAgICB1c2luZyB0aGUgc2hhcmVkIGtleSB0 byBwcm9kdWNlIGFuIEhNQUMuCjwvbGk+CjxsaT5CYXNlNjR1cmwgZW5jb2RlIHRoZSBITUFDIGFz IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4KPC9saT4KPC9vbD48cD4KICAgICAgVGhlIG91dHB1 dCBpcyBwbGFjZWQgaW4gdGhlIEpXVCBDcnlwdG8gU2VnbWVudCBmb3IgdGhhdCBKV1QuCjwvcD4K PHA+VGhlIEhNQUMgU0hBLTI1NiBNQUMgb24gYSBKV1QgaXMgdmFsaWRhdGVkIGFzIGZvbGxvd3M6 CiAgICAgICAgPC9wPgo8b2wgY2xhc3M9InRleHQiPgo8bGk+VGFrZSB0aGUgYnl0ZXMgb2YgdGhl IFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QKICAgICAgICAgIENsYWltIFNlZ21lbnQg YW5kIGNhbGN1bGF0ZSBhbiBITUFDIFNIQS0yNTYgTUFDIG9uIHRoZW0KICAgICAgICAgIHVzaW5n IHRoZSBzaGFyZWQga2V5Lgo8L2xpPgo8bGk+QmFzZTY0dXJsIGVuY29kZSB0aGUgcHJldmlvdXNs eSBnZW5lcmF0ZWQgSE1BQyBhcyBkZWZpbmVkIGluIHRoaXMKICAgICAgICAgIGRvY3VtZW50Lgo8 L2xpPgo8bGk+SWYgdGhlIEpXVCBDcnlwdG8gU2VnbWVudCBhbmQgdGhlIHByZXZpb3VzbHkgY2Fs Y3VsYXRlZCB2YWx1ZQogICAgICAgICAgZXhhY3RseSBtYXRjaCBpbiBhIGNoYXJhY3RlciBieSBj aGFyYWN0ZXIsIGNhc2Ugc2Vuc2l0aXZlCiAgICAgICAgICBjb21wYXJpc29uLCB0aGVuIG9uZSBo YXMgY29uZmlybWF0aW9uIHRoYXQgdGhlIGtleSB3YXMKICAgICAgICAgIHVzZWQgdG8gZ2VuZXJh dGUgdGhlIEhNQUMgb24gdGhlIEpXVCBhbmQgdGhhdCB0aGUgY29udGVudHMgb2YKICAgICAgICAg IHRoZSBKV1QgQ2xhaW0gU2VnbWVudCBoYXZlIG5vdCBiZSB0YW1wZXJlZCB3aXRoLgo8L2xpPgo8 bGk+SWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSB0b2tlbiBNVVNUIGJlIHJlamVjdGVkLgo8 L2xpPgo8L29sPgoKPHA+U2lnbmluZyB3aXRoIHRoZSBITUFDIFNIQS0zODQgYW5kIEhNQUMgU0hB LTUxMiBhbGdvcml0aG1zIGlzCiAgICAgIHBlcmZvcm1lZCBpZGVudGljYWxseSB0byB0aGUgcHJv Y2VkdXJlIGZvciBITUFDIFNIQS0yNTYgLSBqdXN0CiAgICAgIHdpdGggY29ycmVzcG9uZGluZ2x5 IGxvbmdlciBrZXkgYW5kIHJlc3VsdCB2YWx1ZXMuCjwvcD4KPHA+SldUIGltcGxlbWVudGF0aW9u cyBNVVNUIHN1cHBvcnQgdGhlIEhNQUMgU0hBLTI1NiBhbGdvcml0aG0uCiAgICAgIFN1cHBvcnQg Zm9yIHRoZSBITUFDIFNIQS0zODQgYW5kIEhNQUMgU0hBLTUxMiBhbGdvcml0aG1zIGlzCiAgICAg IE9QVElPTkFMLgo8L3A+CjxhIG5hbWU9IkRlZmluaW5nUlNBIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uOC4yIj48L2E+PGgzPjguMi4mbmJzcDsKU2lnbmluZyBhIEpXVCB3aXRoIFJTQSBT SEEtMjU2PC9oMz4KCjxwPlRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSB1c2Ugb2YgdGhlIFJTQVNT QS1QS0NTMS12MV81CiAgICAgIHNpZ25hdHVyZSBhbGdvcml0aG0gYXMgZGVmaW5lZCBpbiA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzM0NDcnPlJGQwogICAgICAzNDQ3PHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCAmbGRxdW87UHVi bGljLUtleSBDcnlwdG9ncmFwaHkgU3RhbmRhcmRzIChQS0NTKSAjMTogUlNBIENyeXB0b2dyYXBo eSBTcGVjaWZpY2F0aW9ucyBWZXJzaW9uIDIuMSwmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAwMy48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMzNDQ3XSwgU2VjdGlvbiA4LjIgKGNvbW1vbmx5 IGtub3duIGFzIFBLQ1MjMSksIHVzaW5nCiAgICAgIFNIQS0yNTYgYXMgdGhlIGhhc2ggZnVuY3Rp b24uICBOb3RlIHRoYXQgdGhlIHVzZSBvZiB0aGUKICAgICAgUlNBU1NBLVBLQ1MxLXYxXzUgYWxn b3JpdGhtIGlzIHBlcm1pdHRlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZJUFMuMTg2LTMn PkZJUFMgMTg2LTM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmF0aW9uYWwgSW5z dGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgICAgICAgICAgICAgVGVjaG5vbG9neSwgJmxkcXVvO0Rp Z2l0YWwgU2lnbmF0dXJlIFN0YW5kYXJkIChEU1MpLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDkuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbRklQUy4xODYmIzgyMDk7M10sIFNlY3Rpb24gNS41LCBh cyBpcyB0aGUKICAgICAgU0hBLTI1NiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24sIHdoaWNo IGlzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGSVBTLjE4MC0zJz5GSVBTIDE4 MC0zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5hdGlvbmFsIEluc3RpdHV0ZSBv ZiBTdGFuZGFyZHMgYW5kICAgICAgICAgICAgIFRlY2hub2xvZ3ksICZsZHF1bztTZWN1cmUgSGFz aCBTdGFuZGFyZCAoU0hTKSwmcmRxdW87IE9jdG9iZXImbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4gW0ZJUFMuMTgwJiM4MjA5OzNdLiAgVGhlIHJlc2VydmVkICJhbGciCiAgICAg IGVudmVsb3BlIHBhcmFtZXRlciB2YWx1ZSAiUlMyNTYiIGlzIHVzZWQgaW4gdGhlIEpXVCBFbnZl bG9wZQogICAgICBTZWdtZW50IHRvIGluZGljYXRlIHRoYXQgdGhlIEpXVCBDcnlwdG8gU2VnbWVu dCBjb250YWlucyBhbiBSU0EKICAgICAgU0hBLTI1NiBzaWduYXR1cmUuCjwvcD4KPHA+QSAyMDQ4 LWJpdCBvciBsb25nZXIga2V5IGxlbmd0aCBNVVNUIGJlIHVzZWQgd2l0aCB0aGlzIGFsZ29yaXRo bS4KPC9wPgo8cD5UaGUgUlNBIFNIQS0yNTYgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBhcyBmb2xs b3dzOgogICAgICAgIDwvcD4KPG9sIGNsYXNzPSJ0ZXh0Ij4KPGxpPkxldCBLIGJlIHRoZSBzaWdu ZXIncyBSU0EgcHJpdmF0ZSBrZXkgYW5kIGxldCBNIGJlIHRoZQogICAgICAgICAgYnl0ZXMgb2Yg dGhlIFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QgQ2xhaW0KICAgICAgICAgIFNlZ21l bnQuCjwvbGk+CjxsaT5Db21wdXRlIHRoZSBvY3RldCBzdHJpbmcgUyA9IFJTQVNTQS1QS0NTMS1W MV81LVNJR04gKEssIE0pLgo8L2xpPgo8bGk+QmFzZTY0dXJsIGVuY29kZSB0aGUgb2N0ZXQgc3Ry aW5nIFMsIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4KPC9saT4KPC9vbD48cD4KICAgICAg VGhlIG91dHB1dCBpcyBwbGFjZWQgaW4gdGhlIEpXVCBDcnlwdG8gU2VnbWVudCBmb3IgdGhhdCBK V1QuCjwvcD4KPHA+VGhlIFJTQSBTSEEtMjU2IHNpZ25hdHVyZSBvbiBhIEpXVCBpcyB2YWxpZGF0 ZWQgYXMgZm9sbG93czoKICAgICAgICA8L3A+CjxvbCBjbGFzcz0idGV4dCI+CjxsaT5UYWtlIHRo ZSBKV1QgQ3J5cHRvIFNlZ21lbnQgYW5kIGJhc2U2NHVybCBkZWNvZGUgaXQgaW50bwogICAgICAg ICAgYW4gb2N0ZXQgc3RyaW5nIFMuIElmIGRlY29kaW5nIGZhaWxzLCB0aGVuIHRoZSB0b2tlbiBN VVNUIGJlCiAgICAgICAgICByZWplY3RlZC4KPC9saT4KPGxpPkxldCBNIGJlIHRoZSBieXRlcyBv ZiB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24gb2YgdGhlIEpXVAogICAgICAgICAgQ2xhaW0gU2Vn bWVudCBhbmQgbGV0IChuLCBlKSBiZSB0aGUgcHVibGljIGtleSBjb3JyZXNwb25kaW5nCiAgICAg ICAgICB0byB0aGUgcHJpdmF0ZSBrZXkgdXNlZCBieSB0aGUgc2lnbmVyLgo8L2xpPgo8bGk+VmFs aWRhdGUgdGhlIHNpZ25hdHVyZSB3aXRoIFJTQVNTQS1QS0NTMS1WMV81LVZFUklGWQoJICAoKG4s IGUpLCBNLCBTKS4KPC9saT4KPGxpPklmIHRoZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgdG9rZW4g TVVTVCBiZSByZWplY3RlZC4KPC9saT4KPC9vbD48cD4KICAgICAgCjwvcD4KPHA+U2lnbmluZyB3 aXRoIHRoZSBSU0EgU0hBLTM4NCBhbmQgUlNBIFNIQS01MTIgYWxnb3JpdGhtcyBpcwogICAgICBw ZXJmb3JtZWQgaWRlbnRpY2FsbHkgdG8gdGhlIHByb2NlZHVyZSBmb3IgUlNBIFNIQS0yNTYgLSBq dXN0CiAgICAgIHdpdGggY29ycmVzcG9uZGluZ2x5IGxvbmdlciBrZXkgYW5kIHJlc3VsdCB2YWx1 ZXMuCjwvcD4KPHA+SldUIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgdGhlIFJTQSBTSEEt MjU2IGFsZ29yaXRobS4KICAgICAgU3VwcG9ydCBmb3IgdGhlIFJTQSBTSEEtMzg0IGFuZCBSU0Eg U0hBLTUxMiBhbGdvcml0aG1zIGlzCiAgICAgIE9QVElPTkFMLgo8L3A+CjxhIG5hbWU9IkRlZmlu aW5nRUNEU0EiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjMiPjwvYT48aDM+OC4zLiZu YnNwOwpTaWduaW5nIGEgSldUIHdpdGggRUNEU0EgUC0yNTYgU0hBLTI1NjwvaDM+Cgo8cD5UaGUg RWxsaXB0aWMgQ3VydmUgRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChFQ0RTQSkgaXMKICAg ICAgZGVmaW5lZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZJUFMuMTg2LTMnPkZJUFMgMTg2 LTM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmF0aW9uYWwgSW5zdGl0dXRlIG9m IFN0YW5kYXJkcyBhbmQgICAgICAgICAgICAgVGVjaG5vbG9neSwgJmxkcXVvO0RpZ2l0YWwgU2ln bmF0dXJlIFN0YW5kYXJkIChEU1MpLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDkuPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiBbRklQUy4xODYmIzgyMDk7M10uIEVDRFNBCiAgICAgIHByb3ZpZGVzIGZv ciB0aGUgdXNlIG9mIEVsbGlwdGljIEN1cnZlIGNyeXB0b2dyYXBoeSwgd2hpY2ggaXMKICAgICAg YWJsZSB0byBwcm92aWRlIGVxdWl2YWxlbnQgc2VjdXJpdHkgdG8gUlNBIGNyeXB0b2dyYXBoeSBi dXQKICAgICAgdXNpbmcgc2hvcnRlciBrZXkgbGVuZ3RocyBhbmQgd2l0aCBncmVhdGVyIHByb2Nl c3NpbmcKICAgICAgc3BlZWQuIFRoaXMgbWVhbnMgdGhhdCBFQ0RTQSBzaWduYXR1cmVzIHdpbGwg YmUgc3Vic3RhbnRpYWxseQogICAgICBzbWFsbGVyIGluIHRlcm1zIG9mIGxlbmd0aCB0aGFuIGVx dWl2YWxlbnRseSBzdHJvbmcgUlNBIERpZ2l0YWwKICAgICAgU2lnbmF0dXJlcy4KPC9wPgo8cD5U aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgdXNlIG9mIEVDRFNBIHdpdGggdGhlIFAtMjU2 CiAgICAgIGN1cnZlIGFuZCB0aGUgU0hBLTI1NiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24u IFRoZSBQLTI1NgogICAgICBjdXJ2ZSBpcyBhbHNvIGRlZmluZWQgaW4gRklQUyAxODYtMy4gVGhl IHJlc2VydmVkICJhbGciIGVudmVsb3BlCiAgICAgIHBhcmFtZXRlciB2YWx1ZSAiRVMyNTYiIGlz IHVzZWQgaW4gdGhlIEpXVCBFbnZlbG9wZSBTZWdtZW50IHRvCiAgICAgIGluZGljYXRlIHRoYXQg dGhlIEpXVCBDcnlwdG8gU2VnbWVudCBjb250YWlucyBhIEVDRFNBIFAtMjU2CiAgICAgIFNIQS0y NTYgc2lnbmF0dXJlLgo8L3A+CjxwPkEgSldUIGlzIHNpZ25lZCB3aXRoIGFuIEVDRFNBIFAtMjU2 IFNIQS0yNTYgc2lnbmF0dXJlIGFzCiAgICAgIGZvbGxvd3M6CiAgICAgICAgPC9wPgo8b2wgY2xh c3M9InRleHQiPgo8bGk+VGFrZSB0aGUgYnl0ZXMgb2YgdGhlIFVURi04IHJlcHJlc2VudGF0aW9u IG9mIHRoZSBKV1QKICAgICAgICAgIENsYWltIFNlZ21lbnQgYW5kIGdlbmVyYXRlIGEgZGlnaXRh bCBzaWduYXR1cmUgb2YgdGhlbSB1c2luZwogICAgICAgICAgRUNEU0EgUC0yNTYgU0hBLTI1NiB3 aXRoIHRoZSBkZXNpcmVkIHByaXZhdGUga2V5LiBUaGUgb3V0cHV0CiAgICAgICAgICB3aWxsIGJl IHRoZSBFQyBwb2ludCAoUiwgUyksIHdoZXJlIFIgYW5kIFMgYXJlIHVuc2lnbmVkCiAgICAgICAg ICBpbnRlZ2Vycy4KPC9saT4KPGxpPlR1cm4gUiBhbmQgUyBpbnRvIGJ5dGUgYXJyYXlzIGluIGJp ZyBlbmRpYW4gb3JkZXIuIEVhY2ggYXJyYXkKICAgICAgICAgIHdpbGwgYmUgMzIgYnl0ZXMgbG9u Zy4KPC9saT4KPGxpPkNvbmNhdGVuYXRlIHRoZSB0d28gYnl0ZSBhcnJheXMgaW4gdGhlIG9yZGVy IFIgYW5kIHRoZW4gUy4KPC9saT4KPGxpPkJhc2U2NHVybCBlbmNvZGUgdGhlIDY0IGJ5dGUgYXJy YXkgYXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uCjwvbGk+Cjwvb2w+PHA+CiAgICAg IFRoZSBvdXRwdXQgYmVjb21lcyB0aGUgSldUIENyeXB0byBTZWdtZW50IGZvciB0aGUgSldULgo8 L3A+CjxwPlRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIGlzIHVzZWQgdG8gdmFsaWRhdGUgdGhlIEVD RFNBCiAgICAgIHNpZ25hdHVyZSBvZiBhIEpXVDoKICAgICAgICA8L3A+CjxvbCBjbGFzcz0idGV4 dCI+CjxsaT5UYWtlIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQgYW5kIGJhc2U2NHVybCBkZWNvZGUg aXQgaW50bwogICAgICAgICAgYSBieXRlIGFycmF5LiBJZiBkZWNvZGluZyBmYWlscywgdGhlIHRv a2VuIE1VU1QgYmUgcmVqZWN0ZWQuCjwvbGk+CjxsaT5UaGUgb3V0cHV0IG9mIHRoZSBiYXNlNjR1 cmwgZGVjb2RpbmcgTVVTVCBiZSBhIDY0IGJ5dGUgYXJyYXkuCjwvbGk+CjxsaT5TcGxpdCB0aGUg NjQgYnl0ZSBhcnJheSBpbnRvIHR3byAzMiBieXRlIGFycmF5cy4gVGhlIGZpcnN0IGFycmF5CiAg ICAgICAgICB3aWxsIGJlIFIgYW5kIHRoZSBzZWNvbmQgUy4gUmVtZW1iZXIgdGhhdCB0aGUgYnl0 ZSBhcnJheXMgYXJlCiAgICAgICAgICBpbiBiaWcgZW5kaWFuIGJ5dGUgb3JkZXI7IHBsZWFzZSBj aGVjayB0aGUgRUNEU0EgdmFsaWRhdG9yIGluCiAgICAgICAgICB1c2UgdG8gc2VlIHdoYXQgYnl0 ZSBvcmRlciBpdCByZXF1aXJlcy4KPC9saT4KPGxpPlN1Ym1pdCB0aGUgYnl0ZXMgb2YgdGhlIFVU Ri04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QKCSAgQ2xhaW0gU2VnbWVudCwgUiwgUyBhbmQg dGhlIHB1YmxpYyBrZXkgKHgsIHkpIHRvIHRoZSBFQ0RTQQoJICBQLTI1NiBTSEEtMjU2IHZhbGlk YXRvci4KPC9saT4KPGxpPklmIHRoZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgdG9rZW4gTVVTVCBi ZSByZWplY3RlZC4KPC9saT4KPC9vbD48cD4KCiAgICAgIFRoZSBFQ0RTQSB2YWxpZGF0b3Igd2ls bCB0aGVuIGRldGVybWluZSBpZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUKICAgICAgaXMgdmFsaWQs IGdpdmVuIHRoZSBpbnB1dHMuICBOb3RlIHRoYXQgRUNEU0EgZGlnaXRhbCBzaWduYXR1cmUKICAg ICAgY29udGFpbnMgYSB2YWx1ZSByZWZlcnJlZCB0byBhcyBLLCB3aGljaCBpcyBhIHJhbmRvbSBu dW1iZXIKICAgICAgZ2VuZXJhdGVkIGZvciBlYWNoIGRpZ2l0YWwgc2lnbmF0dXJlIGluc3RhbmNl LiBUaGlzIG1lYW5zIHRoYXQKICAgICAgdHdvIEVDRFNBIGRpZ2l0YWwgc2lnbmF0dXJlcyB1c2lu ZyBleGFjdGx5IHRoZSBzYW1lIGlucHV0CiAgICAgIHBhcmFtZXRlcnMgd2lsbCBvdXRwdXQgZGlm ZmVyZW50IHNpZ25hdHVyZXMgYmVjYXVzZSB0aGVpciBLCiAgICAgIHZhbHVlcyB3aWxsIGJlIGRp ZmZlcmVudC4gVGhlIGNvbnNlcXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBvbmUKICAgICAgbXVzdCB2 YWxpZGF0ZSBhbiBFQ0RTQSBzaWduYXR1cmUgYnkgc3VibWl0dGluZyB0aGUgcHJldmlvdXNseQog ICAgICBzcGVjaWZpZWQgaW5wdXRzIHRvIGFuIEVDRFNBIHZhbGlkYXRvci4KPC9wPgo8cD5TaWdu aW5nIHdpdGggdGhlIEVDRFNBIFAtMzg0IFNIQS0zODQgYW5kIEVDRFNBIFAtNTIxIFNIQS01MTIg YWxnb3JpdGhtcyBpcwogICAgICBwZXJmb3JtZWQgaWRlbnRpY2FsbHkgdG8gdGhlIHByb2NlZHVy ZSBmb3IgRUNEU0EgUC0yNTYgU0hBLTI1NiAtIGp1c3QKICAgICAgd2l0aCBjb3JyZXNwb25kaW5n bHkgbG9uZ2VyIGtleSBhbmQgcmVzdWx0IHZhbHVlcy4KPC9wPgo8cD5JdCBpcyBSRUNPTU1FTkRF RCB0aGF0IEpXVCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGUgRUNEU0EKICAgICAgUC0yNTYg U0hBLTI1NiBhbGdvcml0aG0uICBTdXBwb3J0IGZvciB0aGUgRUNEU0EgUC0zODQgU0hBLTM4NAog ICAgICBhbmQgRUNEU0EgUC01MjEgU0hBLTUxMiBhbGdvcml0aG1zIGlzIE9QVElPTkFMLgo8L3A+ CjxhIG5hbWU9ImFuY2hvcjgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjQiPjwvYT48 aDM+OC40LiZuYnNwOwpBZGRpdGlvbmFsIEFsZ29yaXRobXM8L2gzPgoKPHA+QWRkaXRpb25hbCBh bGdvcml0aG1zIE1BWSBiZSB1c2VkIHRvIHByb3RlY3QgSldUcyB3aXRoCiAgICAgIGNvcnJlc3Bv bmRpbmcgImFsZyIgZW52ZWxvcGUgcGFyYW1ldGVyIHZhbHVlcyBiZWluZyBkZWZpbmVkIHRvCiAg ICAgIHJlZmVyIHRvIHRoZW0uIExpa2UgY2xhaW0gbmFtZXMsIG5ldyAiYWxnIiBlbnZlbG9wZSBw YXJhbWV0ZXIKICAgICAgdmFsdWVzIFNIT1VMRCBlaXRoZXIgYmUgZGVmaW5lZCBpbiB0aGUgSUFO QSBKU09OIFdlYiBUb2tlbgogICAgICBBbGdvcml0aG1zIHJlZ2lzdHJ5IG9yIGJlIGEgVVJJIHRo YXQgY29udGFpbnMgYSBjb2xsaXNpb24KICAgICAgcmVzaXN0YW50IG5hbWVzcGFjZS4gIEluIHBh cnRpY3VsYXIsIHRoZSB1c2Ugb2YgYWxnb3JpdGhtCiAgICAgIGlkZW50aWZpZXJzIGRlZmluZWQg aW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMjc1Jz5YTUwgRFNJRzxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5FYXN0bGFrZSwgRC4sIFJlYWdsZSwgSi4sIGFuZCBELiBTb2xv LCAmbGRxdW87KEV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlKSBYTUwtU2lnbmF0dXJlIFN5bnRh eCBhbmQgUHJvY2Vzc2luZywmcmRxdW87IE1hcmNoJm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+IFtSRkMzMjc1XQogICAgICBhbmQgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucyBpcyBw ZXJtaXR0ZWQuCjwvcD4KPGEgbmFtZT0iSUFOQSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjkiPjwvYT48aDM+OS4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD5UaGlzIHNw ZWNpZmljYXRpb24gY2FsbHMgZm9yOgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxp PkEgbmV3IElBTkEgcmVnaXN0cnkgZW50aXRsZWQgIkpTT04gV2ViIFRva2VuIENsYWltcyIgZm9y CiAgICAgICAgICByZXNlcnZlZCBjbGFpbSBuYW1lcyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1Jl c2VydmVkQ2xhaW1OYW1lJz5TZWN0aW9uJm5ic3A7NC4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPlJlc2VydmVkIENsYWltIE5hbWVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB1 c2VkIGluIGEgRGVjb2RlZCBKV1QKICAgICAgICAgIENsYWltIFNlZ21lbnQuIEluY2x1c2lvbiBp biB0aGUgcmVnaXN0cnkgaXMgUkZDIFJlcXVpcmVkIGluCiAgICAgICAgICB0aGUgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNSRkM1MjI2Jz5SRkMgNTIyNjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5OYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAmbGRxdW87R3VpZGVsaW5lcyBm b3IgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcywmcmRxdW87 IE1heSZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNTIyNl0gc2Vuc2Ug Zm9yCiAgICAgICAgICByZXNlcnZlZCBKV1QgY2xhaW0gbmFtZXMgdGhhdCBhcmUgaW50ZW5kZWQg dG8gYmUKICAgICAgICAgIGludGVyb3BlcmFibGUgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuICBU aGUgcmVnaXN0cnkgd2lsbAogICAgICAgICAganVzdCByZWNvcmQgdGhlIHJlc2VydmVkIGNsYWlt IG5hbWUgYW5kIGEgcG9pbnRlciB0byB0aGUgUkZDCiAgICAgICAgICB0aGF0IGRlZmluZXMgaXQu IFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGluY2x1c2lvbiBvZiB0aGUKICAgICAgICAgIGNs YWltIG5hbWVzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNDbGFpbVRhYmxlJz5U YWJsZSZuYnNwOzE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVzZXJ2ZWQgQ2xh aW0gRGVmaW5pdGlvbnM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L2xpPgo8bGk+QSBuZXcg SUFOQSByZWdpc3RyeSBlbnRpdGxlZCAiSlNPTiBXZWIgVG9rZW4gRW52ZWxvcGUKICAgICAgICAg IFBhcmFtZXRlcnMiIGZvciByZXNlcnZlZCBlbnZlbG9wZSBwYXJhbWV0ZXIgbmFtZXMgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNSZXNlcnZlZEVudmVsb3BlUGFyYW1ldGVyTmFtZSc+U2VjdGlvbiZu YnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNlcnZlZCBFbnZlbG9w ZSBQYXJhbWV0ZXIgTmFtZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IHVzZWQgaW4gYQogICAg ICAgICAgRGVjb2RlZCBKV1QgRW52ZWxvcGUgUGFyYW1ldGVyIFNlZ21lbnQuIEluY2x1c2lvbiBp biB0aGUKICAgICAgICAgIHJlZ2lzdHJ5IGlzIFJGQyBSZXF1aXJlZCBpbiB0aGUgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNSRkM1MjI2Jz5SRkMKICAgICAgICAgIDUyMjY8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgJmxkcXVvO0d1 aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJG Q3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzUy MjZdIHNlbnNlIGZvciByZXNlcnZlZCBKV1QgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWVzCiAgICAg ICAgICB0aGF0IGFyZSBpbnRlbmRlZCB0byBiZSBpbnRlcm9wZXJhYmxlIGJldHdlZW4KICAgICAg ICAgIGltcGxlbWVudGF0aW9ucy4gIFRoZSByZWdpc3RyeSB3aWxsIGp1c3QgcmVjb3JkIHRoZSBy ZXNlcnZlZAogICAgICAgICAgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWUgYW5kIGEgcG9pbnRlciB0 byB0aGUgUkZDIHRoYXQKICAgICAgICAgIGRlZmluZXMgaXQuIFRoaXMgc3BlY2lmaWNhdGlvbiBk ZWZpbmVzIGluY2x1c2lvbiBvZiB0aGUKICAgICAgICAgIGVudmVsb3BlIHBhcmFtZXRlciBuYW1l cyBkZWZpbmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRW52ZWxvcGVQYXJhbWV0ZXJUYWJs ZSc+VGFibGUmbmJzcDszPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJlc2VydmVk IEVudmVsb3BlIFBhcmFtZXRlciBEZWZpbml0aW9uczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4u CjwvbGk+CjxsaT5BIG5ldyBJQU5BIHJlZ2lzdHJ5IGVudGl0bGVkICJKU09OIFdlYiBUb2tlbiBB bGdvcml0aG1zIgogICAgICAgICAgZm9yIHJlc2VydmVkIHZhbHVlcyB1c2VkIHdpdGggdGhlICJh bGciIGVudmVsb3BlIHBhcmFtZXRlcgogICAgICAgICAgdmFsdWVzIHVzZWQgaW4gYSBkZWNvZGVk IEpXVCBFbnZlbG9wZSBTZWdtZW50LiBJbmNsdXNpb24gaW4KICAgICAgICAgIHRoZSByZWdpc3Ry eSBpcyBSRkMgUmVxdWlyZWQgaW4gdGhlIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTIyNic+ UkZDIDUyMjY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQg SC4gQWx2ZXN0cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25z aWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzUyMjZdIHNlbnNlLiBUaGUgcmVnaXN0cnkgd2lsbAogICAg ICAgICAganVzdCByZWNvcmQgdGhlICJhbGciIHZhbHVlIGFuZCBhIHBvaW50ZXIgdG8gdGhlIFJG QyB0aGF0CiAgICAgICAgICBkZWZpbmVzIGl0LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMg aW5jbHVzaW9uIG9mIHRoZQogICAgICAgICAgYWxnb3JpdGhtIHZhbHVlcyBkZWZpbmVkIGluIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjQWxnVGFibGUnPlRhYmxlJm5ic3A7NDxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5KU09OIFdlYiBUb2tlbiBSZXNlcnZlZCBBbGdvcml0aG0gVmFs dWVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KPC9saT4KPC91bD4KCjxhIG5hbWU9IlNlY3Vy aXR5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAiPjwvYT48aDM+MTAuJm5ic3A7ClNl Y3VyaXR5IENvbnNpZGVyYXRpb25zPC9oMz4KCjxwPlRCRDogTG90cyBvZiB3b3JrIHRvIGRvIGhl cmUuIFdlIG5lZWQgdG8gcmVtZW1iZXIgdG8gbG9vawogICAgICBpbnRvIGFueSBpc3N1ZXMgcmVs YXRpbmcgdG8gc2VjdXJpdHkgYW5kIEpTT04gcGFyc2luZy4gT25lCiAgICAgIHdvbmRlcnMganVz dCBob3cgc2VjdXJlIG1vc3QgSlNPTiBwYXJzaW5nIGxpYnJhcmllcyBhcmUuIFdlcmUKICAgICAg dGhleSBldmVyIGhhcmRlbmVkIGZvciBzZWN1cml0eSBzY2VuYXJpb3M/IElmIG5vdCwgd2hhdCBr aW5kIG9mCiAgICAgIGhvbGVzIGRvZXMgdGhhdCBvcGVuIHVwPyBBbHNvLCB3ZSBuZWVkIHRvIHdh bGsgdGhyb3VnaCB0aGUgSlNPTgogICAgICBzdGFuZGFyZCBhbmQgc2VlIHdoYXQga2luZCBvZiBp c3N1ZXMgd2UgaGF2ZSBlc3BlY2lhbGx5IGFyb3VuZAogICAgICBjb21wYXJpc29uIG9mIG5hbWVz LiAgRm9yIGluc3RhbmNlLCBjb21wYXJpc29ucyBvZiBjbGFpbSBuYW1lcwogICAgICBhbmQgb3Ro ZXIgcGFyYW1ldGVycyBtdXN0IG9jY3VyIGFmdGVyIHRoZXkgYXJlIHVuZXNjYXBlZC4gTmVlZAog ICAgICB0byBhbHNvIHB1dCBpbiB0ZXh0IGFib3V0OiBJbXBvcnRhbmNlIG9mIGtlZXBpbmcgc2Vj cmV0cwogICAgICBzZWNyZXQuIFJvdGF0aW5nIGtleXMuIFN0cmVuZ3RocyBhbmQgd2Vha25lc3Nl cyBvZiB0aGUgZGlmZmVyZW50CiAgICAgIGFsZ29yaXRobXMuIENhc2Ugc2Vuc2l0aXZpdHkgYW5k IG1vcmUgZ2VuZXJhbGx5IFVuaWNvZGUKICAgICAgY29tcGFyaXNvbiBpc3N1ZXMgdGhhdCBjYW4g Y2F1c2Ugc2VjdXJpdHkgaG9sZXMsIGVzcGVjaWFsbHkgaW4KICAgICAgY2xhaW0gbmFtZXMgYW5k IGV4cGxhaW4gd2h5IFVuaWNvZGUgTm9ybWFsaXphdGlvbiBpcyBzdWNoIGEKICAgICAgcHJvYmxl bS4KPC9wPgo8cD5UQkQ6IE5lZWQgdG8gcHV0IGluIHRleHQgYWJvdXQgd2h5IHN0cmljdCBKU09O IHZhbGlkYXRpb24gaXMgbmVjZXNzYXJ5LgogICAgICBCYXNpY2FsbHksIHRoYXQgaWYgbWFsZm9y bWVkIEpTT04gaXMgcmVjZWl2ZWQgdGhlbiB0aGUgaW50ZW50IG9mIHRoZQogICAgICBzZW5kZXIg aXMgaW1wb3NzaWJsZSB0byByZWxpYWJseSBkaXNjZXJuLiBXaGlsZSBpbiBub24tc2VjdXJpdHkK ICAgICAgY29udGV4dHMgaXQncyBvLmsuIHRvIGJlIGdlbmVyb3VzIGluIHdoYXQgb25lIGFjY2Vw dHMsIGluIHNlY3VyaXR5CiAgICAgIGNvbnRleHRzIHRoaXMgY2FuIGxlYWQgdG8gc2VyaW91cyBz ZWN1cml0eSBob2xlcy4gRm9yIGV4YW1wbGUsIG1hbGZvcm1lZAogICAgICBKU09OIG1pZ2h0IGlu ZGljYXRlIHRoYXQgc29tZW9uZSBoYXMgbWFuYWdlZCB0byBmaW5kIGEgc2VjdXJpdHkgaG9sZSBp bgogICAgICB0aGUgaXNzdWVyJ3MgY29kZSBhbmQgaXMgbGV2ZXJhZ2luZyBpdCB0byBnZXQgdGhl IGlzc3VlciB0byBpc3N1ZSAiYmFkIgogICAgICB0b2tlbnMgd2hvc2UgY29udGVudCB0aGUgYXR0 YWNrZXIgY2FuIGNvbnRyb2wuCjwvcD4KPGEgbmFtZT0iYW5jaG9yOSI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEwLjEiPjwvYT48aDM+MTAuMS4mbmJzcDsKVW5pY29kZSBDb21wYXJpc29u IFNlY3VyaXR5IElzc3VlczwvaDM+Cgo8cD5DbGFpbSBuYW1lcyBpbiBKV1RzIGFyZSBVbmljb2Rl IHN0cmluZ3MuICBGb3Igc2VjdXJpdHkKICAgICAgICByZWFzb25zLCB0aGUgcmVwcmVzZW50YXRp b25zIHRoZXNlIG5hbWVzIG11c3QgYmUgY29tcGFyZWQgdmVyYmF0aW0gYWZ0ZXIgcGVyZm9ybWlu ZwogICAgICAgIGFueSBlc2NhcGUgcHJvY2Vzc2luZyAoYXMgcGVyIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjUkZDNDYyNyc+UkZDCiAgICAgICAgNDYyNzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5Dcm9ja2ZvcmQsIEQuLCAmbGRxdW87VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEg VHlwZSBmb3IgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pLCZyZHF1bzsgSnVseSZu YnNwOzIwMDYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNDYyN10sIFNlY3Rpb24gMi41 KS4gIEluIHBhcnRpY3VsYXIsIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVVNBMTUnPlVuaWNvZGUg Tm9ybWFsaXphdGlvbjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EYXZpcywgTS4s IFdoaXN0bGVyLCBLLiwgYW5kIE0uIEQmdXVtbDtyc3QsICZsZHF1bztVbmljb2RlIE5vcm1hbGl6 YXRpb24gRm9ybXMsJnJkcXVvOyAwOSZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiBbVVNBMTVdIG9yIGNhc2UgZm9sZGluZwogICAgICAgIE1VU1QgTk9UIGJlIGFwcGxpZWQgYXQg YW55IHBvaW50IHRvIGVpdGhlciB0aGUgSlNPTiBzdHJpbmcgb3IKICAgICAgICB0byB0aGUgc3Ry aW5nIGl0IGlzIHRvIGJlIGNvbXBhcmVkIGFnYWluc3QuCjwvcD4KPHA+VGhpcyBtZWFucywgZm9y IGluc3RhbmNlLCB0aGF0IHRoZXNlIEpTT04gc3RyaW5ncyBtdXN0CiAgICAgICAgY29tcGFyZSBh cyBiZWluZyBlcXVhbCAoIkpXVCIsICJcdTAwNGFXVCIpLCB3aGVyZWFzIHRoZXNlIG11c3QKICAg ICAgICBhbGwgY29tcGFyZSBhcyBiZWluZyBub3QgZXF1YWwgdG8gdGhlIGZpcnN0IHNldCBvciB0 byBlYWNoIG90aGVyCiAgICAgICAgKCJqd3QiLCAiSnd0IiwgIkpXXHUwMDc0IikuCjwvcD4KPHA+ SlNPTiBzdHJpbmdzIE1BWSBjb250YWluIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgVW5pY29kZQog ICAgICAgIEJhc2ljIE11bHRpbGluZ3VhbCBQbGFuZS4gIEZvciBpbnN0YW5jZSwgdGhlIEcgY2xl ZiBjaGFyYWN0ZXIKICAgICAgICAoVSsxRDExRSkgbWF5IGJlIHJlcHJlc2VudGVkIGluIGEgSlNP TiBzdHJpbmcgYXMKICAgICAgICAiXHVEODM0XHVERDFFIi4gIElkZWFsbHksIEpXVCBpbXBsZW1l bnRhdGlvbnMgU0hPVUxEIGVuc3VyZQogICAgICAgIHRoYXQgY2hhcmFjdGVycyBvdXRzaWRlIHRo ZSBCYXNpYyBNdWx0aWxpbmd1YWwgUGxhbmUgYXJlCiAgICAgICAgcHJlc2VydmVkIGFuZCBjb21w YXJlZCBjb3JyZWN0bHk7IGFsdGVybmF0aXZlbHksIGlmIHRoaXMgaXMKICAgICAgICBub3QgcG9z c2libGUgZHVlIHRvIHRoZXNlIGNoYXJhY3RlcnMgZXhlcmNpc2luZyBsaW1pdGF0aW9ucwogICAg ICAgIHByZXNlbnQgaW4gdGhlIHVuZGVybHlpbmcgSlNPTiBpbXBsZW1lbnRhdGlvbiwgdGhlbiBp bnB1dAogICAgICAgIGNvbnRhaW5pbmcgdGhlbSBNVVNUIGJlIHJlamVjdGVkLgo8L3A+CjxhIG5h bWU9Ik9wZW5Jc3N1ZXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMSI+PC9hPjxoMz4x MS4mbmJzcDsKT3BlbiBJc3N1ZXM8L2gzPgoKPHA+VGhlIGZvbGxvd2luZyBvcGVuIGlzc3VlcyBo YXZlIGJlZW4gaWRlbnRpZmllZCBkdXJpbmcgcmV2aWV3CiAgICAgIG9mIHByZXZpb3VzIGRyYWZ0 cy4gIEFkZGl0aW9uYWwgaW5wdXQgb24gdGhlbSBpcyBzb2xpY2l0ZWQuCjwvcD4KPHVsIGNsYXNz PSJ0ZXh0Ij4KPGxpPlRoZSBkcmFmdCBjdXJyZW50bHkgZGVmaW5lcyBubyBtZWNoYW5pc20ocykg Zm9yIHJldHJpZXZpbmcKICAgICAgICBwdWJsaWMga2V5cyB0aGF0IGFyZSBub3QgZW5jb2RlZCBh cyBYLjUwOSBjZXJ0aWZpY2F0ZXMuICBBCiAgICAgICAgbWVjaGFuaXNtIG9yIG1lY2hhbmlzbXMg c2ltaWxhciB0byB0aGUgTWFnaWMgU2lnbmF0dXJlcyBrZXkKICAgICAgICBkaXNjb3ZlcnkgcHJv Y2VzcyBmb3IgTWFnaWMgS2V5cyBjb3VsZCBiZSBhZGRlZCB0byBmdXR1cmUKICAgICAgICBkcmFm dHMuICBTb21lIGhhdmUgc3VnZ2VzdGVkIHRoYXQgdGhleSBrZXlzIHRoZW1zZWx2ZXMgYWxzbyBi ZQogICAgICAgIGVuY29kZWQgYXMgSldUcy4KPC9saT4KPGxpPlJlbGF0ZWQgdG8gdGhlIGFib3Zl LCBpdCdzIG5vdCBjbGVhciB3aGV0aGVyIHRoZSAiaXNzIgoJY2xhaW0gc2hvdWxkIGJlIGV4cGVj dGVkIHRvIGNvbnRhaW4gYSBsb2NhdGlvbiBmb3IgcmV0cmlldmluZwoJbm9uLVguNTA5IHB1Ymxp YyBrZXlzLCBvciB3aGV0aGVyIGEgc2VwYXJhdGUgaXNzdWVyIGtleQoJbG9jYXRpb24gcGFyYW1l dGVyIHNob3VsZCBiZSBkZWZpbmVkLiAgQWxzbywgZG9lcyB0aGlzIGJlbG9uZwoJaW4gdGhlIGVu dmVsb3BlIG9yIHRoZSBjbGFpbXM/CjwvbGk+CjwvdWw+CjxhIG5hbWU9IkFja25vd2xlZGdlbWVu dHMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMiI+PC9hPjxoMz4xMi4mbmJzcDsKQWNr bm93bGVkZ2VtZW50czwvaDM+Cgo8cD5UaGUgYXV0aG9ycyBhY2tub3dsZWRnZSB0aGF0IHRoZSBk ZXNpZ24gb2YgSldUcyB3YXMKICAgICAgaW50ZW50aW9uYWxseSBpbmZsdWVuY2VkIGJ5IHRoZSBk ZXNpZ24gYW5kIHNpbXBsaWNpdHkgb2YgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNTV1QnPlNpbXBs ZSBXZWIgVG9rZW5zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0LCBELiBh bmQgWS4gR29sYW5kLCAmbGRxdW87U2ltcGxlIFdlYiBUb2tlbiAoU1dUKSwmcmRxdW87IE5vdmVt YmVyJm5ic3A7MjAwOS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtTV1RdLiAgU29sdXRpb25z IGZvciBzaWduaW5nCiAgICAgIEpTT04gdG9rZW5zIHdlcmUgYWxzbyBwcmV2aW91c2x5IGV4cGxv cmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjTWFnaWNTaWduYXR1cmVzJz5NYWdpYyBTaWdu YXR1cmVzPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlBhbnplciAoZWRpdG9yKSwg Si4sIExhdXJpZSwgQi4sIGFuZCBELiBCYWxmYW56LCAmbGRxdW87TWFnaWMgU2lnbmF0dXJlcywm cmRxdW87IEF1Z3VzdCZuYnNwOzIwMTAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbTWFnaWNT aWduYXR1cmVzXSwgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNKU1MnPkpTT04gU2ltcGxlIFNpZ248 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QnJhZGxleSwgSi4gYW5kIE4uIFNha2lt dXJhIChlZGl0b3IpLCAmbGRxdW87SlNPTiBTaW1wbGUgU2lnbiwmcmRxdW87IFNlcHRlbWJlciZu YnNwOzIwMTAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbSlNTXSwgYW5kIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjQ2FudmFzQXBwJz5DYW52YXMgQXBwbGljYXRpb25zPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkZhY2Vib29rLCAmbGRxdW87Q2FudmFzIEFwcGxpY2F0aW9ucywm cmRxdW87IDIwMTAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbQ2FudmFzQXBwXSwgYWxsIG9m IHdoaWNoIGluZmx1ZW5jZWQgdGhpcyBkcmFmdC4KPC9wPgo8YSBuYW1lPSJKV1RFeGFtcGxlcyI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEzIj48L2E+PGgzPjEzLiZuYnNwOwpBcHBlbmRp eCAtIE5vbi1Ob3JtYXRpdmUgLSBKV1QgRXhhbXBsZXM8L2gzPgoKPGEgbmFtZT0iSE1BQ1NIQTI1 NkV4YW1wbGUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMy4xIj48L2E+PGgzPjEzLjEu Jm5ic3A7CkpXVCB1c2luZyBITUFDIFNIQS0yNTY8L2gzPgoKPGEgbmFtZT0iYW5jaG9yMTAiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMy4xLjEiPjwvYT48aDM+MTMuMS4xLiZuYnNwOwpF bmNvZGluZzwvaDM+Cgo8cD5UaGUgRGVjb2RlZCBKV1QgQ2xhaW0gU2VnbWVudCB1c2VkIGluIHRo aXMgZXhhbXBsZSBpczoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsg bWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnsiaXNzIjoiam9lIiwK ICJleHAiOjEzMDA4MTkzODAsCiAiaHR0cDovL2V4YW1wbGUuY29tL2lzX3Jvb3QiOnRydWV9PC9w cmU+PC9kaXY+CjxwPk5vdGUgdGhhdCB3aGl0ZSBzcGFjZSBpcyBleHBsaWNpdGx5IGFsbG93ZWQg aW4gRGVjb2RlZCBKV1QgQ2xhaW0gU2VnbWVudHMKICAgIGFuZCBubyBjYW5vbmljYWxpemF0aW9u IGlzIHBlcmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuIFRoZQogICAgZm9sbG93aW5nIGJ5dGUgYXJy YXkgY29udGFpbnMgdGhlIFVURi04IGNoYXJhY3RlcnMgZm9yIHRoZQogICAgRGVjb2RlZCBKV1Qg Q2xhaW0gU2VnbWVudDoKPC9wPgo8cD4KClsxMjMsIDM0LCAxMDUsIDExNSwgMTE1LCAzNCwgNTgs IDM0LCAxMDYsIDExMSwgMTAxLCAzNCwKICA0NCwgMTMsIDEwLCAzMiwgMzQsIDEwMSwgMTIwLCAx MTIsIDM0LCA1OCwgNDksIDUxLAogIDQ4LCA0OCwgNTYsIDQ5LCA1NywgNTEsIDU2LCA0OCwgNDQs IDEzLCAxMCwgMzIsIDM0LAogIDEwNCwgMTE2LCAxMTYsIDExMiwgNTgsIDQ3LCA0NywgMTAxLCAx MjAsIDk3LCAxMDksIDExMiwKICAxMDgsIDEwMSwgNDYsIDk5LCAxMTEsIDEwOSwgNDcsIDEwNSwg MTE1LCA5NSwgMTE0LCAxMTEsCiAgMTExLCAxMTYsIDM0LAo1OCwgMTE2LCAxMTQsIDExNywgMTAx LCAxMjVdCgogICAgCjwvcD4KPHA+QmFzZTY0dXJsIGVuY29kaW5nIHRoZSBhYm92ZSB5aWVsZHMg dGhlIEpXVCBDbGFpbSBTZWdtZW50IHZhbHVlOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFi bGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ ZXlKcGMzTWlPaUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZM eTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUTwvcHJlPjwvZGl2Pgo8cD5UaGUg Zm9sbG93aW5nIGV4YW1wbGUgSlNPTiBlbnZlbG9wZSBvYmplY3QgZGVjbGFyZXMgdGhhdCB0aGUK ICAgICAgZW5jb2RlZCBvYmplY3QgaXMgYSBKU09OIFdlYiBUb2tlbiAoSldUKSBhbmQgdGhlIEpX VCBDbGFpbQogICAgICBTZWdtZW50IGlzIHNpZ25lZCB1c2luZyB0aGUgSE1BQyBTSEEtMjU2IGFs Z29yaXRobToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2lu LWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnsidHlwIjoiSldUIiwKICJhbGci OiJIUzI1NiJ9PC9wcmU+PC9kaXY+CjxwPiBUaGUgZm9sbG93aW5nIGJ5dGUgYXJyYXkgY29udGFp bnMgdGhlIFVURi04IGNoYXJhY3RlcnMgZm9yCiAgICAgIHRoZSBEZWNvZGVkIEpXVCBFbnZlbG9w ZSBTZWdtZW50Ogo8L3A+CjxwPgoKWzEyMywgMzQsIDExNiwgMTIxLCAxMTIsIDM0LCA1OCwgMzQs IDc0LCA4NywgODQsIDM0LAogIDQ0LCAxMywgMTAsIDMyLCAzNCwgOTcsIDEwOCwgMTAzLCAzNCwg NTgsIDM0LCA3MiwgODMsCiAgNTAsIDUzLCA1NCwgMzQsIDEyNV0KCiAgICAKPC9wPgo8cD5CYXNl NjR1cmwgZW5jb2RpbmcgdGhpcyBVVEYtOCByZXByZXNlbnRhdGlvbiB5aWVsZHMgdGhpcyBKV1QK ICAgICAgRW52ZWxvcGUgU2VnbWVudCB2YWx1ZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PmV5SjBlWEFpT2lKS1YxUWlMQTBLSUNKaGJHY2lPaUpJVXpJMU5pSjk8L3ByZT48L2Rpdj4KPHA+ SE1BQ3MgYXJlIGdlbmVyYXRlZCB1c2luZyBrZXlzLiBUaGlzIGV4YW1wbGUgdXNlZCB0aGUKICAg IGtleSByZXByZXNlbnRlZCBieSB0aGUgZm9sbG93aW5nIGJ5dGUgYXJyYXk6CjwvcD4KPHA+Cgpb ODMsIDE1OSwgMTE3LCAxMiwgMjM1LCAxNjksIDE2OCwgMjAwLCAxMzEsIDE1MiwgMjI3LAogIDI0 NiwgMjE0LCAyMTIsIDE4OCwgNzQsIDcxLCA4MywgMjQ0LCAxNjYsIDkwLCAyNCwgMjM5LAogIDI1 MSwgMzIsIDEyNCwgNiwgMjAxLCAxOTQsIDEwNCwgMjQxLCA2MiwgMTc0LCAyNDYsIDY1LAogIDEx MSwgNDksIDUyLCAyMTAsIDExOCwgMjEyLCAxMjQsIDM0LCA4OCwgMTY3LCAxMTIsIDg0LAogIDg4 LCA4MywgNjUsIDE1NSwgMTgsIDIzNCwgMjUwLCAyMjQsIDEwMSwgMTQ3LCAyMjEsIDIzLAogIDEw NCwgMjE5LCAxNzAsIDE0NiwgMjE1XQogICAgCiAgICAKPC9wPgo8cD5SdW5uaW5nIHRoZSBITUFD IFNIQS0yNTYgYWxnb3JpdGhtIG9uIHRoZSBKV1QgQ2xhaW0gU2VnbWVudAogICAgd2l0aCB0aGlz IGtleSB5aWVsZHMgdGhlIGZvbGxvd2luZyBieXRlIGFycmF5Ogo8L3A+CjxwPgoKWzIyMywgMTU1 LCAxNzIsIDkwLCA2MywgODcsIDI0MCwgMTI0LCA2LCA3NSwgMjI0LCAxMzEsCiAgMTE1LCAyOSwg NzMsIDYzLCA5OSwgMTAyLCAxNjksIDIwMiwgMjAzLCAxOTMsIDE1OCwgNCwKICA0MiwgMTU5LCA0 NCwgNTMsIDU2LCA5NSwgMjIxLCAxOThdCgogICAgCjwvcD4KPHA+QmFzZTY0dXJsIGVuY29kaW5n IHRoZSBhYm92ZSBITUFDIG91dHB1dCB5aWVsZHMgdGhlIEpXVCBDcnlwdG8gU2VnbWVudCB2YWx1 ZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPjM1dXNXajlYOEh3R1MtQ0RjeDFKUDJObXFj ckx3WjRFS3A4c05UaGYzY1k8L3ByZT48L2Rpdj4KPHA+Q29tYmluaW5nIHRoZXNlIHNlZ21lbnRz IGluIHRoZSBvcmRlcgogICAgICBFbnZlbG9wZS5DbGFpbXMuU2lnbmF0dXJlIHdpdGggcGVyaW9k IGNoYXJhY3RlcnMgYmV0d2VlbiB0aGUKICAgICAgc2VnbWVudHMgeWllbGRzIHRoaXMgY29tcGxl dGUgSldUICh3aXRoIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5CiAgICAgIHB1cnBvc2VzIG9ubHkp Ogo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDog M2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ZXlKMGVYQWlPaUpLVjFRaUxBMEtJQ0poYkdj aU9pSklVekkxTmlKOQouCmV5SnBjM01pT2lKcWIyVWlMQTBLSUNKbGVIQWlPakV6TURBNE1Ua3pP REFzRFFvZ0ltaDBkSEE2THk5bGVHRnRjR3hsTG1OdmJTOXBjMTl5YjI5MElqcDBjblZsZlEKLgoz NXVzV2o5WDhId0dTLUNEY3gxSlAyTm1xY3JMd1o0RUtwOHNOVGhmM2NZPC9wcmU+PC9kaXY+Cjxh IG5hbWU9ImFuY2hvcjExIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTMuMS4yIj48L2E+ PGgzPjEzLjEuMi4mbmJzcDsKRGVjb2Rpbmc8L2gzPgoKPHA+RGVjb2RpbmcgdGhlIEpXVCBmaXJz dCByZXF1aXJlcyByZW1vdmluZyB0aGUgYmFzZTY0dXJsCiAgICAgIGVuY29kaW5nIGZyb20gdGhl IEpXVCBFbnZlbG9wZSBTZWdtZW50IGFuZCB0aGUgSldUIENsYWltCiAgICAgIFNlZ21lbnQuIFdl IGJhc2U2NHVybCBkZWNvZGUgdGhlIHNlZ21lbnRzIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0n I2Jhc2U2NHVybGxvZ2ljJz5TZWN0aW9uJm5ic3A7NzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5CYXNlNjR1cmwgZW5jb2RpbmcgYXMgdXNlZCBieSBKV1RzPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiBhbmQgdHVybiB0aGVtIGludG8gdGhlCiAgICAgIGNvcnJlc3BvbmRpbmcgVVRG LTggYnl0ZSBhcnJheXMsIHdoaWNoIHdlIHRoZW4gdHJhbnNsYXRlIGludG8KICAgICAgdGhlIERl Y29kZWQgSldUIEVudmVsb3BlIFNlZ21lbnQgYW5kIERlY29kZWQgSldUIENsYWltIFNlZ21lbnQK ICAgICAgc3RyaW5ncy4KPC9wPgo8YSBuYW1lPSJhbmNob3IxMiI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjEzLjEuMyI+PC9hPjxoMz4xMy4xLjMuJm5ic3A7ClZhbGlkYXRpbmc8L2gzPgoK PHA+TmV4dCB3ZSB2YWxpZGF0ZSB0aGUgZGVjb2RlZCByZXN1bHRzLiAgU2luY2UgdGhlICJhbGci CiAgICAgIHBhcmFtZXRlciBpbiB0aGUgZW52ZWxvcGUgaXMgIkhTMjU2Iiwgd2UgdmFsaWRhdGUg dGhlIEhNQUMKICAgICAgU0hBLTI1NiBzaWduYXR1cmUgY29udGFpbmVkIGluIHRoZSBKV1QgQ3J5 cHRvIFNlZ21lbnQuICBJZiBhbnkKICAgICAgb2YgdGhlIHZhbGlkYXRpb24gc3RlcHMgZmFpbCwg dGhlIHRva2VuIE1VU1QgYmUgcmVqZWN0ZWQuCjwvcD4KPHA+Rmlyc3QsIHdlIHZhbGlkYXRlIHRo YXQgdGhlIGRlY29kZWQgZW52ZWxvcGUgYW5kIGNsYWltCiAgICAgIHNlZ21lbnQgc3RyaW5ncyBh cmUgYm90aCBsZWdhbCBKU09OLgo8L3A+CjxwPlRvIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUsIHdl IHJlcGVhdCB0aGUgcHJldmlvdXMgcHJvY2VzcyBvZgogICAgICB1c2luZyB0aGUgY29ycmVjdCBr ZXkgYW5kIHRoZSBKV1QgQ2xhaW0gU2VnbWVudCBhcyBpbnB1dCB0byBhCiAgICAgIFNIQS0yNTYg SE1BQyBmdW5jdGlvbiBhbmQgdGhlbiB0YWtpbmcgdGhlIG91dHB1dCwgYmFzZTY0dXJsCiAgICAg IGVuY29kaW5nIGl0LCBhbmQgZGV0ZXJtaW5pbmcgaWYgaXQgbWF0Y2hlcyB0aGUgSldUIENyeXB0 bwogICAgICBTZWdtZW50IGluIHRoZSBKV1QuICBJZiBpdCBtYXRjaGVzIGV4YWN0bHksIHRoZSB0 b2tlbiBoYXMgYmVlbgogICAgICB2YWxpZGF0ZWQuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTMiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMy4yIj48L2E+PGgzPjEzLjIuJm5ic3A7CkpXVCB1 c2luZyBSU0EgU0hBLTI1NjwvaDM+Cgo8YSBuYW1lPSJhbmNob3IxNCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEzLjIuMSI+PC9hPjxoMz4xMy4yLjEuJm5ic3A7CkVuY29kaW5nPC9oMz4K CjxwPlRoZSBEZWNvZGVkIEpXVCBDbGFpbSBTZWdtZW50IHVzZWQgaW4gdGhpcyBleGFtcGxlIGlz IHRoZSBzYW1lIGFzIGluIHRoZSBwcmV2aW91cyBleGFtcGxlOgo8L3A+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+eyJpc3MiOiJqb2UiLAogImV4cCI6MTMwMDgxOTM4MCwKICJodHRwOi8vZXhhbXBs ZS5jb20vaXNfcm9vdCI6dHJ1ZX08L3ByZT48L2Rpdj4KPHA+U2luY2UgdGhlIEpXVCBDbGFpbSBT ZWdtZW50IHdpbGwgdGhlcmVmb3JlIGJlIHRoZSBzYW1lLCBpdHMKICAgICAgY29tcHV0YXRpb24g aXMgbm90IHJlcGVhdGVkIGhlcmUuICBIb3dldmVyLCB0aGUgRGVjb2RlZCBKV1QKICAgICAgRW52 ZWxvcGUgU2VnbWVudCBpcyBkaWZmZXJlbnQgaW4gdHdvIHdheXM6IEZpcnN0LCBiZWNhdXNlIGEK ICAgICAgZGlmZmVyZW50IGFsZ29yaXRobSBpcyBiZWluZyB1c2VkLCB0aGUgImFsZyIgdmFsdWUg aXMKICAgICAgZGlmZmVyZW50LiAgU2Vjb25kLCBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvc2VzIG9u bHksIHRoZQogICAgICBvcHRpb25hbCAidHlwIiBwYXJhbWV0ZXIgaXMgbm90IHVzZWQuICAoVGhp cyBkaWZmZXJlbmNlIGlzIG5vdAogICAgICByZWxhdGVkIHRvIHRoZSBzaWduYXR1cmUgYWxnb3Jp dGhtIGVtcGxveWVkLikgIFRoZSBEZWNvZGVkIEpXVAogICAgICBFbnZlbG9wZSBTZWdtZW50IHVz ZWQgaXM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT57ImFsZyI6IlJTMjU2In08L3ByZT48 L2Rpdj4KPHA+IFRoZSBmb2xsb3dpbmcgYnl0ZSBhcnJheSBjb250YWlucyB0aGUgVVRGLTggY2hh cmFjdGVycyBmb3IKICAgICAgdGhlIERlY29kZWQgSldUIEVudmVsb3BlIFNlZ21lbnQ6CjwvcD4K PHA+CgogWzEyMywgMzQsIDk3LCAxMDgsIDEwMywgMzQsIDU4LCAzNCwgODIsIDgzLCA1MCwgNTMs CiAgNTQsIDM0LCAxMjVdCgogICAgCjwvcD4KPHA+QmFzZTY0dXJsIGVuY29kaW5nIHRoaXMgVVRG LTggcmVwcmVzZW50YXRpb24geWllbGRzIHRoaXMgSldUCiAgICAgIEVudmVsb3BlIFNlZ21lbnQg dmFsdWU6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT5leUpoYkdjaU9pSlNVekkxTmlKOTwv cHJlPjwvZGl2Pgo8cD5UaGUgUlNBIGtleSBjb25zaXN0cyBvZiBhIHB1YmxpYyBwYXJ0IChuLCBl KSwgYW5kIGEKICAgICAgICBwcml2YXRlIGV4cG9uZW50IGQuICBUaGUgdmFsdWVzIG9mIHRoZSBS U0Ega2V5IHVzZWQgaW4gdGhpcwogICAgICAgIGV4YW1wbGUsIHByZXNlbnRlZCBhcyB0aGUgYnl0 ZSBhcnJheXMgcmVwcmVzZW50aW5nCiAgICAgICAgYmlnIGVuZGlhbiBpbnRlZ2VycyBhcmU6Cjwv cD48dGFibGUgY2xhc3M9ImZ1bGwiIGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjIiIGNlbGxzcGFjaW5nPSIyIj4KPGNvbCBhbGlnbj0ibGVmdCI+PGNvbCBhbGlnbj0ibGVm dCI+Cjx0cj48dGggYWxpZ249ImxlZnQiPlBhcmFtZXRlciBOYW1lPC90aD48dGggYWxpZ249Imxl ZnQiPlZhbHVlPC90aD48L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+bjwvdGQ+Cjx0ZCBhbGln bj0ibGVmdCI+CgpbMjEwLCAyNTIsIDEyMywgMTA2LCAxMCwgMzAsIDEwOCwgMTAzLCAxNiwgNzQs IDIzNSwgMTQzLAoxMzYsIDE3OCwgODcsIDEwMiwgMTU1LCA3NywgMjQ2LCAxMjEsIDIyMSwgMTcz LCA5LCAxNTUsCjkyLCA3NCwgMTA4LCAyMTcsIDE2OCwgMTI4LCAyMSwgMTgxLCAxNjEsIDUxLCAx OTEsIDExLAoxMzMsIDEwOCwgMTIwLCAxMTMsIDE4MiwgMjIzLCAwLCAxMSwgODUsIDc5LCAyMDYs IDE3OSwKMTk0LCAyMzcsIDgxLCA0MywgMTgyLCAxNDMsIDIwLCA5MiwgMTEwLCAxMzIsIDUyLCAx MTcsCjQ3LCAxNzEsIDgyLCAxNjEsCjIwNywgMTkzLCAzNiwgNjQsIDE0MywgMTIxLCAxODEsIDEz OCwgNjksIDEyMCwgMTkzLAoxMDAsIDQwLCAxMzMsIDg3LCAxMzcsIDI0NywgMTYyLCA3MywgMjI3 LCAxMzIsIDIwMywgNDUsCjE1OSwgMTc0LCA0NSwgMTAzLCAyNTMsIDE1MCwgMjUxLCAxNDYsIDEw OCwgMjUsIDE0MiwgNywKMTE1LCAxNTMsIDI1MywgMjAwLCAyMSwgMTkyLCAxNzUsIDksIDEyNSwg MjIyLCA5MCwgMTczLAoyMzksIDI0NCwgNzcsIDIzMSwgMTQsIDEzMCwgMTI3LCA3MiwgMTIwLCA2 NywgMzYsIDU3LAoxOTEsIDIzOCwgMTg1LCA5NiwgMTA0LAoyMDgsIDcxLCA3OSwgMTk3LCAxMywg MTA5LCAxNDQsIDE5MSwgNTgsIDE1MiwgMjIzLCAxNzUsCjE2LCA2NCwgMjAwLCAxNTYsIDIsIDIx NCwgMTQ2LCAxNzEsIDU5LCA2MCwgNDAsIDE1MCwKOTYsIDE1NywgMTM0LCAyNTMsIDExNSwgMTgz LCAxMTYsIDIwNiwgNywgNjQsIDEwMCwgMTI0LAoyMzgsIDIzNCwgMTYzLCAxNiwgMTg5LCAxOCwg MjQ5LCAxMzMsIDE2OCwgMjM1LCAxNTksCjg5LCAyNTMsIDIxMiwgMzgsIDIwNiwgMTY1LCAxNzgs IDE4LCAxNSwgNzksIDQyLCA1MiwKMTg4LCAxNzEsIDExOCwgNzUsIDEyNiwKMTA4LCA4NCwgMjE0 LCAxMzIsIDIsIDU2LCAxODgsIDE5NiwgNSwgMTM1LCAxNjUsIDE1OCwKMTAyLCAyMzcsIDMxLCA1 MSwgMTM3LCA2OSwgMTE5LCA5OSwgOTIsIDcxLCAxMCwgMjQ3LAo5MiwgMjQ5LCA0NCwgMzIsIDIw OSwgMjE4LCA2NywgMjI1LCAxOTEsIDE5NiwgMjUsIDIyNiwKMzQsIDE2NiwgMjQwLCAyMDgsIDE4 NywgNTMsIDE0MCwgOTQsIDU2LCAyNDksIDIwMywgNSwKMTAsIDIzNCwgMjU0LCAxNDQsIDcyLCAy MCwgMjQxLCAxNzIsIDI2LCAxNjQsIDE1NiwgMjAyLAoxNTgsIDE2MCwgMjAyLCAxMzFdCgoJICA8 L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+ZTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ CgpbMSwgMCwgMV0KCgkgIDwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5kPC90ZD4K PHRkIGFsaWduPSJsZWZ0Ij4KCls5NSwgMTM1LCAxOSwgMTgxLCAyMjYsIDg4LCAyNTQsIDksIDI0 OCwgMjEsIDEzMSwgMjM2LAo5MiwgMzEsIDQzLCAxMTcsIDEyMCwgMTc3LCAyMzAsIDI1MiwgNDQs IDEzMSwgODEsIDc1LAo1NSwgMTQ1LCA1NSwgMTcsIDE2MSwgMTg2LCA2OCwgMTU0LCAyMSwgMzEs IDIyNSwgMjAzLAo0NCwgMTYwLCAyNTMsIDUxLCAxODMsIDExMywgMjMwLCAxMzgsIDU5LCAyNSwg NjgsIDEwMCwKMTU3LCAyMDAsIDEwMywgMTczLCAyOCwgMzAsIDgyLCA2NCwgMTg3LCAxMzMsIDYy LCA5NSwKMzYsIDE3OSwgNTIsIDg5LAoxNzcsIDY0LCA0MCwgMjEwLCAyMTQsIDk5LCAxMDcsIDIz OSwgMjM2LCAzMCwgMTQxLCAxNjksCjExNiwgMTc5LCA4MiwgMjUyLCA4MywgMjExLCAyNDYsIDE4 LCAxMjYsIDE2OCwgMTYzLAoxOTQsIDE1NywgMjA5LCA3OSwgNTcsIDY1LCAxMDQsIDQ0LCA4Niwg MTY3LCAxMzUsIDEwNCwKMjIsIDc4LCA3NywgMjE4LCAxNDMsIDYsIDIwMywgMjQ5LCAxOTksIDUy LCAxNzAsIDIzMiwKMCwgNTAsIDM2LCAzOSwgMTQyLCAxNjksIDY5LCA3NCwgMzMsIDE3NywgMTI0 LCAxNzYsCjEwOSwgMjMsIDEyOCwgMTE3LCAxMzQsCjE0MCwgMTkyLCA5MSwgNjEsIDE4MiwgMjU1 LCAyOSwgMjUzLCAxOTUsIDIxMywgOTksIDEyMCwKMTgwLCAyMzcsIDE3MywgMjM3LCAyNDAsIDE5 NSwgMTIyLCA3NiwgMjIwLCAzOCwgMjA5LAoyMTIsIDE1NCwgMTk0LCAxMTEsIDExMSwgMjI3LCAx ODEsIDM0LCAxMCwgOTMsIDIxMCwKMTQ3LCAxNTAsIDk4LCAyNywgMTg4LCAxMDQsIDE0MCwgMjQy LCAyMzgsIDIyNiwgMTk4LAoyMjQsIDIxMywgNzcsIDE2MywgMTk5LCAxMzAsIDEsIDc2LCAyMDgs IDExNSwgMTU3LCAxNzgsCjgyLCAyMDQsIDgxLCAyMDIsIDIzNSwgMTY4LCAyMTEsCjI0MSwgMTg0 LCAzNiwgMTg2LCAxNzEsIDM2LCAyMDgsIDEwNCwgMjM2LCAxNDQsIDUwLAoxMDAsIDIxNSwgMjE0 LCAxMjAsIDE3MSwgOCwgMjQwLCAxMTAsIDIwMSwgMjMxLCAyMjYsCjYxLCAxNTAsIDYsIDQwLCAx ODMsIDY4LCAxOTEsIDE0OCwgMTc5LCAxMDUsIDcwLCA4NiwKNzAsIDYwLCAxMjYsIDY1LCAxMTUs IDE1MywgMjM3LCAxMTUsIDIwOCwgMTE4LCAyMDAsCjE0NSwgMjUyLCAyNDQsIDk5LCAxNjksIDE3 MCwgMTU2LCAyMzAsIDQ1LCAxNjksIDIwNSwKMjMsIDIyNiwgNTUsIDIyMCwgNDIsIDEyOCwgMiwg MjQxXQoKCSAgPC90ZD4KPC90cj4KPC90YWJsZT4KPGJyIGNsZWFyPSJhbGwiIC8+Cgo8cD5UaGUg UlNBIHByaXZhdGUga2V5IChuLCBkKSBpcyB0aGVuIHBhc3NlZCB0byB0aGUgUlNBCglzaWduaW5n IGZ1bmN0aW9uLCB3aGljaCBhbHNvIHRha2VzIHRoZSBoYXNoIHR5cGUsIFNIQS0yNTYsIGFuZAoJ dGhlIEpXVCBDbGFpbSBTZWdtZW50IGFzIGlucHV0cy4gIFRoZSByZXN1bHQgb2YgdGhlIHNpZ25h dHVyZQoJaXMgYSBieXRlIGFycmF5IFMsIHdoaWNoIHJlcHJlc2VudHMgYSBiaWcgZW5kaWFuIGlu dGVnZXIuICBJbgoJdGhpcyBleGFtcGxlLCBTIGlzOgo8L3A+PHRhYmxlIGNsYXNzPSJmdWxsIiBh bGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+ Cjxjb2wgYWxpZ249ImxlZnQiPjxjb2wgYWxpZ249ImxlZnQiPgo8dHI+PHRoIGFsaWduPSJsZWZ0 Ij5SZXN1bHQgTmFtZTwvdGg+PHRoIGFsaWduPSJsZWZ0Ij5WYWx1ZTwvdGg+PC90cj4KPHRyPgo8 dGQgYWxpZ249ImxlZnQiPlM8L3RkPgo8dGQgYWxpZ249ImxlZnQiPgoKWzIwOCwgMTQxLCAyMTks IDQ0LCA2NiwgMTI5LCAxNzksIDIzMCwgNjksIDEyMCwgMTIzLAoxMDgsIDIwMywgOTYsIDE4Miwg MTQ1LCA2NiwgMTc5LCAxOTgsIDEwNCwgNDMsIDE4NywKMTk5LCAxNTksIDE3NSwgNSwgMjE3LCAx MDEsIDEwOSwgMjM2LCA4OCwgMTM2LCAxOTMsCjEzMywgNzksIDM5LCAxNjIsIDEzMSwgNTgsIDEx NCwgMTMzLCAyMDIsIDE3MSwgMjI3LAoxMzUsIDE1NywgMTIzLCAxODgsIDkwLCAxMTEsIDY2LCAy NDEsIDM4LCAyMzgsIDU5LCAxOCwKMTI1LCAxNDYsIDEyOSwgMTQsIDU0LCAxODMsIDEwLCAyMjEs CjMzLCAxMDUsIDM3LCAxNzMsIDExOSwgMjM5LCA5MiwgMjcsIDIzMiwgMTc1LCAxNzMsIDQ5LAoy MSwgMjgsIDI1MiwgMjM3LCAxODMsIDEwNywgOTgsIDE1NiwgMTEzLCAxMTYsIDE2MiwKMjE5LCA1 MywgOTYsIDQ0LCAyMTQsIDE3NSwgMTU0LCA2MSwgMTAwLCAxNzUsIDkwLCAxMTgsCjI0NywgNDIs IDE5NiwgNDUsIDc0LCAyMTcsIDE0NSwgOTIsIDM5LCAxMjMsIDIyNCwgMjQ3LAoxNzEsIDIwNiwg MjAzLCA5MSwgMTY3LCAxMDMsIDU3LCAxNjMsIDg3LCAxNzIsIDY3LCA3NywKMjU1LCA5LCAyMTgs IDEwNywgNjIsCjIyOCwgNzEsIDIzOSwgMzYsIDI0NiwgMjMsIDk2LCAxMDgsIDI4LCAxOSwgMTc5 LCAyNCwKMTY3LCAxOTYsIDQyLCA5NywgMTk4LCA4MCwgMjQxLCA3OSwgMzEsIDAsIDg1LCAxNywK NTAsIDYsIDE0MywgMjM4LCAyMTQsIDEzMSwgMjQ2LCAxMywgNDksIDExMSwgMzAsIDE0MiwKMTgy LCAxNDUsIDIwMCwgMTcsIDEyNywgNzYsIDIzNiwgNjksIDY2LCAxMzMsIDE5OCwgMTM3LAoxMDMs IDQ1LCAzLCA0OCwgMTIzLCAyMDMsIDE3LCAxNjIsIDEsIDEwNSwgMTMzLCAyMiwKMTA1LCAyNSwg NjMsIDE3MywKMTg2LCAyMzEsIDIwNiwgMjQ2LCAyMiwgMjQzLCAyNTAsIDUzLCAyMzcsIDIwOSwg MzYsCjExMSwgMTY4LCAxMSwgNDAsIDIzNywgMTc5LCA4MywgMTI1LCAxODAsIDg0LCAyMzEsIDEy OSwKMzcsIDIzNiwgMTcyLCAyMiwgMjM0LCA1OCwgMTk4LCAxODcsIDEyNCwgNjUsIDE0NSwgMTQ4 LAoyMjcsIDEyMiwgMTc3LCAxNiwgMTc2LCA4NCwgMjgsIDEsIDE0MSwgMTc5LCA1NywgOTYsCjIz MiwgMjE1LCA1MSwgNywgNDksIDYzLCAxOTUsIDE1NSwgOTQsIDUxLCAyMiwgMjM5LAo5MCwgMTM4 LCAyMDcsIDQxLCA2Ml0KCgkgIDwvdGQ+CjwvdHI+CjwvdGFibGU+CjxiciBjbGVhcj0iYWxsIiAv PgoKPHA+QmFzZTY0dXJsIGVuY29kaW5nIHRoZSBzaWduYXR1cmUgcHJvZHVjZXMgdGhpcyB2YWx1 ZSBmb3IgdGhlIEpXVAoJQ3J5cHRvIFNlZ21lbnQ6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4wSTNiTEVLQnMtWkZlSHRzeTJDMmtVS3p4bWdydThlZnJ3WFpaVzNzV0lqQmhVOG5vb002Y29Y S3EtT0huWHU4V205QzhTYnVPeEo5a29FT05yY0szU0ZwSmExMzcxd2I2Sy10TVJVY19PMjNhMktj Y1hTaTJ6VmdMTmF2bWoxa3IxcDI5eXJFTFVyWmtWd25lLUQzcTg3TFc2ZG5PYU5YckVOTl93bmFh ejdrUi04azloZGdiQndUc3hpbnhDcGh4bER4VHg4QVZSRXlCb191MW9QMkRURnZIbzYya2NnUmYw enNSVUtGeG9sbkxRTXdlOHNSb2dGcGhSWnBHVC10dXVmTzloYnotalh0MFNSdnFBc283Yk5UZmJS VTU0RWw3S3dXNmpyR3UzeEJrWlRqZXJFUXNGUWNBWTJ6T1dEbzF6TUhNVF9EbTE0ekZ1OWFpczhw UGc8L3ByZT48L2Rpdj4KPHA+Q29tYmluaW5nIHRoZXNlIHNlZ21lbnRzIGluIHRoZSBvcmRlcgog ICAgICBFbnZlbG9wZS5DbGFpbXMuU2lnbmF0dXJlIHdpdGggcGVyaW9kIGNoYXJhY3RlcnMgYmV0 d2VlbiB0aGUKICAgICAgc2VnbWVudHMgeWllbGRzIHRoaXMgY29tcGxldGUgSldUICh3aXRoIGxp bmUgYnJlYWtzIGZvciBkaXNwbGF5CiAgICAgIHB1cnBvc2VzIG9ubHkpOgo8L3A+PGRpdiBzdHls ZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+ZXlKaGJHY2lPaUpTVXpJMU5pSjkKLgpleUpwYzNNaU9pSnFiMlVpTEEw S0lDSmxlSEFpT2pFek1EQTRNVGt6T0RBc0RRb2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlw YzE5eWIyOTBJanAwY25WbGZRCi4KMEkzYkxFS0JzLVpGZUh0c3kyQzJrVUt6eG1ncnU4ZWZyd1ha Wlczc1dJakJoVThub29NNmNvWEtxLU9Iblh1OFdtOUM4U2J1T3hKOWtvRU9OcmNLM1NGcEphMTM3 MXdiNkstdE1SVWNfTzIzYTJLY2NYU2kyelZnTE5hdm1qMWtyMXAyOXlyRUxVclprVnduZS1EM3E4 N0xXNmRuT2FOWHJFTk5fd25hYXo3a1ItOGs5aGRnYkJ3VHN4aW54Q3BoeGxEeFR4OEFWUkV5Qm9f dTFvUDJEVEZ2SG82MmtjZ1JmMHpzUlVLRnhvbG5MUU13ZThzUm9nRnBoUlpwR1QtdHV1Zk85aGJ6 LWpYdDBTUnZxQXNvN2JOVGZiUlU1NEVsN0t3VzZqckd1M3hCa1pUamVyRVFzRlFjQVkyek9XRG8x ek1ITVRfRG0xNHpGdTlhaXM4cFBnPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjE1Ij48L2E+ PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTMuMi4yIj48L2E+PGgzPjEzLjIuMi4mbmJzcDsKRGVj b2Rpbmc8L2gzPgoKPHA+RGVjb2RpbmcgdGhlIEpXVCBmcm9tIHRoaXMgZXhhbXBsZSByZXF1aXJl cyBwcm9jZXNzaW5nIHRoZQogICAgICBKV1QgRW52ZWxvcGUgU2VnbWVudCBhbmQgQ2xhaW0gU2Vn bWVudCBleGFjdGx5IGFzIGRvbmUgaW4gdGhlCiAgICAgIGZpcnN0IGV4YW1wbGUuCjwvcD4KPGEg bmFtZT0iYW5jaG9yMTYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMy4yLjMiPjwvYT48 aDM+MTMuMi4zLiZuYnNwOwpWYWxpZGF0aW5nPC9oMz4KCjxwPlNpbmNlIHRoZSAiYWxnIiBwYXJh bWV0ZXIgaW4gdGhlIGVudmVsb3BlIGlzICJSUzI1NiIsIHdlCiAgICAgIHZhbGlkYXRlIHRoZSBS U0EgU0hBLTI1NiBzaWduYXR1cmUgY29udGFpbmVkIGluIHRoZSBKV1QgQ3J5cHRvCiAgICAgIFNl Z21lbnQuICBJZiBhbnkgb2YgdGhlIHZhbGlkYXRpb24gc3RlcHMgZmFpbCwgdGhlIHRva2VuIE1V U1QgYmUKICAgICAgcmVqZWN0ZWQuCjwvcD4KPHA+Rmlyc3QsIHdlIHZhbGlkYXRlIHRoYXQgdGhl IGRlY29kZWQgZW52ZWxvcGUgYW5kIGNsYWltCiAgICAgIHNlZ21lbnQgc3RyaW5ncyBhcmUgYm90 aCBsZWdhbCBKU09OLgo8L3A+CjxwPlZhbGlkYXRpbmcgdGhlIEpXVCBDcnlwdG8gU2VnbWVudCBp cyBhIGxpdHRsZSBkaWZmZXJlbnQgZnJvbQogICAgICB0aGUgcHJldmlvdXMgZXhhbXBsZS4gRmly c3QsIHdlIGJhc2U2NHVybCBkZWNvZGUgdGhlIEpXVCBDcnlwdG8KICAgICAgU2VnbWVudCB0byBw cm9kdWNlIGEgc2lnbmF0dXJlIFMgdG8gY2hlY2suICBXZSB0aGVuIHBhc3MgKG4sIGUpLAogICAg ICBTIGFuZCB0aGUgSldUIENsYWltIFNlZ21lbnQgdG8gYW4gUlNBIHNpZ25hdHVyZSB2ZXJpZmll ciB0aGF0CiAgICAgIGhhcyBiZWVuIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBTSEEtMjU2IGhhc2gg ZnVuY3Rpb24uCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi4xMy4zIj48L2E+PGgzPjEzLjMuJm5ic3A7CkpXVCB1c2luZyBFQ0RTQSBQLTI1NiBTSEEt MjU2PC9oMz4KCjxhIG5hbWU9ImFuY2hvcjE4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u MTMuMy4xIj48L2E+PGgzPjEzLjMuMS4mbmJzcDsKRW5jb2Rpbmc8L2gzPgoKPHA+VGhlIERlY29k ZWQgSldUIENsYWltIFNlZ21lbnQgdXNlZCBpbiB0aGlzIGV4YW1wbGUgaXMgdGhlIHNhbWUgYXMg aW4gdGhlIHByZXZpb3VzIGV4YW1wbGVzOgo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7 IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+eyJp c3MiOiJqb2UiLAogImV4cCI6MTMwMDgxOTM4MCwKICJodHRwOi8vZXhhbXBsZS5jb20vaXNfcm9v dCI6dHJ1ZX08L3ByZT48L2Rpdj4KPHA+U2luY2UgdGhlIEpXVCBDbGFpbSBTZWdtZW50IHdpbGwg dGhlcmVmb3JlIGJlIHRoZSBzYW1lLCBpdHMKICAgICAgY29tcHV0YXRpb24gaXMgbm90IHJlcGVh dGVkIGhlcmUuICBIb3dldmVyLCB0aGUgRGVjb2RlZCBKV1QKICAgICAgRW52ZWxvcGUgU2VnbWVu dCBpcyBkaWZmZXJzIGZyb20gdGhlIHByZXZpb3VzIGV4YW1wbGUgYmVjYXVzZSBhCiAgICAgIGRp ZmZlcmVudCBhbGdvcml0aG0gaXMgYmVpbmcgdXNlZC4gIFRoZSBEZWNvZGVkIEpXVCBFbnZlbG9w ZQogICAgICBTZWdtZW50IHVzZWQgaXM6CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT57ImFs ZyI6IkVTMjU2In08L3ByZT48L2Rpdj4KPHA+IFRoZSBmb2xsb3dpbmcgYnl0ZSBhcnJheSBjb250 YWlucyB0aGUgVVRGLTggY2hhcmFjdGVycyBmb3IKICAgICAgdGhlIERlY29kZWQgSldUIEVudmVs b3BlIFNlZ21lbnQ6CjwvcD4KPHA+CgpbMTIzLCAzNCwgOTcsIDEwOCwgMTAzLCAzNCwgNTgsIDM0 LCA2OSwgODMsIDUwLCA1MywKICA1NCwgMzQsIDEyNV0KCiAgICAKPC9wPgo8cD5CYXNlNjR1cmwg ZW5jb2RpbmcgdGhpcyBVVEYtOCByZXByZXNlbnRhdGlvbiB5aWVsZHMgdGhpcyBKV1QKICAgICAg RW52ZWxvcGUgU2VnbWVudCB2YWx1ZToKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3 aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPmV5Smhi R2NpT2lKRlV6STFOaUo5PC9wcmU+PC9kaXY+CjxwPlRoZSBFQ0RTQSBrZXkgY29uc2lzdHMgb2Yg YSBwdWJsaWMgcGFydCwgdGhlIEVDIHBvaW50ICh4LCB5KSwgYW5kIGEKICAgICAgcHJpdmF0ZSBw YXJ0IGQuICBUaGUgdmFsdWVzIG9mIHRoZSBFQ0RTQSBrZXkgdXNlZCBpbiB0aGlzCiAgICAgIGV4 YW1wbGUsIHByZXNlbnRlZCBhcyB0aGUgYnl0ZSBhcnJheXMgcmVwcmVzZW50aW5nCiAgICAgIGJp ZyBlbmRpYW4gaW50ZWdlcnMgYXJlOgo8L3A+PHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2Vu dGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+Cjxjb2wgYWxp Z249ImxlZnQiPjxjb2wgYWxpZ249ImxlZnQiPgo8dHI+PHRoIGFsaWduPSJsZWZ0Ij5QYXJhbWV0 ZXIgTmFtZTwvdGg+PHRoIGFsaWduPSJsZWZ0Ij5WYWx1ZTwvdGg+PC90cj4KPHRyPgo8dGQgYWxp Z249ImxlZnQiPng8L3RkPgo8dGQgYWxpZ249ImxlZnQiPgoKWzQ4LCAxNjAsIDY2LCA3NiwgMjEw LCAyOCwgNDEsIDY4LCAxMzEsIDEzOCwgNDUsIDExNywKMjAxLCA0MywgNTUsIDIzMSwgMTEwLCAx NjIsIDEzLCAxNTksIDAsIDEzNywgNTgsIDU5LAo3OCwgMjM4LCAxMzgsIDYwLCAxMCwgMTc1LCAy MzYsIDYyXQoKCTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij55PC90ZD4KPHRkIGFs aWduPSJsZWZ0Ij4KClsyMjQsIDc1LCAxMDEsIDIzMywgMzYsIDg2LCAyMTcsIDEzNiwgMTM5LCA4 MiwgMTc5LCAxMjEsCjE4OSwgMjUxLCAyMTMsIDMwLCAyMzIsIDEwNSwgMjM5LCAzMSwgMTUsIDE5 OCwgOTEsIDEwMiwKODksIDEwNSwgOTEsIDEwOCwgMjA2LCA4LCAyMywgMzVdCgoJPC90ZD4KPC90 cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPmQ8L3RkPgo8dGQgYWxpZ249ImxlZnQiPgoKWzI0Mywg MTg5LCAxMiwgNywgMTY4LCAzMSwgMTg1LCA1MCwgMTIwLCAzMCwgMjEzLCAzOSwKODIsIDI0Niwg MTIsIDIwMCwgMTU0LCAxMDcsIDIyOSwgMjI5LCAyNSwgNTIsIDI1NCwgMSwKMTQ3LCAxNDEsIDIx OSwgODUsIDIxNiwgMjQ3LCAxMjAsIDFdCgoJPC90ZD4KPC90cj4KPC90YWJsZT4KPGJyIGNsZWFy PSJhbGwiIC8+Cgo8cD5UaGUgRUNEU0EgcHJpdmF0ZSBwYXJ0IGQgaXMgdGhlbiBwYXNzZWQgdG8g YW4gRUNEU0EKICAgICAgc2lnbmluZyBmdW5jdGlvbiwgd2hpY2ggYWxzbyB0YWtlcyB0aGUgY3Vy dmUgdHlwZSwKICAgICAgUC0yNTYsIHRoZSBoYXNoIHR5cGUsIFNIQS0yNTYsIGFuZCB0aGUgSldU IENsYWltCiAgICAgIFNlZ21lbnQgYXMgaW5wdXRzLiAgVGhlIHJlc3VsdCBvZiB0aGUgc2lnbmF0 dXJlIGlzIHRoZQogICAgICBFQyBwb2ludCAoUiwgUyksIHdoZXJlIFIgYW5kIFMgYXJlIHVuc2ln bmVkIGludGVnZXJzLgogICAgICBJbiB0aGlzIGV4YW1wbGUsIHRoZSBSIGFuZCBTIHZhbHVlcywg Z2l2ZW4gYXMKICAgICAgYnl0ZSBhcnJheXMgcmVwcmVzZW50aW5nIGJpZyBlbmRpYW4gaW50ZWdl cnMgYXJlOgo8L3A+PHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+Cjxjb2wgYWxpZ249ImxlZnQiPjxjb2wg YWxpZ249ImxlZnQiPgo8dHI+PHRoIGFsaWduPSJsZWZ0Ij5SZXN1bHQgTmFtZTwvdGg+PHRoIGFs aWduPSJsZWZ0Ij5WYWx1ZTwvdGg+PC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPlI8L3RkPgo8 dGQgYWxpZ249ImxlZnQiPgoKWzE3NSwgMTEsIDExNSwgNDIsIDE2MCwgMTgyLCAxODEsIDI4LCAx MzUsIDIyMiwgNTIsIDE1NCwKICAxODIsIDIzNywgMjA2LCAxMzcsIDgyLCAyMCwgMjQzLCA3LCAx MiwgMTY0LCAxMDcsIDcyLAogIDIzNiwgMTg3LCAyNDEsIDE5MCwgMjYsIDc2LCAzMiwgMTgxXQoK CTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij5TPC90ZD4KPHRkIGFsaWduPSJsZWZ0 Ij4KClsxMjAsIDIzLCAxODksIDIwNSwgMjAyLCAxMywgMTc3LCAxODcsIDIzLCA0NywgMTIsIDIy NywKICAyMzcsIDI1MCwgMjMwLCAyMzMsIDI0NSwgMjE2LCA5LCAxNzAsIDI0LCAxODUsIDE5OCwK ICAxODcsIDE5MywgOTQsIDE1OCwgMTE3LCAxNjcsIDg4LCAxNTMsIDE5Nl0KCgk8L3RkPgo8L3Ry Pgo8L3RhYmxlPgo8YnIgY2xlYXI9ImFsbCIgLz4KCjxwPkNvbmNhdGVuYXRpbmcgdGhlIFMgYXJy YXkgdG8gdGhlIGVuZCBvZiB0aGUgUiBhcnJheSBhbmQKICAgICAgYmFzZTY0dXJsIGVuY29kaW5n IHRoZSByZXN1bHQgcHJvZHVjZXMgdGhpcyB2YWx1ZSBmb3IgdGhlIEpXVAogICAgICBDcnlwdG8g U2VnbWVudDoKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2lu LWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnJ3dHpLcUMydFJ5SDNqU2F0dTNP aVZJVTh3Y01wR3RJN0x2eHZocE1JTFY0RjczTnlnMnh1eGN2RE9QdC11YnA5ZGdKcWhpNXhydkJY cDUxcDFpWnhBPC9wcmU+PC9kaXY+CjxwPkNvbWJpbmluZyB0aGVzZSBzZWdtZW50cyBpbiB0aGUg b3JkZXIKICAgICAgRW52ZWxvcGUuQ2xhaW1zLlNpZ25hdHVyZSB3aXRoIHBlcmlvZCBjaGFyYWN0 ZXJzIGJldHdlZW4gdGhlCiAgICAgIHNlZ21lbnRzIHlpZWxkcyB0aGlzIGNvbXBsZXRlIEpXVCAo d2l0aCBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheQogICAgICBwdXJwb3NlcyBvbmx5KToKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPmV5SmhiR2NpT2lKRlV6STFOaUo5Ci4KZXlKcGMzTWlPaUpx YjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxM bU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUQouCnJ3dHpLcUMydFJ5SDNqU2F0dTNPaVZJVTh3Y01w R3RJN0x2eHZocE1JTFY0RjczTnlnMnh1eGN2RE9QdC11YnA5ZGdKcWhpNXhydkJYcDUxcDFpWnhB PC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjE5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMTMuMy4yIj48L2E+PGgzPjEzLjMuMi4mbmJzcDsKRGVjb2Rpbmc8L2gzPgoKPHA+RGVjb2Rp bmcgdGhlIEpXVCBmcm9tIHRoaXMgZXhhbXBsZSByZXF1aXJlcyBwcm9jZXNzaW5nIHRoZQogICAg ICBKV1QgRW52ZWxvcGUgU2VnbWVudCBhbmQgQ2xhaW0gU2VnbWVudCBleGFjdGx5IGFzIGRvbmUg aW4gdGhlCiAgICAgIGZpcnN0IGV4YW1wbGUuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjAiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMy4zLjMiPjwvYT48aDM+MTMuMy4zLiZuYnNwOwpWYWxp ZGF0aW5nPC9oMz4KCjxwPlNpbmNlIHRoZSAiYWxnIiBwYXJhbWV0ZXIgaW4gdGhlIGVudmVsb3Bl IGlzICJFUzI1NiIsIHdlCiAgICAgIHZhbGlkYXRlIHRoZSBFQ0RTQSBQLTI1NiBTSEEtMjU2IHNp Z25hdHVyZSBjb250YWluZWQgaW4gdGhlIEpXVAogICAgICBDcnlwdG8gU2VnbWVudC4gIElmIGFu eSBvZiB0aGUgdmFsaWRhdGlvbiBzdGVwcyBmYWlsLCB0aGUgdG9rZW4KICAgICAgTVVTVCBiZSBy ZWplY3RlZC4KPC9wPgo8cD5GaXJzdCwgd2UgdmFsaWRhdGUgdGhhdCB0aGUgZGVjb2RlZCBlbnZl bG9wZSBhbmQgY2xhaW0KICAgICAgc2VnbWVudCBzdHJpbmdzIGFyZSBib3RoIGxlZ2FsIEpTT04u CjwvcD4KPHA+VmFsaWRhdGluZyB0aGUgSldUIENyeXB0byBTZWdtZW50IGlzIGEgbGl0dGxlIGRp ZmZlcmVudCBmcm9tCiAgICAgIHRoZSBmaXJzdCBleGFtcGxlLiBGaXJzdCwgd2UgYmFzZTY0dXJs IGRlY29kZSB0aGUgSldUIENyeXB0bwogICAgICBTZWdtZW50IGFzIGluIHRoZSBwcmV2aW91cyBl eGFtcGxlcyBidXQgd2UgdGhlbiBuZWVkIHRvIHNwbGl0CiAgICAgIHRoZSA2NCBtZW1iZXIgYnl0 ZSBhcnJheSB0aGF0IG11c3QgcmVzdWx0IGludG8gdHdvIDMyIGJ5dGUKICAgICAgYXJyYXlzLCB0 aGUgZmlyc3QgUiBhbmQgdGhlIHNlY29uZCBTLiBXZSB0aGVuIHBhc3MgKHgsIHkpLCAoUiwKICAg ICAgUykgYW5kIHRoZSBKV1QgQ2xhaW0gU2VnbWVudCB0byBhbiBFQ0RTQSBzaWduYXR1cmUgdmVy aWZpZXIgdGhhdAogICAgICBoYXMgYmVlbiBjb25maWd1cmVkIHRvIHVzZSB0aGUgUC0yNTYgY3Vy dmUgd2l0aCB0aGUgU0hBLTI1NiBoYXNoCiAgICAgIGZ1bmN0aW9uLgo8L3A+CjxwPkFzIGV4cGxh aW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0RlZmluaW5nRUNEU0EnPlNlY3Rpb24mbmJz cDs4LjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U2lnbmluZyBhIEpXVCB3aXRo IEVDRFNBIFAtMjU2IFNIQS0yNTY8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCB0aGUKICAgICAg dXNlIG9mIHRoZSBrIHZhbHVlIGluIEVDRFNBIG1lYW5zIHRoYXQgd2UgY2Fubm90IHZhbGlkYXRl IHRoZQogICAgICBjb3JyZWN0bmVzcyBvZiB0aGUgc2lnbmF0dXJlIGluIHRoZSBzYW1lIHdheSB3 ZSB2YWxpZGF0ZWQgdGhlCiAgICAgIGNvcnJlY3RuZXNzIG9mIHRoZSBITUFDLiBJbnN0ZWFkLCBp bXBsZW1lbnRhdGlvbnMgTVVTVCB1c2UgYW4KICAgICAgRUNEU0EgdmFsaWRhdG9yIHRvIHZhbGlk YXRlIHRoZSBzaWduYXR1cmUuCjwvcD4KPGEgbmFtZT0iYmFzZTY0dXJsbm90ZXMiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xNCI+PC9hPjxoMz4xNC4mbmJzcDsKQXBwZW5kaXggLSBOb24t Tm9ybWF0aXZlIC0gTm90ZXMgb24gaW1wbGVtZW50aW5nIGJhc2U2NHVybCBlbmNvZGluZyB3aXRo b3V0IHBhZGRpbmc8L2gzPgoKPHA+VGhpcyBhcHBlbmRpeCBkZXNjcmliZXMgaG93IHRvIGltcGxl bWVudCBiYXNlNjR1cmwgZW5jb2RpbmcKICBhbmQgZGVjb2RpbmcgZnVuY3Rpb25zIHdpdGhvdXQg cGFkZGluZyBiYXNlZCB1cG9uIHN0YW5kYXJkCiAgYmFzZTY0IGVuY29kaW5nIGFuZCBkZWNvZGlu ZyBmdW5jdGlvbnMgdGhhdCBkbyB1c2UgcGFkZGluZy4KPC9wPgo8cD5UbyBiZSBjb25jcmV0ZSwg ZXhhbXBsZSBDIyBjb2RlIGltcGxlbWVudGluZyB0aGVzZSBmdW5jdGlvbnMKICBpcyBzaG93biBi ZWxvdy4gIFNpbWlsYXIgY29kZSBjb3VsZCBiZSB1c2VkIGluIG90aGVyCiAgbGFuZ3VhZ2VzLgo8 L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2Vt OyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+c3RhdGljIHN0cmluZyBiYXNlNjR1cmxlbmNvZGUo Ynl0ZSBbXSBhcmcpCnsKICBzdHJpbmcgcyA9IENvbnZlcnQuVG9CYXNlNjRTdHJpbmcoYXJnKTsg Ly8gU3RhbmRhcmQgYmFzZTY0IGVuY29kZXIKICBzID0gcy5TcGxpdCgnPScpWzBdOyAvLyBSZW1v dmUgYW55IHRyYWlsaW5nICc9J3MKICBzID0gcy5SZXBsYWNlKCcrJywgJy0nKTsgLy8gNjJuZCBj aGFyIG9mIGVuY29kaW5nCiAgcyA9IHMuUmVwbGFjZSgnLycsICdfJyk7IC8vIDYzcmQgY2hhciBv ZiBlbmNvZGluZwogIHJldHVybiBzOwp9CgpzdGF0aWMgYnl0ZSBbXSBiYXNlNjR1cmxkZWNvZGUo c3RyaW5nIGFyZykKewogIHN0cmluZyBzID0gYXJnOwogIHMgPSBzLlJlcGxhY2UoJy0nLCAnKycp OyAvLyA2Mm5kIGNoYXIgb2YgZW5jb2RpbmcKICBzID0gcy5SZXBsYWNlKCdfJywgJy8nKTsgLy8g NjNyZCBjaGFyIG9mIGVuY29kaW5nCiAgc3dpdGNoIChzLkxlbmd0aCAlIDQpIC8vIFBhZCB3aXRo IHRyYWlsaW5nICc9J3MKICB7CiAgICBjYXNlIDA6IGJyZWFrOyAvLyBObyBwYWQgY2hhcnMgaW4g dGhpcyBjYXNlCiAgICBjYXNlIDI6IHMgKz0gIj09IjsgYnJlYWs7IC8vIFR3byBwYWQgY2hhcnMK ICAgIGNhc2UgMzogcyArPSAiPSI7IGJyZWFrOyAvLyBPbmUgcGFkIGNoYXIKICAgIGRlZmF1bHQ6 IHRocm93IG5ldyBTeXN0ZW0uRXhjZXB0aW9uKAogICAgICAiSWxsZWdhbCBiYXNlNjR1cmwgc3Ry aW5nISIpOwogIH0KICByZXR1cm4gQ29udmVydC5Gcm9tQmFzZTY0U3RyaW5nKHMpOyAvLyBTdGFu ZGFyZCBiYXNlNjQgZGVjb2Rlcgp9PC9wcmU+PC9kaXY+CjxwPkFzIHBlciB0aGUgZXhhbXBsZSBj b2RlIGFib3ZlLCB0aGUgbnVtYmVyIG9mICc9JyBwYWRkaW5nCiAgY2hhcmFjdGVycyB0aGF0IG5l ZWRzIHRvIGJlIGFkZGVkIHRvIHRoZSBlbmQgb2YgYSBiYXNlNjR1cmwKICBlbmNvZGVkIHN0cmlu ZyB3aXRob3V0IHBhZGRpbmcgdG8gdHVybiBpdCBpbnRvIG9uZSB3aXRoIHBhZGRpbmcKICBpcyBh IGRldGVybWluaXN0aWMgZnVuY3Rpb24gb2YgdGhlIGxlbmd0aCBvZiB0aGUgZW5jb2RlZCBzdHJp bmcuCiAgU3BlY2lmaWNhbGx5LAogIGlmIHRoZSBsZW5ndGggbW9kIDQgaXMgMCwgbm8gcGFkZGlu ZyBpcyBhZGRlZDsKICBpZiB0aGUgbGVuZ3RoIG1vZCA0IGlzIDIsIHR3byAnPScgcGFkZGluZyBj aGFyYWN0ZXJzIGFyZSBhZGRlZDsKICBpZiB0aGUgbGVuZ3RoIG1vZCA0IGlzIDMsIG9uZSAnPScg cGFkZGluZyBjaGFyYWN0ZXIgaXMgYWRkZWQ7CiAgaWYgdGhlIGxlbmd0aCBtb2QgNCBpcyAxLCB0 aGUgaW5wdXQgaXMgbWFsZm9ybWVkLgo8L3A+CjxwPkFuIGV4YW1wbGUgY29ycmVzcG9uZGVuY2Ug YmV0d2VlbiB1bmVuY29kZWQgYW5kIGVuY29kZWQKICB2YWx1ZXMgZm9sbG93cy4gIFRoZSBieXRl IHNlcXVlbmNlIGJlbG93IGVuY29kZXMgaW50byB0aGUgc3RyaW5nCiAgYmVsb3csIHdoaWNoIHdo ZW4gZGVjb2RlZCwgcmVwcm9kdWNlcyB0aGUgYnl0ZSBzZXF1ZW5jZS4KPC9wPjxkaXYgc3R5bGU9 J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0 OiBhdXRvJz48cHJlPjMgMjM2IDI1NSAyMjQgMTkzPC9wcmU+PC9kaXY+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+QS16XzRNRTwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3IyMSI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjE1Ij48L2E+PGgzPjE1LiZuYnNwOwpBcHBlbmRpeCAtIE5vbi1O b3JtYXRpdmUgLSBSZWxhdGlvbnNoaXAgb2YgSldUcyB0byBTQU1MIFRva2VuczwvaDM+Cgo8cD48 YSBjbGFzcz0naW5mbycgaHJlZj0nI09BU0lTLnNhbWwtY29yZS0yLjAtb3MnPlNBTUwgMi4wPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbnRvciwgUy4sIEtlbXAsIEouLCBQaGls cG90dCwgUi4sIGFuZCBFLiBNYWxlciwgJmxkcXVvO0Fzc2VydGlvbnMgYW5kIFByb3RvY29sIGZv ciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAgICAgICAgICAg ICAoU0FNTCkgVjIuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+IFtPQVNJUy5zYW1sJiM4MjA5O2NvcmUmIzgyMDk7Mi4wJiM4MjA5O29zXQogIHByb3Zp ZGVzIGEgc3RhbmRhcmQgZm9yIGNyZWF0aW5nIHRva2VucyB3aXRoIG11Y2ggZ3JlYXRlcgogIGV4 cHJlc3Npdml0eSBhbmQgbW9yZSBzZWN1cml0eSBvcHRpb25zIHRoYW4gc3VwcG9ydGVkIGJ5CiAg SldUcy4gSG93ZXZlciwgdGhlIGNvc3Qgb2YgdGhpcyBmbGV4aWJpbGl0eSBhbmQgZXhwcmVzc2l2 ZW5lc3MKICBpcyBib3RoIHNpemUgYW5kIGNvbXBsZXhpdHkuIEluIGFkZGl0aW9uLCBTQU1MJ3Mg dXNlIG9mIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVzNDLkNSLXhtbDExLTIwMDIxMDE1Jz5YTUw8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q293YW4sIEouLCAmbGRxdW87RXh0ZW5z aWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4xLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIwMDIu PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbVzNDLkNSJiM4MjA5O3htbDExJiM4MjA5OzIwMDIx MDE1XSBhbmQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMjc1Jz5YTUwgRFNJRzxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FYXN0bGFrZSwgRC4sIFJlYWdsZSwgSi4sIGFuZCBE LiBTb2xvLCAmbGRxdW87KEV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlKSBYTUwtU2lnbmF0dXJl IFN5bnRheCBhbmQgUHJvY2Vzc2luZywmcmRxdW87IE1hcmNoJm5ic3A7MjAwMi48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+IFtSRkMzMjc1XSBvbmx5IGNvbnRyaWJ1dGVzIHRvIHRoZSBzaXplIG9m CiAgU0FNTCB0b2tlbnMuCjwvcD4KPHA+SldUcyBhcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIHNp bXBsZSB0b2tlbiBmb3JtYXQKICB0aGF0IGlzIHNtYWxsIGVub3VnaCB0byBmaXQgaW50byBIVFRQ IGhlYWRlcnMgYW5kIHF1ZXJ5IGFyZ3VtZW50cyBpbgogIFVSSXMuIEl0IGRvZXMgdGhpcyBieSBz dXBwb3J0aW5nIGEgbXVjaCBzaW1wbGVyIHRva2VuIG1vZGVsIHRoYW4KICBTQU1MIGFuZCB1c2lu ZyB0aGUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjI3Jz5KU09OPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkNyb2NrZm9yZCwgRC4sICZsZHF1bztUaGUgYXBwbGljYXRpb24v anNvbiBNZWRpYSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTiksJnJk cXVvOyBKdWx5Jm5ic3A7MjAwNi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM0NjI3XSBv YmplY3QgZW5jb2RpbmcKICBzeW50YXguIEl0IGFsc28gc3VwcG9ydHMgc2VjdXJpbmcgdG9rZW5z IHVzaW5nIEhhc2gtYmFzZWQgTWVzc2FnZQogIEF1dGhlbnRpY2F0aW9uIENvZGVzIChITUFDcykg YW5kIGRpZ2l0YWwgc2lnbmF0dXJlcyB1c2luZyBhIHNtYWxsZXIgKGFuZAogIGxlc3MgZmxleGli bGUpIGZvcm1hdCB0aGFuIFhNTCBEU0lHLgo8L3A+CjxwPlRoZXJlZm9yZSwgd2hpbGUgSldUcyBj YW4gZG8gc29tZSBvZiB0aGUgdGhpbmdzIFNBTUwgdG9rZW5zCiAgZG8sIEpXVHMgYXJlIG5vdCBp bnRlbmRlZCBhcyBhIGZ1bGwgcmVwbGFjZW1lbnQgZm9yIFNBTUwgdG9rZW5zLCBidXQKICByYXRo ZXIgYXMgYSBjb21wcm9taXNlIHRva2VuIGZvcm1hdCB0byBiZSB1c2VkIHdoZW4gc3BhY2UgaXMg YXQgYQogIHByZW1pdW0uCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjIiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4xNiI+PC9hPjxoMz4xNi4mbmJzcDsKQXBwZW5kaXggLSBOb24tTm9ybWF0aXZl IC0gUmVsYXRpb25zaGlwIG9mIEpXVHMgdG8gU2ltcGxlIFdlYiBUb2tlbnMgKFNXVHMpPC9oMz4K CjxwPkJvdGggSldUcyBhbmQgU2ltcGxlIFdlYiBUb2tlbnMgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNTV1QnPlNXVDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYXJkdCwgRC4gYW5k IFkuIEdvbGFuZCwgJmxkcXVvO1NpbXBsZSBXZWIgVG9rZW4gKFNXVCksJnJkcXVvOyBOb3ZlbWJl ciZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbU1dUXSwgYXQgdGhlaXIgY29y ZSwgZW5hYmxlIHNldHMgb2YgY2xhaW1zIHRvCiAgYmUgY29tbXVuaWNhdGVkIGJldHdlZW4gYXBw bGljYXRpb25zLiAgRm9yIFNXVHMsIGJvdGggdGhlIGNsYWltCiAgbmFtZXMgYW5kIGNsYWltIHZh bHVlcyBhcmUgc3RyaW5ncy4gIEZvciBKV1RzLCB3aGlsZQogIGNsYWltIG5hbWVzIGFyZSBzdHJp bmdzLCBjbGFpbSB2YWx1ZXMgY2FuIGJlIGFueSBKU09OIHR5cGUuCiAgQm90aCB0b2tlbiB0eXBl cyBvZmZlciBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb24gb2YgdGhlaXIKICBjb250ZW50OiBTV1Rz IHdpdGggSE1BQyBTSEEtMjU2IGFuZCBKV1RzIHdpdGggYSBjaG9pY2Ugb2YKICBhbGdvcml0aG1z LCBpbmNsdWRpbmcgSE1BQyBTSEEtMjU2LCBSU0EgU0hBLTI1NiwgYW5kIEVDRFNBIFAtMjU2CiAg U0hBLTI1Ni4KPC9wPgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlcyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjE3Ij48L2E+PGgzPjE3LiZuYnNwOwpSZWZlcmVuY2VzPC9oMz4KCjxhIG5hbWU9 InJmYy5yZWZlcmVuY2VzMSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxoMz4xNy4xLiZuYnNwO05vcm1hdGl2ZSBSZWZlcmVu Y2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iRklQUy4xODAtMyI+W0ZJUFMuMTgwLTNd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBT dGFuZGFyZHMgYW5kCiAgICAgICAgICAgIFRlY2hub2xvZ3ksICZsZHF1bzs8YSBocmVmPSJodHRw Oi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvZmlwcy9maXBzMTgwLTMvZmlwczE4MC0zX2Zp bmFsLnBkZiI+U2VjdXJlIEhhc2ggU3RhbmRhcmQgKFNIUyk8L2E+LCZyZHF1bzsgRklQUyZuYnNw O1BVQiAxODAtMywgT2N0b2JlciZuYnNwOzIwMDguPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkZJUFMuMTg2LTMiPltGSVBTLjE4Ni0z XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5OYXRpb25hbCBJbnN0aXR1dGUgb2Yg U3RhbmRhcmRzIGFuZAogICAgICAgICAgICBUZWNobm9sb2d5LCAmbGRxdW87PGEgaHJlZj0iaHR0 cDovL2NzcmMubmlzdC5nb3YvcHVibGljYXRpb25zL2ZpcHMvZmlwczE4Ni0zL2ZpcHNfMTg2LTMu cGRmIj5EaWdpdGFsIFNpZ25hdHVyZSBTdGFuZGFyZCAoRFNTKTwvYT4sJnJkcXVvOyBGSVBTJm5i c3A7UFVCIDE4Ni0zLCBKdW5lJm5ic3A7MjAwOS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjA0NSI+W1JGQzIwNDVdPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpuZWRAaW5ub3NvZnQu Y29tIj5GcmVlZCwgTi48L2E+IGFuZCA8YSBocmVmPSJtYWlsdG86bnNiQG5zYi5mdi5jb20iPk4u IEJvcmVuc3RlaW48L2E+LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjMjA0NSI+TXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5zaW9ucyAoTUlNRSkg UGFydCBPbmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNzYWdlIEJvZGllczwvYT4sJnJkcXVvOyBS RkMmbmJzcDsyMDQ1LCBOb3ZlbWJlciZuYnNwOzE5OTYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvcmZjL3JmYzIwNDUudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQg Y2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjEwNCI+W1JGQzIx MDRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpodWdv QHdhdHNvbi5pYm0uY29tIj5LcmF3Y3p5aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWloaXJA Y3MudWNzZC5lZHUiPkJlbGxhcmUsIE0uPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzpjYW5ldHRp QHdhdHNvbi5pYm0uY29tIj5SLiBDYW5ldHRpPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzIxMDQiPkhNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3Nh Z2UgQXV0aGVudGljYXRpb248L2E+LCZyZHF1bzsgUkZDJm5ic3A7MjEwNCwgRmVicnVhcnkmbmJz cDsxOTk3ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTA0LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzIxMTkiPltSRkMyMTE5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86c29iQGhhcnZhcmQuZWR1Ij5CcmFkbmVyLCBTLjwv YT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMTE5Ij5L ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVsczwv YT4sJnJkcXVvOyBCQ1AmbmJzcDsxNCwgUkZDJm5ic3A7MjExOSwgTWFyY2gmbmJzcDsxOTk3ICg8 YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTE5LnR4dCI+VFhUPC9h PiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIx MTkuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMveG1sL3JmYzIxMTkueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzMzOSI+W1JGQzMzMzldPC9h PjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpHS0BBQ00uT1JH Ij5LbHluZSwgRy4sIEVkLjwvYT4gYW5kIDxhIGhyZWY9Im1haWx0bzpjaHJpcy5uZXdtYW5Ac3Vu LmNvbSI+Qy4gTmV3bWFuPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzMzMzkiPkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0OiBUaW1lc3RhbXBz PC9hPiwmcmRxdW87IFJGQyZuYnNwOzMzMzksIEp1bHkmbmJzcDsyMDAyICg8YSBocmVmPSJodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzMzM5LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0i aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzMzMzkuaHRtbCI+SFRN TDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3Jm YzMzMzkueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzQ0NyI+W1JGQzM0NDddPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPkpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCAmbGRxdW87PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzQ0NyI+UHVibGljLUtleSBDcnlw dG9ncmFwaHkgU3RhbmRhcmRzIChQS0NTKSAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0 aW9ucyBWZXJzaW9uIDIuMTwvYT4sJnJkcXVvOyBSRkMmbmJzcDszNDQ3LCBGZWJydWFyeSZuYnNw OzIwMDMgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzM0NDcudHh0 Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249 InRvcCI+PGEgbmFtZT0iUkZDMzYyOSI+W1JGQzM2MjldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPlllcmdlYXUsIEYuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzYyOSI+VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAx MDY0NjwvYT4sJnJkcXVvOyBTVEQmbmJzcDs2MywgUkZDJm5ic3A7MzYyOSwgTm92ZW1iZXImbmJz cDsyMDAzICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzNjI5LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzM5ODYiPltSRkMzOTg2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86dGltYmxAdzMub3JnIj5CZXJuZXJzLUxlZSwgVC48 L2E+LCA8YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAZ2Jpdi5jb20iPkZpZWxkaW5nLCBSLjwvYT4s IGFuZCA8YSBocmVmPSJtYWlsdG86TE1NQGFjbS5vcmciPkwuIE1hc2ludGVyPC9hPiwgJmxkcXVv OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5ODYiPlVuaWZvcm0gUmVz b3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXg8L2E+LCZyZHF1bzsgU1REJm5i c3A7NjYsIFJGQyZuYnNwOzM5ODYsIEphbnVhcnkmbmJzcDsyMDA1ICg8YSBocmVmPSJodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzOTg2LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzM5ODYuaHRtbCI+SFRNTDwv YT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzM5 ODYueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDYyNyI+W1JGQzQ2MjddPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkNyb2NrZm9yZCwgRC4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjI3Ij5UaGUgYXBwbGljYXRpb24vanNvbiBNZWRpYSBUeXBl IGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTik8L2E+LCZyZHF1bzsgUkZDJm5i c3A7NDYyNywgSnVseSZuYnNwOzIwMDYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzQ2MjcudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDY0OCI+W1JGQzQ2NDhdPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvc2Vmc3NvbiwgUy4sICZsZHF1bzs8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4Ij5UaGUgQmFzZTE2LCBCYXNlMzIs IGFuZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3M8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NDY0OCwgT2N0 b2JlciZuYnNwOzIwMDYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm YzQ2NDgudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTIyNiI+W1JGQzUyMjZdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPk5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bzs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjI2Ij5HdWlkZWxpbmVzIGZv ciBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzPC9hPiwmcmRx dW87IEJDUCZuYnNwOzI2LCBSRkMmbmJzcDs1MjI2LCBNYXkmbmJzcDsyMDA4ICg8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjI2LnR4dCI+VFhUPC9hPikuPC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlVT QTE1Ij5bVVNBMTVdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1h aWx0bzptYXJrZGF2aXNAZ29vZ2xlLmNvbSI+RGF2aXMsIE0uPC9hPiwgPGEgaHJlZj0ibWFpbHRv OmtlbkB1bmljb2RlLm9yZyI+V2hpc3RsZXIsIEsuPC9hPiwgYW5kIE0uIEQmdXVtbDtyc3QsICZs ZHF1bztVbmljb2RlIE5vcm1hbGl6YXRpb24gRm9ybXMsJnJkcXVvOyBVbmljb2RlIFN0YW5kYXJk IEFubmV4Jm5ic3A7MTUsIDA5Jm5ic3A7MjAwOS48L3RkPjwvdHI+CjwvdGFibGU+Cgo8YSBuYW1l PSJyZmMucmVmZXJlbmNlczIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+MTcuMi4mbmJzcDtJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iQ2FudmFzQXBwIj5bQ2FudmFzQXBw XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5GYWNlYm9vaywgJmxkcXVvOzxhIGhy ZWY9Imh0dHA6Ly9kZXZlbG9wZXJzLmZhY2Vib29rLmNvbS9kb2NzL2F1dGhlbnRpY2F0aW9uL2Nh bnZhcyI+Q2FudmFzIEFwcGxpY2F0aW9uczwvYT4sJnJkcXVvOyAyMDEwLjwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJKU1MiPltKU1Nd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkJyYWRsZXksIEouIGFuZCBOLiBTYWtp bXVyYSAoZWRpdG9yKSwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly9qc29uZW5jLmluZm8vanNzLzEu MC8iPkpTT04gU2ltcGxlIFNpZ248L2E+LCZyZHF1bzsgU2VwdGVtYmVyJm5ic3A7MjAxMC48L3Rk PjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0i TWFnaWNTaWduYXR1cmVzIj5bTWFnaWNTaWduYXR1cmVzXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5QYW56ZXIgKGVkaXRvciksIEouLCBMYXVyaWUsIEIuLCBhbmQgRC4gQmFsZmFu eiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly9zYWxtb24tcHJvdG9jb2wuZ29vZ2xlY29kZS5jb20v c3ZuL3RydW5rL2RyYWZ0LXBhbnplci1tYWdpY3NpZy1leHBlcmltZW50YWwtMDAuaHRtbCI+TWFn aWMgU2lnbmF0dXJlczwvYT4sJnJkcXVvOyBBdWd1c3QmbmJzcDsyMDEwLjwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJPQVNJUy5zYW1s LWNvcmUtMi4wLW9zIj5bT0FTSVMuc2FtbC1jb3JlLTIuMC1vc108L2E+PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+PGEgaHJlZj0ibWFpbHRvOmNhbnRvci4yQG9zdS5lZHUiPkNhbnRvciwg Uy48L2E+LCA8YSBocmVmPSJtYWlsdG86Sm9obi5LZW1wQG5va2lhLmNvbSI+S2VtcCwgSi48L2E+ LCA8YSBocmVmPSJtYWlsdG86cnBoaWxwb3R0QHJzYXNlY3VyaXR5LmNvbSI+UGhpbHBvdHQsIFIu PC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzpldmUubWFsZXJAc3VuLmNvbSI+RS4gTWFsZXI8L2E+ LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvc2VjdXJpdHkvc2Ft bC92Mi4wL3NhbWwtY29yZS0yLjAtb3MucGRmIj5Bc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3Ig dGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3VhZ2UKICAgICAgICAgICAg KFNBTUwpIFYyLjA8L2E+LCZyZHF1bzsgT0FTSVMgU3RhbmRhcmQmbmJzcDtzYW1sLWNvcmUtMi4w LW9zLCBNYXJjaCZuYnNwOzIwMDUuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4 dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzMyNzUiPltSRkMzMjc1XTwvYT48L3RkPgo8dGQg Y2xhc3M9ImF1dGhvci10ZXh0Ij5FYXN0bGFrZSwgRC4sIFJlYWdsZSwgSi4sIGFuZCBELiBTb2xv LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzI3NSI+KEV4 dGVuc2libGUgTWFya3VwIExhbmd1YWdlKSBYTUwtU2lnbmF0dXJlIFN5bnRheCBhbmQgUHJvY2Vz c2luZzwvYT4sJnJkcXVvOyBSRkMmbmJzcDszMjc1LCBNYXJjaCZuYnNwOzIwMDIgKDxhIGhyZWY9 Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzMyNzUudHh0Ij5UWFQ8L2E+KS48L3Rk PjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0i UkZDNDEyMiI+W1JGQzQxMjJdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhy ZWY9Im1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgPGEgaHJlZj0i bWFpbHRvOm1pY2hhZWxAcmVmYWN0b3JlZC1uZXR3b3Jrcy5jb20iPk1lYWxsaW5nLCBNLjwvYT4s IGFuZCA8YSBocmVmPSJtYWlsdG86cnNhbHpAZGF0YXBvd2VyLmNvbSI+Ui4gU2FsejwvYT4sICZs ZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTIyIj5BIFVuaXZl cnNhbGx5IFVuaXF1ZSBJRGVudGlmaWVyIChVVUlEKSBVUk4gTmFtZXNwYWNlPC9hPiwmcmRxdW87 IFJGQyZuYnNwOzQxMjIsIEp1bHkmbmJzcDsyMDA1ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL3JmYy9yZmM0MTIyLnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzQxMjIuaHRtbCI+SFRNTDwvYT4sIDxhIGhy ZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzQxMjIueG1sIj5Y TUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRv cCI+PGEgbmFtZT0iU1dUIj5bU1dUXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5I YXJkdCwgRC4gYW5kIFkuIEdvbGFuZCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly9vYXV0aC13cmFw LXdnLmdvb2dsZWdyb3Vwcy5jb20vd2ViL1NXVC12MC45LjUuMS5wZGY/Z2RhPVNuNE1zRU1BQUFC RkI3UEZBRmlWZWRQdGpjcVQ4dXVJSW1IWFVrc05VS01YTHlyU3VtQXNfZEYydHpsUTMzUmhUMXdX OEJGWU8xUXl0aUotSGRHWVljUGlfMDlwbDhON0ZXTHZlT2FXanpiWW5wbmtwbXhjV2ciPlNpbXBs ZSBXZWIgVG9rZW4gKFNXVCk8L2E+LCZyZHF1bzsgVmVyc2lvbiZuYnNwOzAuOS41LjEsIE5vdmVt YmVyJm5ic3A7MjAwOS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxp Z249InRvcCI+PGEgbmFtZT0iVzNDLkNSLXhtbDExLTIwMDIxMDE1Ij5bVzNDLkNSLXhtbDExLTIw MDIxMDE1XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Db3dhbiwgSi4sICZsZHF1 bzs8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9UUi8yMDAyL0NSLXhtbDExLTIwMDIxMDE1Ij5F eHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAoWE1MKSAxLjE8L2E+LCZyZHF1bzsgVzNDIENSJm5i c3A7Q1IteG1sMTEtMjAwMjEwMTUsIE9jdG9iZXImbmJzcDsyMDAyLjwvdGQ+PC90cj4KPC90YWJs ZT4KCjxhIG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPkF1dGhvcnMnIEFkZHJlc3Nlczwv aDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij5NaWNoYWVsIEIuIEpvbmVzIChFZGl0b3IpPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+TWljcm9zb2Z0PC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3Rk Pjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5EaXJrIEJhbGZhbno8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5Hb29nbGU8L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRk PiZuYnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+ Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvaG4gQnJhZGxleTwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPmlu ZGVwZW5kZW50PC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0 ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5ZYXJvbiBZLiBHb2xhbmQ8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+ PHRkPiZuYnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvaG4gUGFuemVyPC90ZD48L3RyPgo8dHI+PHRk IGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ R29vZ2xlPC90ZD48L3RyPgo8dHIgY2VsbHBhZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0ZD4m bmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5OYXQgU2FraW11cmE8L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Ob211 cmEgUmVzZWFyY2ggSW5zdGl0dXRlPC90ZD48L3RyPgo8L3RhYmxlPgo8L2JvZHk+PC9odG1sPgoK --_005_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_ Content-Type: text/xml; name="draft-jones-json-web-token-00.xml" Content-Description: draft-jones-json-web-token-00.xml Content-Disposition: attachment; filename="draft-jones-json-web-token-00.xml"; size=67293; creation-date="Mon, 25 Oct 2010 23:30:01 GMT"; modification-date="Mon, 25 Oct 2010 21:04:28 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPCEtLSBlZGl0ZWQgd2l0 aCBYTUxTcHkgdjIwMTAgcmVsLiAzIHNwMSAoeDY0KSAoaHR0cDovL3d3dy5hbHRvdmEuY29tKSBi eSBZYXJvbiBZLiBHb2xhbmQgKE1pY3Jvc29mdCkgLS0+CjwhRE9DVFlQRSByZmMgU1lTVEVNICJy ZmMyNjI5LmR0ZCIgWwo8IUVOVElUWSByZmMyMTE5IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTE5LnhtbCI+CjwhRU5U SVRZIE9BU0lTLnNhbWwtY29yZS0yLjAtb3MgUFVCTElDICIiICJodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbDIvcmVmZXJlbmNlLk9BU0lTLnNhbWwtY29yZS0yLjAtb3Mu eG1sIj4KPCFFTlRJVFkgVzNDLkNSLXhtbDExLTIwMDIxMDE1IFBVQkxJQyAiIiAiaHR0cDovL3ht bC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWw0L3JlZmVyZW5jZS5XM0MuQ1IteG1sMTEt MjAwMjEwMTUueG1sIj4KPCFFTlRJVFkgUkZDMjA0NSBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjA0NS54bWwiPgo8IUVO VElUWSBSRkMyMTA0IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTA0LnhtbCI+CjwhRU5USVRZIFJGQzMyNzUgUFVCTElD ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjMyNzUueG1sIj4KPCFFTlRJVFkgUkZDMzMzOSBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMzMzOS54bWwiPgo8IUVO VElUWSBSRkMzNDQ3IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4zNDQ3LnhtbCI+CjwhRU5USVRZIFJGQzM2MjkgUFVCTElD ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjM2MjkueG1sIj4KPCFFTlRJVFkgUkZDMzk4NiBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMzk4Ni54bWwiPgo8IUVO VElUWSBSRkM0MTIyIFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40MTIyLnhtbCI+CjwhRU5USVRZIFJGQzQ2MjcgUFVCTElD ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjQ2MjcueG1sIj4KPCFFTlRJVFkgUkZDNDY0OCBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNDY0OC54bWwiPgo8IUVO VElUWSBSRkM1MjI2IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41MjI2LnhtbCI+Cl0+Cjw/cmZjIHRvYz0ieWVzIj8+Cjw/ cmZjIHRvY29tcGFjdD0ieWVzIj8+Cjw/cmZjIHRvY2RlcHRoPSIzIj8+Cjw/cmZjIHRvY2luZGVu dD0ieWVzIj8+Cjw/cmZjIHN5bXJlZnM9InllcyI/Pgo8P3JmYyBzb3J0cmVmcz0ieWVzIj8+Cjw/ cmZjIGNvbW1lbnRzPSJ5ZXMiPz4KPD9yZmMgaW5saW5lPSJ5ZXMiPz4KPD9yZmMgY29tcGFjdD0i eWVzIj8+Cjw/cmZjIHN1YmNvbXBhY3Q9Im5vIj8+CjxyZmMgY2F0ZWdvcnk9InN0ZCIgZG9jTmFt ZT0iZHJhZnQtam9uZXMtanNvbi13ZWItdG9rZW4tMDAiCiAgICAgaXByPSJ0cnVzdDIwMDkwMiI+ CiAgPGZyb250PgogICAgPHRpdGxlPkpTT04gV2ViIFRva2VuIChKV1QpPC90aXRsZT4KCiAgICA8 YXV0aG9yIGZ1bGxuYW1lPSJNaWNoYWVsIEIuIEpvbmVzIChFZGl0b3IpIiBpbml0aWFscz0iTS5C LiIgc3VybmFtZT0iSm9uZXMgKGVkaXRvcikiPgogICAgICA8b3JnYW5pemF0aW9uPk1pY3Jvc29m dDwvb3JnYW5pemF0aW9uPgogICAgPC9hdXRob3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iRGly ayBCYWxmYW56IiBpbml0aWFscz0iRC4gIiBzdXJuYW1lPSJCYWxmYW56Ij4KICAgICAgPG9yZ2Fu aXphdGlvbj5Hb29nbGU8L29yZ2FuaXphdGlvbj4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3Ig ZnVsbG5hbWU9IkpvaG4gQnJhZGxleSIgaW5pdGlhbHM9IkouIiBzdXJuYW1lPSJCcmFkbGV5Ij4K ICAgICAgPG9yZ2FuaXphdGlvbj5pbmRlcGVuZGVudDwvb3JnYW5pemF0aW9uPgogICAgPC9hdXRo b3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iWWFyb24gWS4gR29sYW5kIiBpbml0aWFscz0iWS5Z LiIgc3VybmFtZT0iR29sYW5kIj4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2Fu aXphdGlvbj4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9IkpvaG4gUGFuemVy IiBpbml0aWFscz0iSi4gIiBzdXJuYW1lPSJQYW56ZXIiPgogICAgICA8b3JnYW5pemF0aW9uPkdv b2dsZTwvb3JnYW5pemF0aW9uPgogICAgPC9hdXRob3I+CgogICAgPGF1dGhvciBmdWxsbmFtZT0i TmF0IFNha2ltdXJhIiBpbml0aWFscz0iTi4gIiBzdXJuYW1lPSJTYWtpbXVyYSI+CiAgICAgIDxv cmdhbml6YXRpb24+Tm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZTwvb3JnYW5pemF0aW9uPgogICAg PC9hdXRob3I+CgogICAgPGRhdGUgZGF5PSIyNSIgbW9udGg9Ik9jdG9iZXIiIHllYXI9IjIwMTAi IC8+CgogICAgPGFyZWE+QXBwbGljYXRpb25zPC9hcmVhPgoKICAgIDxrZXl3b3JkPlJGQzwva2V5 d29yZD4KCiAgICA8a2V5d29yZD5SZXF1ZXN0IGZvciBDb21tZW50czwva2V5d29yZD4KCiAgICA8 a2V5d29yZD5JLUQ8L2tleXdvcmQ+CgogICAgPGtleXdvcmQ+SW50ZXJuZXQtRHJhZnQ8L2tleXdv cmQ+CgogICAgPGtleXdvcmQ+QXNzZXJ0aW9uPC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPkNsYWlt PC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPlNpbXBsZSBXZWIgVG9rZW48L2tleXdvcmQ+CgogICAg PGtleXdvcmQ+U2VjdXJpdHkgVG9rZW48L2tleXdvcmQ+CgogICAgPGtleXdvcmQ+U1dUPC9rZXl3 b3JkPgoKICAgIDxrZXl3b3JkPkpTT04gV2ViIFRva2VuPC9rZXl3b3JkPgoKICAgIDxrZXl3b3Jk PkpXVDwva2V5d29yZD4KCiAgICA8a2V5d29yZD5KYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbjwv a2V5d29yZD4KCiAgICA8a2V5d29yZD5KU09OPC9rZXl3b3JkPgoKICAgIDxhYnN0cmFjdD4KICAg ICAgPHQ+SlNPTiBXZWIgVG9rZW4gKEpXVCkgZGVmaW5lcyBhIHRva2VuIGZvcm1hdCB0aGF0IGNh biBlbmNvZGUKICAgICAgY2xhaW1zIHRyYW5zZmVycmVkIGJldHdlZW4gdHdvIHBhcnRpZXMuIFRo ZSBjbGFpbXMgaW4gYSBKV1QgYXJlCiAgICAgIGVuY29kZWQgYXMgYSBKU09OIG9iamVjdCB0aGF0 IGlzIGRpZ2l0YWxseSBzaWduZWQuPC90PgogICAgPC9hYnN0cmFjdD4KCiAgICA8bm90ZSB0aXRs ZT0iUmVxdWlyZW1lbnRzIExhbmd1YWdlIj4KICAgICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAgICAiU0hP VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIDx4cmVmCiAgICAgIHRhcmdldD0iUkZDMjExOSI+UkZDIDIxMTk8L3hyZWY+LjwvdD4KICAg IDwvbm90ZT4KICA8L2Zyb250PgoKICA8bWlkZGxlPgogICAgPHNlY3Rpb24gdGl0bGU9IkludHJv ZHVjdGlvbiI+CiAgICAgIDx0PkpTT04gV2ViIFRva2VuIChKV1QpIGlzIGEgc2ltcGxlIHRva2Vu IGZvcm1hdCBpbnRlbmRlZCBmb3IKICAgICAgc3BhY2UgY29uc3RyYWluZWQgZW52aXJvbm1lbnRz IHN1Y2ggYXMgSFRUUCBBdXRob3JpemF0aW9uCiAgICAgIGhlYWRlcnMgYW5kIFVSSSBxdWVyeSBw YXJhbWV0ZXJzLiBKV1RzIGVuY29kZSB0aGUgY2xhaW1zIHRvIGJlCiAgICAgIHRyYW5zbWl0dGVk IGFzIGEgSlNPTiBvYmplY3QgKGFzIGRlZmluZWQgaW4gPHhyZWYKICAgICAgdGFyZ2V0PSJSRkM0 NjI3Ij5SRkMgNDYyNzwveHJlZj4pIHRoYXQgaXMgYmFzZTY0dXJsIGVuY29kZWQgYW5kCiAgICAg IGRpZ2l0YWxseSBzaWduZWQuPC90PgoKICAgICA8dD5UaGUgc3VnZ2VzdGVkIHByb251bmNpYXRp b24gb2YgSldUIGlzIHRoZSBzYW1lIGFzIHRoZSBFbmdsaXNoIHdvcmQgImpvdCIuPC90PgogICAg PC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJUZXJtaW5vbG9neSI+CiAgICAgIDx0Pjxs aXN0IHN0eWxlPSJoYW5naW5nIj4KCiAgICAgICAgICA8dCBoYW5nVGV4dD0iSlNPTiBXZWIgVG9r ZW4gKEpXVCkiPkEgc3RyaW5nIGNvbnNpc3Rpbmcgb2YKICAgICAgICAgIHRocmVlIEpXVCBUb2tl biBTZWdtZW50czogdGhlIEpXVCBFbnZlbG9wZSBTZWdtZW50LCB0aGUgSldUCiAgICAgICAgICBD bGFpbSBTZWdtZW50LCBhbmQgdGhlIEpXVCBDcnlwdG8gU2VnbWVudCwgaW4gdGhhdCBvcmRlciwK ICAgICAgICAgIHdpdGggdGhlIHNlZ21lbnRzIGJlaW5nIHNlcGFyYXRlZCBieSBwZXJpb2QgKCcu JykKICAgICAgICAgIGNoYXJhY3RlcnMuPC90PgoKICAgICAgICAgIDx0IGhhbmdUZXh0PSJKV1Qg VG9rZW4gU2VnbWVudCI+T25lIG9mIHRoZSB0aHJlZSBwYXJ0cyB0aGF0CiAgICAgICAgICBtYWtl IHVwIGEgSlNPTiBXZWIgVG9rZW4gKEpXVCkuICBKV1QgVG9rZW4gU2VnbWVudHMgYXJlCiAgICAg ICAgICBhbHdheXMgYmFzZTY0dXJsIGVuY29kZWQgdmFsdWVzLjwvdD4KCiAgICAgICAgICA8dCBo YW5nVGV4dD0iSldUIEVudmVsb3BlIFNlZ21lbnQiPkEgSldUIFRva2VuIFNlZ21lbnQKICAgICAg ICAgIGNvbnRhaW5pbmcgYSBiYXNlNjR1cmwgZW5jb2RlZCBKU09OIG9iamVjdCB0aGF0IGRlc2Ny aWJlcwogICAgICAgICAgdGhlIHNpZ25hdHVyZSBhcHBsaWVkIHRvIHRoZSBKV1QgQ2xhaW0gU2Vn bWVudC48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkpXVCBDbGFpbSBTZWdtZW50Ij5BIEpX VCBUb2tlbiBTZWdtZW50CiAgICAgICAgICBjb250YWluaW5nIGEgYmFzZTY0dXJsIGVuY29kZWQg SlNPTiBvYmplY3QgdGhhdCBlbmNvZGVzIHRoZQogICAgICAgICAgY2xhaW1zIHJlcHJlc2VudGVk IGJ5IHRoZSBKV1QuPC90PgoKICAgICAgICAgIDx0IGhhbmdUZXh0PSJKV1QgQ3J5cHRvIFNlZ21l bnQiPkEgSldUIFRva2VuIFNlZ21lbnQKICAgICAgICAgIGNvbnRhaW5pbmcgYmFzZTY0dXJsIGVu Y29kZWQgY3J5cHRvZ3JhcGhpYyBzaWduYXR1cmUKICAgICAgICAgIG1hdGVyaWFsIHRoYXQgc2Vj dXJlcyB0aGUgSldUIENyeXB0byBTZWdtZW50J3MgY29udGVudHMuPC90PgoKICAgICAgICAgIDx0 IGhhbmdUZXh0PSJEZWNvZGVkIEpXVCBFbnZlbG9wZSBTZWdtZW50Ij5BIEpXVCBFbnZlbG9wZSBT ZWdtZW50IHRoYXQKICAgICAgICAgIGhhcyBiZWVuIGJhc2U2NHVybCBkZWNvZGVkIGJhY2sgaW50 byBhIEpTT04gb2JqZWN0LjwvdD4KCiAgICAgICAgICA8dCBoYW5nVGV4dD0iRGVjb2RlZCBKV1Qg Q2xhaW0gU2VnbWVudCI+QSBKV1QgQ2xhaW0gU2VnbWVudCB0aGF0CiAgICAgICAgICBoYXMgYmVl biBiYXNlNjR1cmwgZGVjb2RlZCBiYWNrIGludG8gYSBKU09OIG9iamVjdC48L3Q+CgogICAgICAg ICAgPHQgaGFuZ1RleHQ9IkRlY29kZWQgSldUIENyeXB0byBTZWdtZW50Ij5BIEpXVCBDcnlwdG8g U2VnbWVudCB0aGF0CiAgICAgICAgICBoYXMgYmVlbiBiYXNlNjR1cmwgZGVjb2RlZCBiYWNrIGlu dG8gY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbC48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkJh c2U2NHVybCBFbmNvZGluZyI+Rm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHNwZWNpZmljYXRpb24s IAogICAgICAgICAgdGhpcyB0ZXJtIGFsd2F5cyByZWZlcnMgdG8gdGhlIGhlIFVSTC0gYW5kIGZp bGVuYW1lLXNhZmUgQmFzZTY0CiAgICAgICAgICBlbmNvZGluZyBkZXNjcmliZWQgaW4gPHhyZWYg dGFyZ2V0PSJSRkM0NjQ4Ij5SRkMgNDY0ODwveHJlZj4sIFNlY3Rpb24gNSwKICAgICAgICAgIHdp dGggdGhlICc9JyBwYWRkaW5nIGNoYXJhY3RlcnMgb21pdHRlZCwgYXMgcGVybWl0dGVkIGJ5IFNl Y3Rpb24gMy4yOwogICAgICAgICAgc2VlIDx4cmVmIHRhcmdldD0iYmFzZTY0dXJsbG9naWMiPjwv eHJlZj4gZm9yIG1vcmUgZGV0YWlscy48L3Q+CgogICAgICAgIDwvbGlzdD48L3Q+CiAgICA8L3Nl Y3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkpTT04gV2ViIFRva2VuIChKV1QpIE92ZXJ2aWV3 Ij4KCiAgICAgIDx0PkpXVHMgcmVwcmVzZW50IGEgc2V0IG9mIGNsYWltcyBhcyBhIEpTT04gb2Jq ZWN0IHRoYXQgaXMKICAgICAgYmFzZTY0dXJsIGVuY29kZWQgYW5kIGRpZ2l0YWxseSBzaWduZWQu ICBBcyBwZXIgPHhyZWYKICAgICAgdGFyZ2V0PSJSRkM0NjI3Ij5SRkMgNDYyNzwveHJlZj4gU2Vj dGlvbiAyLjIsIHRoZSBKU09OIG9iamVjdAogICAgICBjb25zaXN0cyBvZiB6ZXJvIG9yIG1vcmUg bmFtZS92YWx1ZSBwYWlycyAob3IgbWVtYmVycyksIHdoZXJlCiAgICAgIHRoZSBuYW1lcyBhcmUg c3RyaW5ncyBhbmQgdGhlIHZhbHVlcyBhcmUgYXJiaXRyYXJ5IEpTT04gdmFsdWVzLgogICAgICBU aGVzZSBtZW1iZXJzIGFyZSB0aGUgY2xhaW1zIHJlcHJlc2VudGVkIGJ5IHRoZSBKV1QuICBUaGUg SlNPTgogICAgICBvYmplY3QgaXMgYmFzZTY0dXJsIGVuY29kZWQgdG8gcHJvZHVjZSB0aGUgSldU IENsYWltIFNlZ21lbnQuIEFuCiAgICAgIGFjY29tcGFueWluZyBiYXNlNjR1cmwgZW5jb2RlZCBK U09OIGVudmVsb3BlIG9iamVjdCBkZXNjcmliZXMKICAgICAgdGhlIHNpZ25hdHVyZSBtZXRob2Qg dXNlZC48L3Q+CgogICAgICA8dD5UaGUgbmFtZXMgd2l0aGluIHRoZSBvYmplY3QgTVVTVCBiZSB1 bmlxdWUuICBUaGUgbmFtZXMgd2l0aGluCiAgICAgIHRoZSBKU09OIG9iamVjdCBhcmUgcmVmZXJy ZWQgdG8gYXMgQ2xhaW0gTmFtZXMuICBUaGUKICAgICAgY29ycmVzcG9uZGluZyB2YWx1ZXMgYXJl IHJlZmVycmVkIHRvIGFzIENsYWltIFZhbHVlcy48L3Q+CgogICAgICA8dD5KV1RzIGNvbnRhaW4g YSBzaWduYXR1cmUgdGhhdCBlbnN1cmVzIHRoZSBpbnRlZ3JpdHkgb2YgdGhlCiAgICAgIGNvbnRl bnQgb2YgdGhlIEpTT04gQ2xhaW0gU2VnbWVudC4gIFRoaXMgc2lnbmF0dXJlIHZhbHVlIGlzCiAg ICAgIGNhcnJpZWQgaW4gdGhlIEpXVCBDcnlwdG8gU2VnbWVudC4gIFRoZSBKU09OIEVudmVsb3Bl IG9iamVjdAogICAgICBNVVNUIGNvbnRhaW4gYW4gImFsZyIgcGFyYW1ldGVyLCB0aGUgdmFsdWUg b2Ygd2hpY2ggaXMgYSBzdHJpbmcKICAgICAgdGhhdCB1bmFtYmlndW91c2x5IGlkZW50aWZpZXMg dGhlIGFsZ29yaXRobSB1c2VkIHRvIHNpZ24gdGhlIEpXVAogICAgICBDbGFpbSBTZWdtZW50IHRv IHByb2R1Y2UgdGhlIEpXVCBDcnlwdG8gU2VnbWVudC48L3Q+CgogICAgICA8c2VjdGlvbiB0aXRs ZT0iRXhhbXBsZSBKV1QiPgoKICAgICAgPHQ+VGhlIGZvbGxvd2luZyBpcyBhbiBleGFtcGxlIG9m IGEgSlNPTiBvYmplY3QgdGhhdCBjYW4gYmUKICAgICAgZW5jb2RlZCB0byBwcm9kdWNlIGEgSldU OjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW3siaXNzIjoiam9lIiwKICJleHAiOjEzMDA4 MTkzODAsCiAiaHR0cDovL2V4YW1wbGUuY29tL2lzX3Jvb3QiOnRydWV9XV0+PC9hcnR3b3JrPgoK ICAgICAgPHQ+QmFzZTY0dXJsIGVuY29kaW5nIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0 aGUgSlNPTgogICAgICBvYmplY3QgeWllbGRzIHRoaXMgSldUIENsYWltIFNlZ21lbnQgdmFsdWU6 PC90PgoKICAgICAgPGFydHdvcms+PCFbQ0RBVEFbZXlKcGMzTWlPaUpxYjJVaUxBMEtJQ0psZUhB aU9qRXpNREE0TVRrek9EQXNEUW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkw SWpwMGNuVmxmUV1dPjwvYXJ0d29yaz4KCiAgICAgIDx0PlRoZSBmb2xsb3dpbmcgZXhhbXBsZSBK U09OIGVudmVsb3BlIG9iamVjdCBkZWNsYXJlcyB0aGF0IHRoZQogICAgICBlbmNvZGVkIG9iamVj dCBpcyBhIEpTT04gV2ViIFRva2VuIChKV1QpIGFuZCB0aGUgSldUIENsYWltCiAgICAgIFNlZ21l bnQgaXMgc2lnbmVkIHVzaW5nIHRoZSBITUFDIFNIQS0yNTYgYWxnb3JpdGhtOjwvdD4KCiAgICAg IDxhcnR3b3JrPjwhW0NEQVRBW3sidHlwIjoiSldUIiwKICJhbGciOiJIUzI1NiJ9XV0+PC9hcnR3 b3JrPgoKICAgICAgPHQ+QmFzZTY0dXJsIGVuY29kaW5nIHRoZSBVVEYtOCByZXByZXNlbnRhdGlv biBvZiB0aGUgSlNPTiBlbnZlbG9wZQogICAgICBvYmplY3QgeWllbGRzIHRoaXMgSldUIEVudmVs b3BlIFNlZ21lbnQgdmFsdWU6PC90PgoKICAgICAgPGFydHdvcms+PCFbQ0RBVEFbZXlKMGVYQWlP aUpLVjFRaUxBMEtJQ0poYkdjaU9pSklVekkxTmlKOV1dPjwvYXJ0d29yaz4KCiAgICAgIDx0PlNp Z25pbmcgdGhlIEpXVCBDbGFpbSBTZWdtZW50IHdpdGggdGhlIEhNQUMgU0hBLTI1NiBhbGdvcml0 aG0KICAgICAgYW5kIGJhc2U2NHVybCBlbmNvZGluZyB0aGUgcmVzdWx0LCBhcyBwZXIgPHhyZWYK ICAgICAgdGFyZ2V0PSJTaWduaW5nV2l0aEhNQUNTSEEyNTYiPjwveHJlZj4sIHlpZWxkcyB0aGlz IEpXVCBDcnlwdG8gU2VnbWVudCB2YWx1ZTo8L3Q+CgogICAgICA8YXJ0d29yaz48IVtDREFUQVsz NXVzV2o5WDhId0dTLUNEY3gxSlAyTm1xY3JMd1o0RUtwOHNOVGhmM2NZXV0+PC9hcnR3b3JrPgoK ICAgICAgPHQ+Q29tYmluaW5nIHRoZXNlIHNlZ21lbnRzIGluIHRoZSBvcmRlcgogICAgICBFbnZl bG9wZS5DbGFpbXMuU2lnbmF0dXJlIHdpdGggcGVyaW9kIGNoYXJhY3RlcnMgYmV0d2VlbiB0aGUK ICAgICAgc2VnbWVudHMgeWllbGRzIHRoaXMgY29tcGxldGUgSldUICh3aXRoIGxpbmUgYnJlYWtz IGZvciBkaXNwbGF5CiAgICAgIHB1cnBvc2VzIG9ubHkpOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwh W0NEQVRBW2V5SjBlWEFpT2lKS1YxUWlMQTBLSUNKaGJHY2lPaUpJVXpJMU5pSjkKLgpleUpwYzNN aU9pSnFiMlVpTEEwS0lDSmxlSEFpT2pFek1EQTRNVGt6T0RBc0RRb2dJbWgwZEhBNkx5OWxlR0Z0 Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAwY25WbGZRCi4KMzV1c1dqOVg4SHdHUy1DRGN4MUpQMk5t cWNyTHdaNEVLcDhzTlRoZjNjWV1dPjwvYXJ0d29yaz4KCiAgICAgIDx0PlRoaXMgY29tcHV0YXRp b24gaXMgaWxsdXN0cmF0ZWQgaW4gbW9yZSBkZXRhaWwgaW4gPHhyZWYKICAgICAgdGFyZ2V0PSJI TUFDU0hBMjU2RXhhbXBsZSI+PC94cmVmPi48L3Q+CgogICAgICA8L3NlY3Rpb24+CiAgICA8L3Nl Y3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkpXVCBDbGFpbXMiPgoKICAgICAgPHQ+VGhlIG1l bWJlcnMgb2YgdGhlIEpTT04gb2JqZWN0IHJlcHJlc2VudGVkIGJ5IHRoZSBEZWNvZGVkIEpXVAog ICAgICBDbGFpbSBTZWdtZW50IGNvbnRhaW4gdGhlIGNsYWltcy4gTm90ZSBob3dldmVyLCB0aGF0 IHRoZSBzZXQgb2YKICAgICAgY2xhaW1zIGEgSldUIG11c3QgY29udGFpbiB0byBiZSBjb25zaWRl cmVkIHZhbGlkIGlzCiAgICAgIGNvbnRleHQtZGVwZW5kZW50IGFuZCBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzCiAgICAgIHNwZWNpZmljYXRpb24uPC90PgoKICAgICAgPHQ+VGhlcmUgYXJl IHRocmVlIGNsYXNzZXMgb2YgSldUIENsYWltIE5hbWVzOiAgUmVzZXJ2ZWQgQ2xhaW0gTmFtZXMs IFB1YmxpYyBDbGFpbSBOYW1lcywgYW5kIFByaXZhdGUgQ2xhaW0gTmFtZXMuPC90PgoKICAgICAg PHNlY3Rpb24gdGl0bGU9IlJlc2VydmVkIENsYWltIE5hbWVzIiBhbmNob3I9IlJlc2VydmVkQ2xh aW1OYW1lIj4KCTx0PlRoZSBmb2xsb3dpbmcgY2xhaW0gbmFtZXMgYXJlIHJlc2VydmVkLiBOb25l IG9mIHRoZSBjbGFpbXMKCWRlZmluZWQgaW4gdGhlIHRhYmxlIGJlbG93IGFyZSBpbnRlbmRlZCB0 byBiZSBtYW5kYXRvcnksIGJ1dAoJcmF0aGVyLCBwcm92aWRlIGEgc3RhcnRpbmcgcG9pbnQgZm9y IGEgc2V0IG9mIHVzZWZ1bCwKCWludGVyb3BlcmFibGUgY2xhaW1zLiAgQWxsIHRoZSBuYW1lcyBh cmUgc2hvcnQgYmVjYXVzZSBhIGNvcmUKCWdvYWwgb2YgSldUcyBpcyBmb3IgdGhlIHRva2VucyB0 aGVtc2VsdmVzIHRvIGJlIHNob3J0LjwvdD4KCgk8dGV4dHRhYmxlIHRpdGxlPSJSZXNlcnZlZCBD bGFpbSBEZWZpbml0aW9ucyIgYW5jaG9yPSJDbGFpbVRhYmxlIj4KCgkgIDx0dGNvbCBhbGlnbj0i bGVmdCI+Q2xhaW0gTmFtZTwvdHRjb2w+CgkgIDx0dGNvbCBhbGlnbj0ibGVmdCI+SlNPTiBWYWx1 ZSBUeXBlPC90dGNvbD4KCSAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5DbGFpbSBTeW50YXg8L3R0Y29s PgoJICA8dHRjb2wgYWxpZ249ImxlZnQiPkNsYWltIFNlbWFudGljczwvdHRjb2w+CgoJICA8Yz5l eHA8L2M+CgkgIDxjPmludGVnZXI8L2M+CgkgIDxjPkludERhdGU8L2M+CgkgIDxjPlRoZSAiZXhw IiAoZXhwaXJhdGlvbiB0aW1lKSBjbGFpbSBpZGVudGlmaWVzIHRoZQoJICBleHBpcmF0aW9uIHRp bWUgb24gb3IgYWZ0ZXIgd2hpY2ggdGhlIHRva2VuIE1VU1QgTk9UIGJlCgkgIGFjY2VwdGVkIGZv ciBwcm9jZXNzaW5nLiAgVGhlIHByb2Nlc3Npbmcgb2YgdGhlICJleHAiIGNsYWltCgkgIHJlcXVp cmVzIHRoYXQgdGhlIGN1cnJlbnQgZGF0ZS90aW1lIE1VU1QgYmUgYmVmb3JlIHRoZQoJICBleHBp cmF0aW9uIGRhdGUvdGltZSBsaXN0ZWQgaW4gdGhlICJleHAiIGNsYWltLiBJbXBsZW1lbnRlcnMK CSAgTUFZIHByb3ZpZGUgZm9yIHNvbWUgc21hbGwgbGVld2F5LCB1c3VhbGx5IG5vIG1vcmUgdGhh biBhCgkgIGZldyBtaW51dGVzLCB0byBhY2NvdW50IGZvciBjbG9jayBza2V3LiAgVGhpcyBjbGFp bSBpcwoJICBPUFRJT05BTC48L2M+CgoJICA8Yz5pc3M8L2M+CgkgIDxjPnN0cmluZzwvYz4KCSAg PGM+U3RyaW5nQW5kVVJJPC9jPgoJICA8Yz5UaGUgImlzcyIgKGlzc3VlcikgY2xhaW0gaWRlbnRp ZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQKCSAgaXNzdWVkIHRoZSBKV1QuICBUaGUgcHJvY2Vzc2lu ZyBvZiB0aGlzIGNsYWltIGlzIGdlbmVyYWxseQoJICBhcHBsaWNhdGlvbiBzcGVjaWZpYy4gIFRo aXMgY2xhaW0gaXMgT1BUSU9OQUwuPC9jPgoKCSAgPGM+YXVkPC9jPgoJICA8Yz5zdHJpbmc8L2M+ CgkgIDxjPlN0cmluZ0FuZFVSSTwvYz4KCSAgPGM+VGhlICJhdWQiIChhdWRpZW5jZSkgY2xhaW0g aWRlbnRpZmllcyB0aGUgYXVkaWVuY2UgdGhhdAoJICB0aGUgSldUIGlzIGludGVuZGVkIGZvci4g IFRoZSBwcm9jZXNzaW5nIG9mIHRoaXMgY2xhaW0KCSAgcmVxdWlyZXMgdGhhdCBpZiBhIEpXVCBj b25zdW1lciByZWNlaXZlcyBhIEpXVCB3aXRoIGFuICJhdWQiCgkgIHZhbHVlIHRoYXQgZG9lcyBu b3QgaWRlbnRpZnkgaXRzZWxmIGFzIHRoZSBKV1QgYXVkaWVuY2UsCgkgIHRoZW4gdGhlIEpXVCBN VVNUIGJlIHJlamVjdGVkLiAgVGhlIGludGVycHJldGF0aW9uIG9mIHRoZQoJICBhdWRpZW5jZSB2 YWx1ZSBpcyBnZW5lcmFsbHkgYXBwbGljYXRpb24gc3BlY2lmaWMuICBUaGlzCgkgIGNsYWltIGlz IE9QVElPTkFMLjwvYz4KCgkgIDxjPnR5cDwvYz4KCSAgPGM+c3RyaW5nPC9jPgoJICA8Yz5TdHJp bmdBbmRVUkk8L2M+CgkgIDxjPlRoZSAidHlwIiAodHlwZSkgY2xhaW0gaXMgdXNlZCB0byBkZWNs YXJlIGEgdHlwZSBmb3IgdGhlCgkgIGNvbnRlbnRzIHRoaXMgSldULiAgVGhlIHZhbHVlIE1BWSBi ZSBhIDx4cmVmCgkgIHRhcmdldD0iUkZDMjA0NSI+TUlNRTwveHJlZj4gdHlwZS4gIFRoaXMgY2xh aW0gaXMKCSAgT1BUSU9OQUwuPC9jPgoKCTwvdGV4dHRhYmxlPgoKCTx0PkFkZGl0aW9uYWwgcmVz ZXJ2ZWQgY2xhaW0gbmFtZXMgTUFZIGJlIGRlZmluZWQgdmlhIHRoZSBJQU5BCglKU09OIFdlYiBU b2tlbiBDbGFpbXMgcmVnaXN0cnksIGFzIHBlciA8eHJlZgoJdGFyZ2V0PSJJQU5BIj48L3hyZWY+ LiAgVGhlIHN5bnRheGVzIHJlZmVycmVkIHRvIGFib3ZlCglhcmU6PC90PgoKCTx0ZXh0dGFibGUg YW5jaG9yPSJTeW50YXhEZWZpbml0aW9ucyI+CgkgIDx0dGNvbCBhbGlnbj0ibGVmdCI+U3ludGF4 IE5hbWU8L3R0Y29sPgoJICA8dHRjb2wgYWxpZ249ImxlZnQiPlN5bnRheCBEZWZpbml0aW9uPC90 dGNvbD4KCgkgIDxjPlN0cmluZ0FuZFVSSTwvYz4KCSAgPGM+QW55IHN0cmluZyB2YWx1ZSBNQVkg YmUgdXNlZCBidXQgYSB2YWx1ZSBjb250YWluaW5nIGEgIjoiCgkgIGNoYXJhY3RlciBNVVNUIGJl IGEgVVJJIGFzIGRlZmluZWQgaW4gPHhyZWYKCSAgdGFyZ2V0PSJSRkMzOTg2Ij5SRkMgMzk4Njwv eHJlZj4uPC9jPgoKCSAgPGM+VVJJPC9jPgoJICA8Yz5BIFVSSSBhcyBkZWZpbmVkIGluIDx4cmVm IHRhcmdldD0iUkZDMzk4NiI+UkZDIDM5ODY8L3hyZWY+LjwvYz4KCgkgIDxjPkludERhdGU8L2M+ CgkgIDxjPlRoZSBudW1iZXIgb2Ygc2Vjb25kcyBmcm9tIDE5NzAtMDEtMDFUMDowOjBaIGFzIG1l YXN1cmVkCgkgIGluIFVUQyB1bnRpbCB0aGUgZGVzaXJlZCBkYXRlL3RpbWUuIFNlZSA8eHJlZgoJ ICB0YXJnZXQ9IlJGQzMzMzkiPlJGQyAzMzM5PC94cmVmPiBmb3IgZGV0YWlscyByZWdhcmRpbmcK CSAgZGF0ZS90aW1lcyBpbiBnZW5lcmFsIGFuZCBVVEMgaW4gcGFydGljdWxhci48L2M+Cgk8L3Rl eHR0YWJsZT4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJQdWJsaWMg Q2xhaW0gTmFtZXMiIGFuY2hvcj0iUHVibGljQ2xhaW1OYW1lIj4KCiAgICAgICAgPHQ+Q2xhaW0g bmFtZXMgY2FuIGJlIGRlZmluZWQgYXQgd2lsbCBieSB0aG9zZSB1c2luZwogICAgICAgIEpXVHMu IEhvd2V2ZXIsIGluIG9yZGVyIHRvIHByZXZlbnQgY29sbGlzaW9ucywgYW55IG5ldyBjbGFpbQog ICAgICAgIG5hbWUgU0hPVUxEIGVpdGhlciBiZSBkZWZpbmVkIGluIHRoZSBJQU5BCiAgICAgICAg SlNPTiBXZWIgVG9rZW4gQ2xhaW1zIHJlZ2lzdHJ5IG9yIGJlIGRlZmluZWQgYXMKICAgICAgICBh IFVSSSB0aGF0IGNvbnRhaW5zIGEgY29sbGlzaW9uIHJlc2lzdGFudCBuYW1lc3BhY2UuIEV4YW1w bGVzCiAgICAgICAgb2YgY29sbGlzaW9uIHJlc2lzdGFudCBuYW1lc3BhY2VzIGluY2x1ZGU6Cgog ICAgICAgICAgPGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgICA8dD5Eb21haW4gTmFt ZXMsPC90PgoKICAgICAgICAgICAgPHQ+T2JqZWN0IElkZW50aWZpZXJzIChPSURzKSBhcyBkZWZp bmVkIGluIHRoZSBJVFUtVCBYIDY2MCBhbmQgWAogICAgICAgICAgICA2NzAgUmVjb21tZW5kYXRp b24gc2VyaWVzIG9yPC90PgoKICAgICAgICAgICAgPHQ+VW5pdmVyc2FsbHkgVW5pcXVlIElEZW50 aWZpZXIgKFVVSUQpIGFzIGRlZmluZWQgaW4gPHhyZWYKICAgICAgICAgICAgdGFyZ2V0PSJSRkM0 MTIyIj5SRkMgNDEyMjwveHJlZj4uPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIEluIGVh Y2ggY2FzZSwgdGhlIGRlZmluZXIgb2YgdGhlIG5hbWUgb3IgdmFsdWUgTVVTVCB0YWtlCiAgICAg ICAgcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0byBtYWtlIHN1cmUgdGhleSBhcmUgaW4gY29udHJv bCBvZiB0aGUgcGFydCBvZgogICAgICAgIHRoZSBuYW1lc3BhY2UgdGhleSB1c2UgdG8gZGVmaW5l IHRoZSBjbGFpbSBuYW1lLjwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0 bGU9IlByaXZhdGUgQ2xhaW0gTmFtZXMiIGFuY2hvcj0iUHJpdmF0ZUNsYWltTmFtZSI+CgogICAg ICAgICA8dD5BIHByb2R1Y2VyIGFuZCBjb25zdW1lciBvZiBhIEpXVCBtYXkgYWdyZWUgdG8gYW55 IGNsYWltCiAgICAgICAgIG5hbWUgdGhhdCBpcyBub3QgYSBSZXNlcnZlZCBOYW1lIDx4cmVmIHRh cmdldD0iUmVzZXJ2ZWRDbGFpbU5hbWUiPjwveHJlZj4KCSBvciBhIFB1YmxpYyBOYW1lIDx4cmVm IHRhcmdldD0iUHVibGljQ2xhaW1OYW1lIj48L3hyZWY+LiBVbmxpa2UKICAgICAgICAgUHVibGlj IE5hbWVzLCB0aGVzZSBwcml2YXRlIG5hbWVzIGFyZSBzdWJqZWN0IHRvIGNvbGxpc2lvbiBhbmQK ICAgICAgICAgc2hvdWxkIGJlIHVzZWQgd2l0aCBjYXV0aW9uLjwvdD4KCiAgICAgIDwvc2VjdGlv bj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iSldUIEVudmVsb3BlIj4KCiAg ICAgIDx0PlRoZSBtZW1iZXJzIG9mIHRoZSBKU09OIG9iamVjdCByZXByZXNlbnRlZCBieSB0aGUg RGVjb2RlZCBKV1QKICAgICAgRW52ZWxvcGUgU2VnbWVudCBkZXNjcmliZSB0aGUgc2lnbmF0dXJl IGFwcGxpZWQgdG8gdGhlIEpXVCBDbGFpbQogICAgICBTZWdtZW50IGFuZCBvcHRpb25hbGx5IGFk ZGl0aW9uYWwgcHJvcGVydGllcyBvZiB0aGUgSldULgogICAgICBJbXBsZW1lbnRhdGlvbnMgTVVT VCB1bmRlcnN0YW5kIHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhlCiAgICAgIGVudmVsb3BlOyBv dGhlcndpc2UsIHRoZSBKV1QgTVVTVCBiZSByZWplY3RlZCBmb3IKICAgICAgcHJvY2Vzc2luZy48 L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iUmVzZXJ2ZWQgRW52ZWxvcGUgUGFyYW1ldGVyIE5h bWVzIiBhbmNob3I9IlJlc2VydmVkRW52ZWxvcGVQYXJhbWV0ZXJOYW1lIj4KCTx0PlRoZSBmb2xs b3dpbmcgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWVzIGFyZSByZXNlcnZlZC4gIEFsbAoJdGhlIG5h bWVzIGFyZSBzaG9ydCBiZWNhdXNlIGEgY29yZSBnb2FsIG9mIEpXVHMgaXMgZm9yIHRoZQoJdG9r ZW5zIHRoZW1zZWx2ZXMgdG8gYmUgc2hvcnQuPC90PgoKCTx0ZXh0dGFibGUgdGl0bGU9IlJlc2Vy dmVkIEVudmVsb3BlIFBhcmFtZXRlciBEZWZpbml0aW9ucyIgYW5jaG9yPSJFbnZlbG9wZVBhcmFt ZXRlclRhYmxlIj4KCgkgIDx0dGNvbCBhbGlnbj0ibGVmdCI+RW52ZWxvcGUgUGFyYW1ldGVyIE5h bWU8L3R0Y29sPgoJICA8dHRjb2wgYWxpZ249ImxlZnQiPkpTT04gVmFsdWUgVHlwZTwvdHRjb2w+ CgkgIDx0dGNvbCBhbGlnbj0ibGVmdCI+RW52ZWxvcGUgUGFyYW1ldGVyIFN5bnRheDwvdHRjb2w+ CgkgIDx0dGNvbCBhbGlnbj0ibGVmdCI+RW52ZWxvcGUgUGFyYW1ldGVyIFNlbWFudGljczwvdHRj b2w+CgoJICA8Yz5hbGc8L2M+CgkgIDxjPnN0cmluZzwvYz4KCSAgPGM+U3RyaW5nQW5kVVJJPC9j PgoJICA8Yz5UaGUgImFsZyIgKGFsZ29yaXRobSkgZW52ZWxvcGUgcGFyYW1ldGVyIGlkZW50aWZp ZXMgdGhlCgkgIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIHVzZWQgdG8gc2VjdXJlIHRoZSBKV1Qu ICBBIGxpc3Qgb2YKCSAgcmVzZXJ2ZWQgYWxnIHZhbHVlcyBpcyBpbiA8eHJlZiB0YXJnZXQ9IkFs Z1RhYmxlIj48L3hyZWY+LgoJICBUaGUgcHJvY2Vzc2luZyBvZiB0aGUgImFsZyIgKGFsZ29yaXRo bSkgZW52ZWxvcGUgcGFyYW1ldGVyLAoJICBpZiBwcmVzZW50LCByZXF1aXJlcyB0aGF0IHRoZSB2 YWx1ZSBvZiB0aGUgImFsZyIgZW52ZWxvcGUKCSAgcGFyYW1ldGVyIE1VU1QgYmUgb25lIHRoYXQg aXMgYm90aCBzdXBwb3J0ZWQgYW5kIGZvciB3aGljaAoJICB0aGVyZSBleGlzdHMgYSBrZXkgZm9y IHVzZSB3aXRoIHRoYXQgYWxnb3JpdGhtIGFzc29jaWF0ZWQKCSAgd2l0aCB0aGUgaXNzdWVyIG9m IHRoZSBKV1QuICBOb3RlIGhvd2V2ZXIsIHRoYXQgaWYgdGhlICJpc3MiCgkgIChpc3N1ZXIpIGNs YWltIGlzIG5vdCBpbmNsdWRlZCBpbiB0aGUgSldUIENsYWltIFNlZ21lbnQsCgkgIHRoZW4gdGhl IG1hbm5lciBpbiB3aGljaCB0aGUgaXNzdWVyIGlzIGRldGVybWluZWQgaXMKCSAgYXBwbGljYXRp b24gc3BlY2lmaWMuIFRoaXMgZW52ZWxvcGUgcGFyYW1ldGVyIGlzCgkgIFJFUVVJUkVELjwvYz4K CgkgIDxjPnR5cDwvYz4KCSAgPGM+c3RyaW5nPC9jPgoJICA8Yz5TdHJpbmdBbmRVUkk8L2M+Cgkg IDxjPlRoZSAidHlwIiAodHlwZSkgZW52ZWxvcGUgcGFyYW1ldGVyIGlzIHVzZWQgdG8gZGVjbGFy ZQoJICB0aGF0IHRoaXMgZGF0YSBzdHJ1Y3R1cmUgaXMgYSBKV1QuICBJZiBhICJ0eXAiIHBhcmFt ZXRlciBpcwoJICBwcmVzZW50LCBpdHMgdmFsdWUgTVVTVCBiZSAiSldUIi4gIFRoaXMgZW52ZWxv cGUgcGFyYW1ldGVyCgkgIGlzIE9QVElPTkFMLiAgKE5vbi1ub3JtYXRpdmUgbm90ZTogT3RoZXIg dmFsdWVzIGNvdWxkIGJlCgkgIHVzZWQgYnkgb3RoZXIgc3BlY2lmaWNhdGlvbnMgdG8gZGVjbGFy ZSBkYXRhIHN0cnVjdHVyZXMKCSAgb3RoZXIgdGhhbiBKV1RzLCBmb3IgaW5zdGFuY2UsIGVuY3J5 cHRlZCBKU09OIHRva2Vucy4pPC9jPgoKCSAgPGM+a2V5aWQ8L2M+CgkgIDxjPnN0cmluZzwvYz4K CSAgPGM+U3RyaW5nPC9jPgoJICA8Yz5UaGUgImtleWlkIiAoa2V5IElEKSBlbnZlbG9wZSBwYXJh bWV0ZXIgaXMgYSBoaW50CgkgIGluZGljYXRpbmcgd2hpY2ggc3BlY2lmaWMga2V5IG93bmVkIGJ5 IHRoZSBzaWduZXIgc2hvdWxkIGJlCgkgIHVzZWQgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZS4g IFRoaXMgYWxsb3dzIHNpZ25lcnMgdG8KCSAgZXhwbGljaXRseSBzaWduYWwgYSBjaGFuZ2Ugb2Yg a2V5IHRvIHJlY2lwaWVudHMuIE9taXR0aW5nCgkgIHRoaXMgcGFyYW1ldGVyIGlzIGVxdWl2YWxl bnQgdG8gc2V0dGluZyBpdCB0byBhbiBlbXB0eQoJICBzdHJpbmcuIFRoZSBmb3JtYXQgb2YgdGhp cyBwYXJhbWV0ZXIgaXMgdW5zcGVjaWZpZWQuICBUaGlzCgkgIGVudmVsb3BlIHBhcmFtZXRlciBp cyBPUFRJT05BTC48L2M+CgoJICA8Yz5jdXJpPC9jPgoJICA8Yz5zdHJpbmc8L2M+CgkgIDxjPlVS STwvYz4KCSAgPGM+VGhlICJjdXJpIiAoY2VydGlmaWNhdGVzIFVSSSkgZW52ZWxvcGUgcGFyYW1l dGVyIGlzIGEgVVJJCgkgIHRoYXQgcG9pbnRzIHRvIFguNTA5IHB1YmxpYyBrZXkgY2VydGlmaWNh dGVzIHRoYXQgY2FuIGJlCgkgIHVzZWQgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZS4gIFRoaXMg ZW52ZWxvcGUgcGFyYW1ldGVyIGlzCgkgIE9QVElPTkFMLjwvYz4KCgkgIDxjPmN0cDwvYz4KCSAg PGM+c3RyaW5nPC9jPgoJICA8Yz5TdHJpbmc8L2M+CgkgIDxjPlRoZSAiY3RwIiAoY2VydGlmaWNh dGUgdGh1bWJwcmludCkgZW52ZWxvcGUgcGFyYW1ldGVyCgkgIHByb3ZpZGVzIGEgYmFzZTY0dXJs IGVuY29kZWQgU0hBLTEgdGh1bWJwcmludCBvZiB0aGUgREVSCgkgIGVuY29kaW5nIG9mIGEgY2Vy dGlmaWNhdGUgdGhhdCBjYW4gYmUgdXNlZCB0byB2YWxpZGF0ZSB0aGUKCSAgc2lnbmF0dXJlLiAg VGhpcyBlbnZlbG9wZSBwYXJhbWV0ZXIgaXMgT1BUSU9OQUwuPC9jPgoKCTwvdGV4dHRhYmxlPgoK CTx0PkFkZGl0aW9uYWwgcmVzZXJ2ZWQgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWVzIE1BWSBiZSBk ZWZpbmVkCgl2aWEgdGhlIElBTkEgSlNPTiBXZWIgVG9rZW4gRW52ZWxvcGUgUGFyYW1ldGVycyBy ZWdpc3RyeSwgYXMKCXBlciA8eHJlZiB0YXJnZXQ9IklBTkEiPjwveHJlZj4uICBUaGUgZW52ZWxv cGUgdmFsdWUgc3ludGF4ZXMKCXJlZmVycmVkIHRvIGFib3ZlIGFyZSBkZWZpbmVkIGluIDx4cmVm Cgl0YXJnZXQ9IlN5bnRheERlZmluaXRpb25zIj48L3hyZWY+LjwvdD4KCiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJQdWJsaWMgRW52ZWxvcGUgUGFyYW1ldGVyIE5hbWVz IiBhbmNob3I9IlB1YmxpY0VudmVsb3BlUGFyYW1ldGVyTmFtZSI+CgogICAgICAgIDx0PkFkZGl0 aW9uYWwgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWVzIGNhbiBiZSBkZWZpbmVkIGJ5IHRob3NlIHVz aW5nCiAgICAgICAgSldUcy4gSG93ZXZlciwgaW4gb3JkZXIgdG8gcHJldmVudCBjb2xsaXNpb25z LCBhbnkgbmV3IGVudmVsb3BlIHBhcmFtZXRlcgogICAgICAgIG5hbWUgb3IgYWxnb3JpdGhtIHZh bHVlIFNIT1VMRCBlaXRoZXIgYmUgZGVmaW5lZCBpbiB0aGUgSUFOQQogICAgICAgIEpTT04gV2Vi IFRva2VuIEVudmVsb3BlIFBhcmFtZXRlcnMgcmVnaXN0cnkgb3IgYmUgZGVmaW5lZCBhcwogICAg ICAgIGEgVVJJIHRoYXQgY29udGFpbnMgYSBjb2xsaXNpb24gcmVzaXN0YW50IG5hbWVzcGFjZS4K ICAgICAgICBJbiBlYWNoIGNhc2UsIHRoZSBkZWZpbmVyIG9mIHRoZSBuYW1lIG9yIHZhbHVlIE1V U1QgdGFrZQogICAgICAgIHJlYXNvbmFibGUgcHJlY2F1dGlvbnMgdG8gbWFrZSBzdXJlIHRoZXkg YXJlIGluIGNvbnRyb2wgb2YgdGhlIHBhcnQgb2YKICAgICAgICB0aGUgbmFtZXNwYWNlIHRoZXkg dXNlIHRvIGRlZmluZSB0aGUgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWUuPC90PgoKCTx0Pk5ldyBl bnZlbG9wZSBwYXJhbWV0ZXJzIHNob3VsZCBiZSBpbnRyb2R1Y2VkIHNwYXJpbmdseSwgYXMKCXRo ZXkgY2FuIHJlc3VsdCBpbiBub24taW50ZXJvcGVyYWJsZSBKV1RzLiAgTm9uZXRoZWxlc3MsIHNv bWUKCWV4dGVuc2lvbnMgbmVlZGVkIGZvciBzb21lIHVzZSBjYXNlcyBtYXkgcmVxdWlyZSB0aGVt LCBzdWNoIGFzCglhbiBleHRlbnNpb24gdG8gZW5hYmxlIHRoZSBpbmNsdXNpb24gb2YgbXVsdGlw bGUKCXNpZ25hdHVyZXMuPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRs ZT0iUHJpdmF0ZSBFbnZlbG9wZSBQYXJhbWV0ZXIgTmFtZXMiIGFuY2hvcj0iUHJpdmF0ZUVudmVs b3BlUGFyYW1ldGVyTmFtZSI+CgogICAgICAgICA8dD5BIHByb2R1Y2VyIGFuZCBjb25zdW1lciBv ZiBhIEpXVCBtYXkgYWdyZWUgdG8gYW55IGVudmVsb3BlIHBhcmFtZXRlcgogICAgICAgICBuYW1l IHRoYXQgaXMgbm90IGEgUmVzZXJ2ZWQgTmFtZSA8eHJlZiB0YXJnZXQ9IlJlc2VydmVkRW52ZWxv cGVQYXJhbWV0ZXJOYW1lIj48L3hyZWY+Cgkgb3IgYSBQdWJsaWMgTmFtZSA8eHJlZiB0YXJnZXQ9 IlB1YmxpY0VudmVsb3BlUGFyYW1ldGVyTmFtZSI+PC94cmVmPi4gVW5saWtlCiAgICAgICAgIFB1 YmxpYyBOYW1lcywgdGhlc2UgcHJpdmF0ZSBuYW1lcyBhcmUgc3ViamVjdCB0byBjb2xsaXNpb24g YW5kCiAgICAgICAgIHNob3VsZCBiZSB1c2VkIHdpdGggY2F1dGlvbi48L3Q+CgoJPHQ+TmV3IGVu dmVsb3BlIHBhcmFtZXRlcnMgc2hvdWxkIGJlIGludHJvZHVjZWQgc3BhcmluZ2x5LCBhcwoJdGhl eSBjYW4gcmVzdWx0IGluIG5vbi1pbnRlcm9wZXJhYmxlIEpXVHMuPC90PgoKICAgICAgPC9zZWN0 aW9uPgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJHZW5lcmFsIFJ1bGVzIGZv ciBDcmVhdGluZyBhbmQgVmFsaWRhdGluZyBhIEpXVCI+CiAgICAgIDx0PlRvIGNyZWF0ZSBhIEpX VCBvbmUgTVVTVCBmb2xsb3cgdGhlc2Ugc3RlcHM6CiAgICAgICAgPGxpc3Qgc3R5bGU9Im51bWJl cnMiPgoKICAgICAgICAgIDx0PkNyZWF0ZSBhIEpTT04gb2JqZWN0IGNvbnRhaW5pbmcgdGhlIGRl c2lyZWQgY2xhaW1zLiAgTm90ZQogICAgICAgICAgdGhhdCB3aGl0ZSBzcGFjZSBpcyBleHBsaWNp dGx5IGFsbG93ZWQgaW4gdGhlIHJlcHJlc2VudGF0aW9uCiAgICAgICAgICBhbmQgbm8gY2Fub25p Y2FsaXphdGlvbiBpcyBwZXJmb3JtZWQgYmVmb3JlIGVuY29kaW5nLjwvdD4KCiAgICAgICAgICA8 dD5UcmFuc2xhdGUgdGhpcyBKU09OIG9iamVjdCdzIFVuaWNvZGUgY29kZSBwb2ludHMgaW50bwog ICAgICAgICAgVVRGLTgsIGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMzNjI5Ij5SRkMK ICAgICAgICAgIDM2Mjk8L3hyZWY+LjwvdD4KCiAgICAgICAgICA8dD5CYXNlNjR1cmwgZW5jb2Rl IHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGlzCiAgICAgICAgICBKU09OIG9iamVjdCBh cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiAod2l0aG91dAogICAgICAgICAgcGFkZGlu ZykuIFRoaXMgZW5jb2RpbmcgYmVjb21lcyB0aGUgSldUIENsYWltIFNlZ21lbnQuPC90PgoKCSAg PHQ+Q3JlYXRlIGEgZGlmZmVyZW50IEpTT04gb2JqZWN0IGNvbnRhaW5pbmcgdGhlIGRlc2lyZWQK CSAgZW52ZWxvcGUgcGFyYW1ldGVycy4gIE5vdGUgdGhhdCB3aGl0ZSBzcGFjZSBpcyBleHBsaWNp dGx5CgkgIGFsbG93ZWQgaW4gdGhlIHJlcHJlc2VudGF0aW9uIGFuZCBubyBjYW5vbmljYWxpemF0 aW9uIGlzCgkgIHBlcmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuPC90PgoKICAgICAgICAgIDx0PlRy YW5zbGF0ZSB0aGlzIEpTT04gb2JqZWN0J3MgVW5pY29kZSBjb2RlIHBvaW50cyBpbnRvCiAgICAg ICAgICBVVEYtOCwgYXMgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzM2MjkiPlJGQwogICAg ICAgICAgMzYyOTwveHJlZj4uPC90PgoKICAgICAgICAgIDx0PkJhc2U2NHVybCBlbmNvZGUgdGhl IFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoaXMgSlNPTgogICAgICAgICAgb2JqZWN0IGFzIGRl ZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uICh3aXRob3V0CiAgICAgICAgICBwYWRkaW5nKS4g VGhpcyBlbmNvZGluZyBiZWNvbWVzIHRoZSBKV1QgRW52ZWxvcGUKICAgICAgICAgIFNlZ21lbnQu PC90PgoKICAgICAgICAgIDx0PkNvbnN0cnVjdCB0aGUgSldUIENyeXB0byBTZWdtZW50IGFzIGRl ZmluZWQgZm9yIHRoZQogICAgICAgICAgcGFydGljdWxhciBhbGdvcml0aG0gYmVpbmcgdXNlZC4g IFRoZSAiYWxnIiBlbnZlbG9wZQogICAgICAgICAgcGFyYW1ldGVyIE1VU1QgYmUgcHJlc2VudCBp biB0aGUgSlNPTiBFbnZlbG9wZSBTZWdtZW50LCB3aXRoCiAgICAgICAgICB0aGUgYWxnb3JpdGht IHZhbHVlIGFjY3VyYXRlbHkgcmVwcmVzZW50aW5nIHRoZSBhbGdvcml0aG0KICAgICAgICAgIHVz ZWQgdG8gY29uc3RydWN0IHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQuPC90PgoKICAgICAgICAgIDx0 PkNvbWJpbmUgdGhlIEpXVCBFbnZlbG9wZSBTZWdtZW50LCB0aGUgSldUIENsYWltIFNlZ21lbnQK ICAgICAgICAgIGFuZCB0aGVuIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQgaW4gdGhhdCBvcmRlciwg c2VwYXJhdGluZwogICAgICAgICAgZWFjaCBieSBwZXJpb2QgY2hhcmFjdGVycywgdG8gY3JlYXRl IHRoZSBKV1QuPC90PgoKICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+V2hlbiB2YWxpZGF0 aW5nIGEgSldUIHRoZSBmb2xsb3dpbmcgc3RlcHMgTVVTVCBiZSB0YWtlbi4gSWYKICAgICAgYW55 IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgdG9rZW4gTVVTVCBiZSByZWplY3Rl ZAogICAgICBmb3IgcHJvY2Vzc2luZy48L3Q+CgogICAgICA8dD48bGlzdCBzdHlsZT0ibnVtYmVy cyI+CgogICAgICAgICAgPHQ+VGhlIEpXVCBNVVNUIGNvbnRhaW4gdHdvIHBlcmlvZCBjaGFyYWN0 ZXJzLjwvdD4KCiAgICAgICAgICA8dD5UaGUgSldUIE1VU1QgYmUgc3BsaXQgb24gdGhlIHR3byBw ZXJpb2QgY2hhcmFjdGVycwogICAgICAgICAgcmVzdWx0aW5nIGluIHRocmVlIG5vbi1lbXB0eSBz ZWdtZW50cy4gIFRoZSBmaXJzdCBzZWdtZW50IGlzCiAgICAgICAgICB0aGUgSldUIEVudmVsb3Bl IFNlZ21lbnQ7IHRoZSBzZWNvbmQgaXMgdGhlIEpXVCBDbGFpbQogICAgICAgICAgU2VnbWVudDsg dGhlIHRoaXJkIGlzIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQuPC90PgoKICAgICAgICAgIDx0PlRo ZSBKV1QgRW52ZWxvcGUgU2VnbWVudCBNVVNUIGJlIHN1Y2Nlc3NmdWxseSBiYXNlNjR1cmwKICAg ICAgICAgIGRlY29kZWQgZm9sbG93aW5nIHRoZSByZXN0cmljdGlvbiBnaXZlbiBpbiB0aGlzIHNw ZWMgdGhhdCBubwogICAgICAgICAgcGFkZGluZyBjaGFyYWN0ZXJzIG1heSBoYXZlIGJlZW4gdXNl ZC48L3Q+CgogICAgICAgICAgPHQ+VGhlIERlY29kZWQgSldUIEVudmVsb3BlIFNlZ21lbnQgTVVT VCBiZSBjb21wbGV0ZWx5IHZhbGlkCiAgICAgICAgICBKU09OIHN5bnRheC48L3Q+CgogICAgICAg ICAgPHQ+VGhlIEpXVCBDbGFpbSBTZWdtZW50IE1VU1QgYmUgc3VjY2Vzc2Z1bGx5IGJhc2U2NHVy bAogICAgICAgICAgZGVjb2RlZCBmb2xsb3dpbmcgdGhlIHJlc3RyaWN0aW9uIGdpdmVuIGluIHRo aXMgc3BlYyB0aGF0IG5vCiAgICAgICAgICBwYWRkaW5nIGNoYXJhY3RlcnMgbWF5IGhhdmUgYmVl biB1c2VkLjwvdD4KCiAgICAgICAgICA8dD5UaGUgRGVjb2RlZCBKV1QgQ2xhaW0gU2VnbWVudCBN VVNUIGJlIGNvbXBsZXRlbHkgdmFsaWQKICAgICAgICAgIEpTT04gc3ludGF4LjwvdD4KCiAgICAg ICAgICA8dD5UaGUgSldUIENyeXB0byBTZWdtZW50IE1VU1QgYmUgc3VjY2Vzc2Z1bGx5IGJhc2U2 NHVybAogICAgICAgICAgZGVjb2RlZCBmb2xsb3dpbmcgdGhlIHJlc3RyaWN0aW9uIGdpdmVuIGlu IHRoaXMgc3BlYyB0aGF0IG5vCiAgICAgICAgICBwYWRkaW5nIGNoYXJhY3RlcnMgbWF5IGhhdmUg YmVlbiB1c2VkLjwvdD4KCiAgICAgICAgICA8dD5UaGUgSldUIEVudmVsb3BlIFNlZ21lbnQgTVVT VCBiZSB2YWxpZGF0ZWQgdG8gb25seQogICAgICAgICAgaW5jbHVkZSBwYXJhbWV0ZXJzIGFuZCB2 YWx1ZXMgd2hvc2Ugc3ludGF4IGFuZCBzZW1hbnRpY3MgYXJlCiAgICAgICAgICBib3RoIHVuZGVy c3Rvb2QgYW5kIHN1cHBvcnRlZC48L3Q+CgogICAgICAgICAgPHQ+V2hlbiB1c2VkIGluIGEgc2Vj dXJpdHktcmVsYXRlZCBjb250ZXh0LCB0aGUgSldUIENsYWltCiAgICAgICAgICBTZWdtZW50IE1V U1QgYmUgdmFsaWRhdGVkIHRvIG9ubHkgaW5jbHVkZSBjbGFpbXMgd2hvc2UKICAgICAgICAgIHN5 bnRheCBhbmQgc2VtYW50aWNzIGFyZSBib3RoIHVuZGVyc3Rvb2QgYW5kIHN1cHBvcnRlZC48L3Q+ CgogICAgICAgICAgPHQ+VGhlIEpXVCBDcnlwdG8gU2VnbWVudCBNVVNUIGJlIHN1Y2Nlc3NmdWxs eSB2YWxpZGF0ZWQKICAgICAgICAgIGFnYWluc3QgdGhlIEpXVCBDbGFpbSBTZWdtZW50IGluIHRo ZSBtYW5uZXIgZGVmaW5lZCBmb3IgdGhlCiAgICAgICAgICBhbGdvcml0aG0gYmVpbmcgdXNlZCwg d2hpY2ggTVVTVCBiZSBhY2N1cmF0ZWx5IHJlcHJlc2VudGVkCiAgICAgICAgICBieSB0aGUgdmFs dWUgb2YgdGhlICJhbGciIGVudmVsb3BlIHBhcmFtZXRlciwgd2hpY2ggTVVTVCBiZQogICAgICAg ICAgcHJlc2VudC48L3Q+CgogICAgICAgIDwvbGlzdD48L3Q+CgogICAgICA8dD5Qcm9jZXNzaW5n IGEgSldUIGluZXZpdGFibHkgcmVxdWlyZXMgY29tcGFyaW5nIGtub3duIHN0cmluZ3MKICAgICAg dG8gdmFsdWVzIGluIHRoZSB0b2tlbi4gRm9yIGV4YW1wbGUsIGluIGNoZWNraW5nIHdoYXQgdGhl CiAgICAgIGFsZ29yaXRobSBpcywgdGhlIFVuaWNvZGUgc3RyaW5nIGVuY29kaW5nICJhbGciIHdp bGwgYmUgY2hlY2tlZAogICAgICBhZ2FpbnN0IHRoZSBtZW1iZXIgbmFtZXMgaW4gdGhlIERlY29k ZWQgSldUIEVudmVsb3BlIFNlZ21lbnQgdG8KICAgICAgc2VlIGlmIHRoZXJlIGlzIGEgbWF0Y2hp bmcgZW52ZWxvcGUgcGFyYW1ldGVyIG5hbWUuIEEgc2ltaWxhcgogICAgICBwcm9jZXNzIG9jY3Vy cyB3aGVuIGRldGVybWluaW5nIGlmIHRoZSB2YWx1ZSBvZiB0aGUgImFsZyIKICAgICAgZW52ZWxv cGUgcGFyYW1ldGVyIHJlcHJlc2VudHMgYSBzdXBwb3J0ZWQgYWxnb3JpdGhtLiBDb21wYXJpbmcK ICAgICAgVW5pY29kZSBzdHJpbmdzLCBob3dldmVyLCBoYXMgc2lnbmlmaWNhbnQgc2VjdXJpdHkg aW1wbGljYXRpb25zLAogICAgICBhcyBwZXIgPHhyZWYgdGFyZ2V0PSJTZWN1cml0eSI+PC94cmVm Pi48L3Q+CgogICAgICA8dD5Db21wYXJpc29ucyBiZXR3ZWVuIEpTT04gc3RyaW5ncyBhbmQgb3Ro ZXIgVW5pY29kZSBzdHJpbmdzCiAgICAgIE1VU1QgYmUgcGVyZm9ybWVkIGFzIHNwZWNpZmllZCBi ZWxvdzo8L3Q+CgogICAgICA8dD48bGlzdCBzdHlsZT0ibnVtYmVycyI+CgogICAgICAgICAgPHQ+ UmVtb3ZlIGFueSBKU09OIGFwcGxpZWQgZXNjYXBpbmcgdG8gcHJvZHVjZSBhbiBhcnJheSBvZgog ICAgICAgICAgVW5pY29kZSBjb2RlIHBvaW50cy48L3Q+CgogICAgICAgICAgPHQ+PHhyZWYgdGFy Z2V0PSJVU0ExNSI+VW5pY29kZSBOb3JtYWxpemF0aW9uPC94cmVmPiBNVVNUCiAgICAgICAgICBO T1QgYmUgYXBwbGllZCBhdCBhbnkgcG9pbnQgdG8gZWl0aGVyIHRoZSBKU09OIHN0cmluZyBvciB0 bwogICAgICAgICAgdGhlIHN0cmluZyBpdCBpcyB0byBiZSBjb21wYXJlZCBhZ2FpbnN0LjwvdD4K CiAgICAgICAgICA8dD5Db21wYXJpc29ucyBiZXR3ZWVuIHRoZSB0d28gc3RyaW5ncyBNVVNUIGJl IHBlcmZvcm1lZCBhcwogICAgICAgICAgYSBVbmljb2RlIGNvZGUgcG9pbnQgdG8gY29kZSBwb2lu dCBlcXVhbGl0eSBjb21wYXJpc29uLjwvdD4KCiAgICAgICAgPC9saXN0PjwvdD4KCiAgICA8L3Nl Y3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkJhc2U2NHVybCBlbmNvZGluZyBhcyB1c2VkIGJ5 IEpXVHMiIGFuY2hvcj0iYmFzZTY0dXJsbG9naWMiPgoKICAgICAgPHQ+SldUcyBtYWtlIHVzZSBv ZiB0aGUgYmFzZTY0dXJsIGVuY29kaW5nIGFzIGRlZmluZWQgaW4gPHhyZWYKICAgICAgdGFyZ2V0 PSJSRkM0NjQ4Ij5SRkMgNDY0ODwveHJlZj4uIEFzIGFsbG93ZWQgYnkgU2VjdGlvbiAzLjIgb2Yg dGhlCiAgICAgIFJGQywgdGhpcyBzcGVjaWZpY2F0aW9uIG1hbmRhdGVzIHRoYXQgYmFzZTY0dXJs IGVuY29kaW5nCiAgICAgIHdoZW4gdXNlZCB3aXRoIEpXVHMgTVVTVCBOT1QgdXNlIHBhZGRpbmcu IFRoZSByZWFzb24gZm9yIHRoaXMKICAgICAgcmVzdHJpY3Rpb24gaXMgdGhhdCB0aGUgcGFkZGlu ZyBjaGFyYWN0ZXIgKCc9JykgaXMgbm90IFVSTAogICAgICBzYWZlLjwvdD4KCiAgICAgIDx0PkZv ciBub3RlcyBvbiBpbXBsZW1lbnRpbmcgYmFzZTY0dXJsIGVuY29kaW5nIHdpdGhvdXQgcGFkZGlu ZywKICAgICAgc2VlIDx4cmVmIHRhcmdldD0iYmFzZTY0dXJsbm90ZXMiPjwveHJlZj4uPC90Pgog ICAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbiB0aXRsZT0iU2lnbmluZyBKV1RzIHdpdGggQ3J5cHRv Z3JhcGhpYyBBbGdvcml0aG1zIiBhbmNob3I9IlNpZ25pbmciPgoKICAgIDx0PkpXVHMgdXNlIHNw ZWNpZmljIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB0byBzaWduIHRoZSBjb250ZW50cwogICAg b2YgdGhlIEpXVCBDbGFpbSBTZWdtZW50LiAgVGhlIHVzZSBvZiB0aGUgZm9sbG93aW5nIGFsZ29y aXRobXMgZm9yCiAgICBwcm9kdWNpbmcgSldUcyBpcyBkZWZpbmVkIGluIHRoaXMgc2VjdGlvbi4g IFRoZSB0YWJsZSBiZWxvdyBpcyB0aGUKICAgIGxpc3Qgb2YgImFsZyIgZW52ZWxvcGUgcGFyYW1l dGVyIHZhbHVlcyByZXNlcnZlZCBieSB0aGlzCiAgICBzcGVjaWZpY2F0aW9uLCBlYWNoIG9mIHdo aWNoIGlzIGV4cGxhaW5lZCBpbiBtb3JlIGRldGFpbCBpbiB0aGUKICAgIGZvbGxvd2luZyBzZWN0 aW9uczo8L3Q+CgogICAgICA8dGV4dHRhYmxlIHRpdGxlPSJKU09OIFdlYiBUb2tlbiBSZXNlcnZl ZCBBbGdvcml0aG0gVmFsdWVzIiBhbmNob3I9IkFsZ1RhYmxlIj4KCiAgICAgICAgPHR0Y29sIGFs aWduPSJsZWZ0Ij5BbGcgQ2xhaW0gVmFsdWU8L3R0Y29sPgogICAgICAgIDx0dGNvbCBhbGlnbj0i bGVmdCI+QWxnb3JpdGhtPC90dGNvbD4KCiAgICAgICAgPGM+SFMyNTY8L2M+CiAgICAgICAgPGM+ SE1BQyB1c2luZyBTSEEtMjU2IGhhc2ggYWxnb3JpdGhtPC9jPgoKICAgICAgICA8Yz5IUzM4NDwv Yz4KICAgICAgICA8Yz5ITUFDIHVzaW5nIFNIQS0zODQgaGFzaCBhbGdvcml0aG08L2M+CgogICAg ICAgIDxjPkhTNTEyPC9jPgogICAgICAgIDxjPkhNQUMgdXNpbmcgU0hBLTUxMiBoYXNoIGFsZ29y aXRobTwvYz4KCiAgICAgICAgPGM+UlMyNTY8L2M+CiAgICAgICAgPGM+UlNBIHVzaW5nIFNIQS0y NTYgaGFzaCBhbGdvcml0aG08L2M+CgogICAgICAgIDxjPlJTMzg0PC9jPgogICAgICAgIDxjPlJT QSB1c2luZyBTSEEtMzg0IGhhc2ggYWxnb3JpdGhtPC9jPgoKICAgICAgICA8Yz5SUzUxMjwvYz4K ICAgICAgICA8Yz5SU0EgdXNpbmcgU0hBLTUxMiBoYXNoIGFsZ29yaXRobTwvYz4KCiAgICAgICAg PGM+RVMyNTY8L2M+CiAgICAgICAgPGM+RUNEU0EgdXNpbmcgUC0yNTYgY3VydmUgYW5kIFNIQS0y NTYgaGFzaCBhbGdvcml0aG08L2M+CgogICAgICAgIDxjPkVTMzg0PC9jPgogICAgICAgIDxjPkVD RFNBIHVzaW5nIFAtMzg0IGN1cnZlIGFuZCBTSEEtMzg0IGhhc2ggYWxnb3JpdGhtPC9jPgoKICAg ICAgICA8Yz5FUzUxMjwvYz4KICAgICAgICA8Yz5FQ0RTQSB1c2luZyBQLTUyMSBjdXJ2ZSBhbmQg U0hBLTUxMiBoYXNoIGFsZ29yaXRobTwvYz4KCiAgICAgIDwvdGV4dHRhYmxlPgoKICAgIDx0Pk9m IHRoZXNlIGFsZ29yaXRobXMsIG9ubHkgSE1BQyBTSEEtMjU2IGFuZCBSU0EgU0hBLTI1NiBNVVNU IGJlCiAgICBpbXBsZW1lbnRlZC4gIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1wbGVtZW50YXRp b25zIGFsc28KICAgIGltcGxlbWVudCBhdCBsZWFzdCB0aGUgRUNEU0EgUC0yNTYgU0hBLTI1NiBh bGdvcml0aG0uPC90PgoKICAgIDxzZWN0aW9uIHRpdGxlPSJTaWduaW5nIGEgSldUIHdpdGggSE1B QyBTSEEtMjU2IiBhbmNob3I9IlNpZ25pbmdXaXRoSE1BQ1NIQTI1NiI+CgogICAgICA8dD5IYXNo IGJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMgKEhNQUNzKSBlbmFibGUgb25lIHRv CiAgICAgIHVzZSBhIHNlY3JldCBwbHVzIGEgY3J5cHRvZ3JhcGhpYyBoYXNoIGZ1bmN0aW9uIHRv IGdlbmVyYXRlIGEKICAgICAgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChNQUMpLiBUaGlz IGNhbiBiZSB1c2VkIHRvCiAgICAgIGRlbW9uc3RyYXRlIHRoYXQgdGhlIE1BQyBtYXRjaGVzIHRo ZSBoYXNoZWQgY29udGVudCwgaW4gdGhpcwogICAgICBjYXNlIHRoZSBKV1QgQ2xhaW0gU2VnbWVu dCwgd2hpY2ggdGhlcmVmb3JlIGRlbW9uc3RyYXRlcyB0aGF0CiAgICAgIHdob2V2ZXIgZ2VuZXJh dGVkIHRoZSBNQUMgd2FzIGluIHBvc3Nlc3Npb24gb2YgdGhlCiAgICAgIHNlY3JldC48L3Q+Cgog ICAgICA8dD5UaGUgYWxnb3JpdGhtIGZvciBpbXBsZW1lbnRpbmcgYW5kIHZhbGlkYXRpbmcgSE1B Q3MgaXMKICAgICAgcHJvdmlkZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMTA0Ij5SRkMgMjEwNDwv eHJlZj4uIEFsdGhvdWdoIGFueQogICAgICBITUFDIGNhbiBiZSB1c2VkIHdpdGggSldUcywgdGhp cyBzZWN0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiB0aGUKICAgICAgU0hBLTI1NiBjcnlwdG9ncmFw aGljIGhhc2ggZnVuY3Rpb24gYXMgZGVmaW5lZCBpbiA8eHJlZgogICAgICB0YXJnZXQ9IkZJUFMu MTgwLTMiPkZJUFMgMTgwLTM8L3hyZWY+LiBUaGUgcmVzZXJ2ZWQgImFsZyIKICAgICAgZW52ZWxv cGUgcGFyYW1ldGVyIHZhbHVlICJIUzI1NiIgaXMgdXNlZCBpbiB0aGUgSldUIEVudmVsb3BlCiAg ICAgIFNlZ21lbnQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgSldUIENyeXB0byBTZWdtZW50IGNvbnRh aW5zIGEKICAgICAgYmFzZTY0dXJsIGVuY29kZWQgSE1BQyBTSEEtMjU2IEhNQUMgdmFsdWUuPC90 PgoKICAgICAgPHQ+VGhlIEhNQUMgU0hBLTI1NiBNQUMgaXMgZ2VuZXJhdGVkIGFzIGZvbGxvd3M6 CiAgICAgICAgPGxpc3Qgc3R5bGU9Im51bWJlcnMiPgogICAgICAgICAgPHQ+VGFrZSB0aGUgYnl0 ZXMgb2YgdGhlIFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QKICAgICAgICAgIENsYWlt IFNlZ21lbnQgYW5kIGV4ZWN1dGUgdGhlIEhNQUMgU0hBLTI1NiBhbGdvcml0aG0gb24gdGhlbQog ICAgICAgICAgdXNpbmcgdGhlIHNoYXJlZCBrZXkgdG8gcHJvZHVjZSBhbiBITUFDLjwvdD4KCiAg ICAgICAgICA8dD5CYXNlNjR1cmwgZW5jb2RlIHRoZSBITUFDIGFzIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudC48L3Q+CiAgICAgICAgPC9saXN0PgogICAgICBUaGUgb3V0cHV0IGlzIHBsYWNlZCBp biB0aGUgSldUIENyeXB0byBTZWdtZW50IGZvciB0aGF0IEpXVC48L3Q+CgogICAgICA8dD5UaGUg SE1BQyBTSEEtMjU2IE1BQyBvbiBhIEpXVCBpcyB2YWxpZGF0ZWQgYXMgZm9sbG93czoKICAgICAg ICA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CgogICAgICAgICAgPHQ+VGFrZSB0aGUgYnl0ZXMgb2Yg dGhlIFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QKICAgICAgICAgIENsYWltIFNlZ21l bnQgYW5kIGNhbGN1bGF0ZSBhbiBITUFDIFNIQS0yNTYgTUFDIG9uIHRoZW0KICAgICAgICAgIHVz aW5nIHRoZSBzaGFyZWQga2V5LjwvdD4KCiAgICAgICAgICA8dD5CYXNlNjR1cmwgZW5jb2RlIHRo ZSBwcmV2aW91c2x5IGdlbmVyYXRlZCBITUFDIGFzIGRlZmluZWQgaW4gdGhpcwogICAgICAgICAg ZG9jdW1lbnQuPC90PgoKICAgICAgICAgIDx0PklmIHRoZSBKV1QgQ3J5cHRvIFNlZ21lbnQgYW5k IHRoZSBwcmV2aW91c2x5IGNhbGN1bGF0ZWQgdmFsdWUKICAgICAgICAgIGV4YWN0bHkgbWF0Y2gg aW4gYSBjaGFyYWN0ZXIgYnkgY2hhcmFjdGVyLCBjYXNlIHNlbnNpdGl2ZQogICAgICAgICAgY29t cGFyaXNvbiwgdGhlbiBvbmUgaGFzIGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBrZXkgd2FzCiAgICAg ICAgICB1c2VkIHRvIGdlbmVyYXRlIHRoZSBITUFDIG9uIHRoZSBKV1QgYW5kIHRoYXQgdGhlIGNv bnRlbnRzIG9mCiAgICAgICAgICB0aGUgSldUIENsYWltIFNlZ21lbnQgaGF2ZSBub3QgYmUgdGFt cGVyZWQgd2l0aC48L3Q+CgoJICA8dD5JZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlIHRva2Vu IE1VU1QgYmUgcmVqZWN0ZWQuPC90PgoKICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+U2ln bmluZyB3aXRoIHRoZSBITUFDIFNIQS0zODQgYW5kIEhNQUMgU0hBLTUxMiBhbGdvcml0aG1zIGlz CiAgICAgIHBlcmZvcm1lZCBpZGVudGljYWxseSB0byB0aGUgcHJvY2VkdXJlIGZvciBITUFDIFNI QS0yNTYgLSBqdXN0CiAgICAgIHdpdGggY29ycmVzcG9uZGluZ2x5IGxvbmdlciBrZXkgYW5kIHJl c3VsdCB2YWx1ZXMuPC90PgoKICAgICAgPHQ+SldUIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBv cnQgdGhlIEhNQUMgU0hBLTI1NiBhbGdvcml0aG0uCiAgICAgIFN1cHBvcnQgZm9yIHRoZSBITUFD IFNIQS0zODQgYW5kIEhNQUMgU0hBLTUxMiBhbGdvcml0aG1zIGlzCiAgICAgIE9QVElPTkFMLjwv dD4KCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IlNpZ25pbmcgYSBKV1Qgd2l0 aCBSU0EgU0hBLTI1NiIgYW5jaG9yPSJEZWZpbmluZ1JTQSI+CgogICAgICA8dD5UaGlzIHNlY3Rp b24gZGVmaW5lcyB0aGUgdXNlIG9mIHRoZSBSU0FTU0EtUEtDUzEtdjFfNQogICAgICBzaWduYXR1 cmUgYWxnb3JpdGhtIGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMzNDQ3Ij5SRkMKICAg ICAgMzQ0NzwveHJlZj4sIFNlY3Rpb24gOC4yIChjb21tb25seSBrbm93biBhcyBQS0NTIzEpLCB1 c2luZwogICAgICBTSEEtMjU2IGFzIHRoZSBoYXNoIGZ1bmN0aW9uLiAgTm90ZSB0aGF0IHRoZSB1 c2Ugb2YgdGhlCiAgICAgIFJTQVNTQS1QS0NTMS12MV81IGFsZ29yaXRobSBpcyBwZXJtaXR0ZWQg aW4gPHhyZWYKICAgICAgdGFyZ2V0PSJGSVBTLjE4Ni0zIj5GSVBTIDE4Ni0zPC94cmVmPiwgU2Vj dGlvbiA1LjUsIGFzIGlzIHRoZQogICAgICBTSEEtMjU2IGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5j dGlvbiwgd2hpY2ggaXMgZGVmaW5lZCBpbiA8eHJlZgogICAgICB0YXJnZXQ9IkZJUFMuMTgwLTMi PkZJUFMgMTgwLTM8L3hyZWY+LiAgVGhlIHJlc2VydmVkICJhbGciCiAgICAgIGVudmVsb3BlIHBh cmFtZXRlciB2YWx1ZSAiUlMyNTYiIGlzIHVzZWQgaW4gdGhlIEpXVCBFbnZlbG9wZQogICAgICBT ZWdtZW50IHRvIGluZGljYXRlIHRoYXQgdGhlIEpXVCBDcnlwdG8gU2VnbWVudCBjb250YWlucyBh biBSU0EKICAgICAgU0hBLTI1NiBzaWduYXR1cmUuPC90PgoKICAgICAgPHQ+QSAyMDQ4LWJpdCBv ciBsb25nZXIga2V5IGxlbmd0aCBNVVNUIGJlIHVzZWQgd2l0aCB0aGlzIGFsZ29yaXRobS48L3Q+ CgogICAgICA8dD5UaGUgUlNBIFNIQS0yNTYgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBhcyBmb2xs b3dzOgogICAgICAgIDxsaXN0IHN0eWxlPSJudW1iZXJzIj4KCiAgICAgICAgICA8dD5MZXQgSyBi ZSB0aGUgc2lnbmVyJ3MgUlNBIHByaXZhdGUga2V5IGFuZCBsZXQgTSBiZSB0aGUKICAgICAgICAg IGJ5dGVzIG9mIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGUgSldUIENsYWltCiAgICAg ICAgICBTZWdtZW50LjwvdD4KCgkgIDx0PkNvbXB1dGUgdGhlIG9jdGV0IHN0cmluZyBTID0gUlNB U1NBLVBLQ1MxLVYxXzUtU0lHTiAoSywgTSkuPC90PgoKICAgICAgICAgIDx0PkJhc2U2NHVybCBl bmNvZGUgdGhlIG9jdGV0IHN0cmluZyBTLCBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuPC90 PgoKICAgICAgICA8L2xpc3Q+CiAgICAgIFRoZSBvdXRwdXQgaXMgcGxhY2VkIGluIHRoZSBKV1Qg Q3J5cHRvIFNlZ21lbnQgZm9yIHRoYXQgSldULjwvdD4KCiAgICAgIDx0PlRoZSBSU0EgU0hBLTI1 NiBzaWduYXR1cmUgb24gYSBKV1QgaXMgdmFsaWRhdGVkIGFzIGZvbGxvd3M6CiAgICAgICAgPGxp c3Qgc3R5bGU9Im51bWJlcnMiPgoKICAgICAgICAgIDx0PlRha2UgdGhlIEpXVCBDcnlwdG8gU2Vn bWVudCBhbmQgYmFzZTY0dXJsIGRlY29kZSBpdCBpbnRvCiAgICAgICAgICBhbiBvY3RldCBzdHJp bmcgUy4gSWYgZGVjb2RpbmcgZmFpbHMsIHRoZW4gdGhlIHRva2VuIE1VU1QgYmUKICAgICAgICAg IHJlamVjdGVkLjwvdD4KCiAgICAgICAgICA8dD5MZXQgTSBiZSB0aGUgYnl0ZXMgb2YgdGhlIFVU Ri04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBKV1QKICAgICAgICAgIENsYWltIFNlZ21lbnQgYW5k IGxldCAobiwgZSkgYmUgdGhlIHB1YmxpYyBrZXkgY29ycmVzcG9uZGluZwogICAgICAgICAgdG8g dGhlIHByaXZhdGUga2V5IHVzZWQgYnkgdGhlIHNpZ25lci48L3Q+CgogICAgICAgICAgPHQ+VmFs aWRhdGUgdGhlIHNpZ25hdHVyZSB3aXRoIFJTQVNTQS1QS0NTMS1WMV81LVZFUklGWQoJICAoKG4s IGUpLCBNLCBTKS48L3Q+CgoJICA8dD5JZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlIHRva2Vu IE1VU1QgYmUgcmVqZWN0ZWQuPC90PgoKICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KCiAgICAg IDx0PlNpZ25pbmcgd2l0aCB0aGUgUlNBIFNIQS0zODQgYW5kIFJTQSBTSEEtNTEyIGFsZ29yaXRo bXMgaXMKICAgICAgcGVyZm9ybWVkIGlkZW50aWNhbGx5IHRvIHRoZSBwcm9jZWR1cmUgZm9yIFJT QSBTSEEtMjU2IC0ganVzdAogICAgICB3aXRoIGNvcnJlc3BvbmRpbmdseSBsb25nZXIga2V5IGFu ZCByZXN1bHQgdmFsdWVzLjwvdD4KCiAgICAgIDx0PkpXVCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBz dXBwb3J0IHRoZSBSU0EgU0hBLTI1NiBhbGdvcml0aG0uCiAgICAgIFN1cHBvcnQgZm9yIHRoZSBS U0EgU0hBLTM4NCBhbmQgUlNBIFNIQS01MTIgYWxnb3JpdGhtcyBpcwogICAgICBPUFRJT05BTC48 L3Q+CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJTaWduaW5nIGEgSldUIHdp dGggRUNEU0EgUC0yNTYgU0hBLTI1NiIgYW5jaG9yPSJEZWZpbmluZ0VDRFNBIj4KICAgICAgPHQ+ VGhlIEVsbGlwdGljIEN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSAoRUNEU0EpIGlz CiAgICAgIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSJGSVBTLjE4Ni0zIj5GSVBTIDE4Ni0zPC94 cmVmPi4gRUNEU0EKICAgICAgcHJvdmlkZXMgZm9yIHRoZSB1c2Ugb2YgRWxsaXB0aWMgQ3VydmUg Y3J5cHRvZ3JhcGh5LCB3aGljaCBpcwogICAgICBhYmxlIHRvIHByb3ZpZGUgZXF1aXZhbGVudCBz ZWN1cml0eSB0byBSU0EgY3J5cHRvZ3JhcGh5IGJ1dAogICAgICB1c2luZyBzaG9ydGVyIGtleSBs ZW5ndGhzIGFuZCB3aXRoIGdyZWF0ZXIgcHJvY2Vzc2luZwogICAgICBzcGVlZC4gVGhpcyBtZWFu cyB0aGF0IEVDRFNBIHNpZ25hdHVyZXMgd2lsbCBiZSBzdWJzdGFudGlhbGx5CiAgICAgIHNtYWxs ZXIgaW4gdGVybXMgb2YgbGVuZ3RoIHRoYW4gZXF1aXZhbGVudGx5IHN0cm9uZyBSU0EgRGlnaXRh bAogICAgICBTaWduYXR1cmVzLjwvdD4KCiAgICAgIDx0PlRoaXMgc3BlY2lmaWNhdGlvbiBkZWZp bmVzIHRoZSB1c2Ugb2YgRUNEU0Egd2l0aCB0aGUgUC0yNTYKICAgICAgY3VydmUgYW5kIHRoZSBT SEEtMjU2IGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5jdGlvbi4gVGhlIFAtMjU2CiAgICAgIGN1cnZl IGlzIGFsc28gZGVmaW5lZCBpbiBGSVBTIDE4Ni0zLiBUaGUgcmVzZXJ2ZWQgImFsZyIgZW52ZWxv cGUKICAgICAgcGFyYW1ldGVyIHZhbHVlICJFUzI1NiIgaXMgdXNlZCBpbiB0aGUgSldUIEVudmVs b3BlIFNlZ21lbnQgdG8KICAgICAgaW5kaWNhdGUgdGhhdCB0aGUgSldUIENyeXB0byBTZWdtZW50 IGNvbnRhaW5zIGEgRUNEU0EgUC0yNTYKICAgICAgU0hBLTI1NiBzaWduYXR1cmUuPC90PgoKICAg ICAgPHQ+QSBKV1QgaXMgc2lnbmVkIHdpdGggYW4gRUNEU0EgUC0yNTYgU0hBLTI1NiBzaWduYXR1 cmUgYXMKICAgICAgZm9sbG93czoKICAgICAgICA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAg ICAgICA8dD5UYWtlIHRoZSBieXRlcyBvZiB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24gb2YgdGhl IEpXVAogICAgICAgICAgQ2xhaW0gU2VnbWVudCBhbmQgZ2VuZXJhdGUgYSBkaWdpdGFsIHNpZ25h dHVyZSBvZiB0aGVtIHVzaW5nCiAgICAgICAgICBFQ0RTQSBQLTI1NiBTSEEtMjU2IHdpdGggdGhl IGRlc2lyZWQgcHJpdmF0ZSBrZXkuIFRoZSBvdXRwdXQKICAgICAgICAgIHdpbGwgYmUgdGhlIEVD IHBvaW50IChSLCBTKSwgd2hlcmUgUiBhbmQgUyBhcmUgdW5zaWduZWQKICAgICAgICAgIGludGVn ZXJzLjwvdD4KCiAgICAgICAgICA8dD5UdXJuIFIgYW5kIFMgaW50byBieXRlIGFycmF5cyBpbiBi aWcgZW5kaWFuIG9yZGVyLiBFYWNoIGFycmF5CiAgICAgICAgICB3aWxsIGJlIDMyIGJ5dGVzIGxv bmcuPC90PgoKICAgICAgICAgIDx0PkNvbmNhdGVuYXRlIHRoZSB0d28gYnl0ZSBhcnJheXMgaW4g dGhlIG9yZGVyIFIgYW5kIHRoZW4gUy48L3Q+CgogICAgICAgICAgPHQ+QmFzZTY0dXJsIGVuY29k ZSB0aGUgNjQgYnl0ZSBhcnJheSBhcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi48L3Q+ CiAgICAgICAgPC9saXN0PgogICAgICBUaGUgb3V0cHV0IGJlY29tZXMgdGhlIEpXVCBDcnlwdG8g U2VnbWVudCBmb3IgdGhlIEpXVC48L3Q+CgogICAgICA8dD5UaGUgZm9sbG93aW5nIHByb2NlZHVy ZSBpcyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBFQ0RTQQogICAgICBzaWduYXR1cmUgb2YgYSBKV1Q6 CiAgICAgICAgPGxpc3Qgc3R5bGU9Im51bWJlcnMiPgogICAgICAgICAgPHQ+VGFrZSB0aGUgSldU IENyeXB0byBTZWdtZW50IGFuZCBiYXNlNjR1cmwgZGVjb2RlIGl0IGludG8KICAgICAgICAgIGEg Ynl0ZSBhcnJheS4gSWYgZGVjb2RpbmcgZmFpbHMsIHRoZSB0b2tlbiBNVVNUIGJlIHJlamVjdGVk LjwvdD4KCiAgICAgICAgICA8dD5UaGUgb3V0cHV0IG9mIHRoZSBiYXNlNjR1cmwgZGVjb2Rpbmcg TVVTVCBiZSBhIDY0IGJ5dGUgYXJyYXkuPC90PgoKICAgICAgICAgIDx0PlNwbGl0IHRoZSA2NCBi eXRlIGFycmF5IGludG8gdHdvIDMyIGJ5dGUgYXJyYXlzLiBUaGUgZmlyc3QgYXJyYXkKICAgICAg ICAgIHdpbGwgYmUgUiBhbmQgdGhlIHNlY29uZCBTLiBSZW1lbWJlciB0aGF0IHRoZSBieXRlIGFy cmF5cyBhcmUKICAgICAgICAgIGluIGJpZyBlbmRpYW4gYnl0ZSBvcmRlcjsgcGxlYXNlIGNoZWNr IHRoZSBFQ0RTQSB2YWxpZGF0b3IgaW4KICAgICAgICAgIHVzZSB0byBzZWUgd2hhdCBieXRlIG9y ZGVyIGl0IHJlcXVpcmVzLjwvdD4KCiAgICAgICAgICA8dD5TdWJtaXQgdGhlIGJ5dGVzIG9mIHRo ZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGUgSldUCgkgIENsYWltIFNlZ21lbnQsIFIsIFMg YW5kIHRoZSBwdWJsaWMga2V5ICh4LCB5KSB0byB0aGUgRUNEU0EKCSAgUC0yNTYgU0hBLTI1NiB2 YWxpZGF0b3IuPC90PgoKCSAgPHQ+SWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSB0b2tlbiBN VVNUIGJlIHJlamVjdGVkLjwvdD4KCiAgICAgICAgPC9saXN0PgoKICAgICAgVGhlIEVDRFNBIHZh bGlkYXRvciB3aWxsIHRoZW4gZGV0ZXJtaW5lIGlmIHRoZSBkaWdpdGFsIHNpZ25hdHVyZQogICAg ICBpcyB2YWxpZCwgZ2l2ZW4gdGhlIGlucHV0cy4gIE5vdGUgdGhhdCBFQ0RTQSBkaWdpdGFsIHNp Z25hdHVyZQogICAgICBjb250YWlucyBhIHZhbHVlIHJlZmVycmVkIHRvIGFzIEssIHdoaWNoIGlz IGEgcmFuZG9tIG51bWJlcgogICAgICBnZW5lcmF0ZWQgZm9yIGVhY2ggZGlnaXRhbCBzaWduYXR1 cmUgaW5zdGFuY2UuIFRoaXMgbWVhbnMgdGhhdAogICAgICB0d28gRUNEU0EgZGlnaXRhbCBzaWdu YXR1cmVzIHVzaW5nIGV4YWN0bHkgdGhlIHNhbWUgaW5wdXQKICAgICAgcGFyYW1ldGVycyB3aWxs IG91dHB1dCBkaWZmZXJlbnQgc2lnbmF0dXJlcyBiZWNhdXNlIHRoZWlyIEsKICAgICAgdmFsdWVz IHdpbGwgYmUgZGlmZmVyZW50LiBUaGUgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IG9uZQog ICAgICBtdXN0IHZhbGlkYXRlIGFuIEVDRFNBIHNpZ25hdHVyZSBieSBzdWJtaXR0aW5nIHRoZSBw cmV2aW91c2x5CiAgICAgIHNwZWNpZmllZCBpbnB1dHMgdG8gYW4gRUNEU0EgdmFsaWRhdG9yLjwv dD4KCiAgICAgIDx0PlNpZ25pbmcgd2l0aCB0aGUgRUNEU0EgUC0zODQgU0hBLTM4NCBhbmQgRUNE U0EgUC01MjEgU0hBLTUxMiBhbGdvcml0aG1zIGlzCiAgICAgIHBlcmZvcm1lZCBpZGVudGljYWxs eSB0byB0aGUgcHJvY2VkdXJlIGZvciBFQ0RTQSBQLTI1NiBTSEEtMjU2IC0ganVzdAogICAgICB3 aXRoIGNvcnJlc3BvbmRpbmdseSBsb25nZXIga2V5IGFuZCByZXN1bHQgdmFsdWVzLjwvdD4KCiAg ICAgIDx0Pkl0IGlzIFJFQ09NTUVOREVEIHRoYXQgSldUIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0 IHRoZSBFQ0RTQQogICAgICBQLTI1NiBTSEEtMjU2IGFsZ29yaXRobS4gIFN1cHBvcnQgZm9yIHRo ZSBFQ0RTQSBQLTM4NCBTSEEtMzg0CiAgICAgIGFuZCBFQ0RTQSBQLTUyMSBTSEEtNTEyIGFsZ29y aXRobXMgaXMgT1BUSU9OQUwuPC90PgoKICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRs ZT0iQWRkaXRpb25hbCBBbGdvcml0aG1zIj4KCiAgICAgIDx0PkFkZGl0aW9uYWwgYWxnb3JpdGht cyBNQVkgYmUgdXNlZCB0byBwcm90ZWN0IEpXVHMgd2l0aAogICAgICBjb3JyZXNwb25kaW5nICJh bGciIGVudmVsb3BlIHBhcmFtZXRlciB2YWx1ZXMgYmVpbmcgZGVmaW5lZCB0bwogICAgICByZWZl ciB0byB0aGVtLiBMaWtlIGNsYWltIG5hbWVzLCBuZXcgImFsZyIgZW52ZWxvcGUgcGFyYW1ldGVy CiAgICAgIHZhbHVlcyBTSE9VTEQgZWl0aGVyIGJlIGRlZmluZWQgaW4gdGhlIElBTkEgSlNPTiBX ZWIgVG9rZW4KICAgICAgQWxnb3JpdGhtcyByZWdpc3RyeSBvciBiZSBhIFVSSSB0aGF0IGNvbnRh aW5zIGEgY29sbGlzaW9uCiAgICAgIHJlc2lzdGFudCBuYW1lc3BhY2UuICBJbiBwYXJ0aWN1bGFy LCB0aGUgdXNlIG9mIGFsZ29yaXRobQogICAgICBpZGVudGlmaWVycyBkZWZpbmVkIGluIDx4cmVm IHRhcmdldD0iUkZDMzI3NSI+WE1MIERTSUc8L3hyZWY+CiAgICAgIGFuZCByZWxhdGVkIHNwZWNp ZmljYXRpb25zIGlzIHBlcm1pdHRlZC48L3Q+CgogICAgPC9zZWN0aW9uPgogIDwvc2VjdGlvbj4K CiAgICA8c2VjdGlvbiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyIgYW5jaG9yPSJJQU5BIj4K ICAgICAgPHQ+VGhpcyBzcGVjaWZpY2F0aW9uIGNhbGxzIGZvcjoKICAgICAgICA8bGlzdCBzdHls ZT0ic3ltYm9scyI+CgogICAgICAgICAgPHQ+QSBuZXcgSUFOQSByZWdpc3RyeSBlbnRpdGxlZCAi SlNPTiBXZWIgVG9rZW4gQ2xhaW1zIiBmb3IKICAgICAgICAgIHJlc2VydmVkIGNsYWltIG5hbWVz IDx4cmVmCiAgICAgICAgICB0YXJnZXQ9IlJlc2VydmVkQ2xhaW1OYW1lIj48L3hyZWY+IHVzZWQg aW4gYSBEZWNvZGVkIEpXVAogICAgICAgICAgQ2xhaW0gU2VnbWVudC4gSW5jbHVzaW9uIGluIHRo ZSByZWdpc3RyeSBpcyBSRkMgUmVxdWlyZWQgaW4KICAgICAgICAgIHRoZSA8eHJlZiB0YXJnZXQ9 IlJGQzUyMjYiPlJGQyA1MjI2PC94cmVmPiBzZW5zZSBmb3IKICAgICAgICAgIHJlc2VydmVkIEpX VCBjbGFpbSBuYW1lcyB0aGF0IGFyZSBpbnRlbmRlZCB0byBiZQogICAgICAgICAgaW50ZXJvcGVy YWJsZSBiZXR3ZWVuIGltcGxlbWVudGF0aW9ucy4gIFRoZSByZWdpc3RyeSB3aWxsCiAgICAgICAg ICBqdXN0IHJlY29yZCB0aGUgcmVzZXJ2ZWQgY2xhaW0gbmFtZSBhbmQgYSBwb2ludGVyIHRvIHRo ZSBSRkMKICAgICAgICAgIHRoYXQgZGVmaW5lcyBpdC4gVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmlu ZXMgaW5jbHVzaW9uIG9mIHRoZQogICAgICAgICAgY2xhaW0gbmFtZXMgZGVmaW5lZCBpbiA8eHJl ZgogICAgICAgICAgdGFyZ2V0PSJDbGFpbVRhYmxlIj48L3hyZWY+LjwvdD4KCiAgICAgICAgICA8 dD5BIG5ldyBJQU5BIHJlZ2lzdHJ5IGVudGl0bGVkICJKU09OIFdlYiBUb2tlbiBFbnZlbG9wZQog ICAgICAgICAgUGFyYW1ldGVycyIgZm9yIHJlc2VydmVkIGVudmVsb3BlIHBhcmFtZXRlciBuYW1l cyA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJSZXNlcnZlZEVudmVsb3BlUGFyYW1ldGVyTmFtZSI+ PC94cmVmPiB1c2VkIGluIGEKICAgICAgICAgIERlY29kZWQgSldUIEVudmVsb3BlIFBhcmFtZXRl ciBTZWdtZW50LiBJbmNsdXNpb24gaW4gdGhlCiAgICAgICAgICByZWdpc3RyeSBpcyBSRkMgUmVx dWlyZWQgaW4gdGhlIDx4cmVmIHRhcmdldD0iUkZDNTIyNiI+UkZDCiAgICAgICAgICA1MjI2PC94 cmVmPiBzZW5zZSBmb3IgcmVzZXJ2ZWQgSldUIGVudmVsb3BlIHBhcmFtZXRlciBuYW1lcwogICAg ICAgICAgdGhhdCBhcmUgaW50ZW5kZWQgdG8gYmUgaW50ZXJvcGVyYWJsZSBiZXR3ZWVuCiAgICAg ICAgICBpbXBsZW1lbnRhdGlvbnMuICBUaGUgcmVnaXN0cnkgd2lsbCBqdXN0IHJlY29yZCB0aGUg cmVzZXJ2ZWQKICAgICAgICAgIGVudmVsb3BlIHBhcmFtZXRlciBuYW1lIGFuZCBhIHBvaW50ZXIg dG8gdGhlIFJGQyB0aGF0CiAgICAgICAgICBkZWZpbmVzIGl0LiBUaGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBpbmNsdXNpb24gb2YgdGhlCiAgICAgICAgICBlbnZlbG9wZSBwYXJhbWV0ZXIgbmFt ZXMgZGVmaW5lZCBpbiA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJFbnZlbG9wZVBhcmFtZXRlclRh YmxlIj48L3hyZWY+LjwvdD4KCiAgICAgICAgICA8dD5BIG5ldyBJQU5BIHJlZ2lzdHJ5IGVudGl0 bGVkICJKU09OIFdlYiBUb2tlbiBBbGdvcml0aG1zIgogICAgICAgICAgZm9yIHJlc2VydmVkIHZh bHVlcyB1c2VkIHdpdGggdGhlICJhbGciIGVudmVsb3BlIHBhcmFtZXRlcgogICAgICAgICAgdmFs dWVzIHVzZWQgaW4gYSBkZWNvZGVkIEpXVCBFbnZlbG9wZSBTZWdtZW50LiBJbmNsdXNpb24gaW4K ICAgICAgICAgIHRoZSByZWdpc3RyeSBpcyBSRkMgUmVxdWlyZWQgaW4gdGhlIDx4cmVmCiAgICAg ICAgICB0YXJnZXQ9IlJGQzUyMjYiPlJGQyA1MjI2PC94cmVmPiBzZW5zZS4gVGhlIHJlZ2lzdHJ5 IHdpbGwKICAgICAgICAgIGp1c3QgcmVjb3JkIHRoZSAiYWxnIiB2YWx1ZSBhbmQgYSBwb2ludGVy IHRvIHRoZSBSRkMgdGhhdAogICAgICAgICAgZGVmaW5lcyBpdC4gIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIGluY2x1c2lvbiBvZiB0aGUKICAgICAgICAgIGFsZ29yaXRobSB2YWx1ZXMgZGVm aW5lZCBpbiA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJBbGdUYWJsZSI+PC94cmVmPi48L3Q+CiAg ICAgICAgPC9saXN0PjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMiIGFuY2hvcj0iU2VjdXJpdHkiPgogICAgICA8dD5UQkQ6IExv dHMgb2Ygd29yayB0byBkbyBoZXJlLiBXZSBuZWVkIHRvIHJlbWVtYmVyIHRvIGxvb2sKICAgICAg aW50byBhbnkgaXNzdWVzIHJlbGF0aW5nIHRvIHNlY3VyaXR5IGFuZCBKU09OIHBhcnNpbmcuIE9u ZQogICAgICB3b25kZXJzIGp1c3QgaG93IHNlY3VyZSBtb3N0IEpTT04gcGFyc2luZyBsaWJyYXJp ZXMgYXJlLiBXZXJlCiAgICAgIHRoZXkgZXZlciBoYXJkZW5lZCBmb3Igc2VjdXJpdHkgc2NlbmFy aW9zPyBJZiBub3QsIHdoYXQga2luZCBvZgogICAgICBob2xlcyBkb2VzIHRoYXQgb3BlbiB1cD8g QWxzbywgd2UgbmVlZCB0byB3YWxrIHRocm91Z2ggdGhlIEpTT04KICAgICAgc3RhbmRhcmQgYW5k IHNlZSB3aGF0IGtpbmQgb2YgaXNzdWVzIHdlIGhhdmUgZXNwZWNpYWxseSBhcm91bmQKICAgICAg Y29tcGFyaXNvbiBvZiBuYW1lcy4gIEZvciBpbnN0YW5jZSwgY29tcGFyaXNvbnMgb2YgY2xhaW0g bmFtZXMKICAgICAgYW5kIG90aGVyIHBhcmFtZXRlcnMgbXVzdCBvY2N1ciBhZnRlciB0aGV5IGFy ZSB1bmVzY2FwZWQuIE5lZWQKICAgICAgdG8gYWxzbyBwdXQgaW4gdGV4dCBhYm91dDogSW1wb3J0 YW5jZSBvZiBrZWVwaW5nIHNlY3JldHMKICAgICAgc2VjcmV0LiBSb3RhdGluZyBrZXlzLiBTdHJl bmd0aHMgYW5kIHdlYWtuZXNzZXMgb2YgdGhlIGRpZmZlcmVudAogICAgICBhbGdvcml0aG1zLiBD YXNlIHNlbnNpdGl2aXR5IGFuZCBtb3JlIGdlbmVyYWxseSBVbmljb2RlCiAgICAgIGNvbXBhcmlz b24gaXNzdWVzIHRoYXQgY2FuIGNhdXNlIHNlY3VyaXR5IGhvbGVzLCBlc3BlY2lhbGx5IGluCiAg ICAgIGNsYWltIG5hbWVzIGFuZCBleHBsYWluIHdoeSBVbmljb2RlIE5vcm1hbGl6YXRpb24gaXMg c3VjaCBhCiAgICAgIHByb2JsZW0uPC90PgoKICAgICAgPHQ+VEJEOiBOZWVkIHRvIHB1dCBpbiB0 ZXh0IGFib3V0IHdoeSBzdHJpY3QgSlNPTiB2YWxpZGF0aW9uIGlzIG5lY2Vzc2FyeS4KICAgICAg QmFzaWNhbGx5LCB0aGF0IGlmIG1hbGZvcm1lZCBKU09OIGlzIHJlY2VpdmVkIHRoZW4gdGhlIGlu dGVudCBvZiB0aGUKICAgICAgc2VuZGVyIGlzIGltcG9zc2libGUgdG8gcmVsaWFibHkgZGlzY2Vy bi4gV2hpbGUgaW4gbm9uLXNlY3VyaXR5CiAgICAgIGNvbnRleHRzIGl0J3Mgby5rLiB0byBiZSBn ZW5lcm91cyBpbiB3aGF0IG9uZSBhY2NlcHRzLCBpbiBzZWN1cml0eQogICAgICBjb250ZXh0cyB0 aGlzIGNhbiBsZWFkIHRvIHNlcmlvdXMgc2VjdXJpdHkgaG9sZXMuIEZvciBleGFtcGxlLCBtYWxm b3JtZWQKICAgICAgSlNPTiBtaWdodCBpbmRpY2F0ZSB0aGF0IHNvbWVvbmUgaGFzIG1hbmFnZWQg dG8gZmluZCBhIHNlY3VyaXR5IGhvbGUgaW4KICAgICAgdGhlIGlzc3VlcidzIGNvZGUgYW5kIGlz IGxldmVyYWdpbmcgaXQgdG8gZ2V0IHRoZSBpc3N1ZXIgdG8gaXNzdWUgImJhZCIKICAgICAgdG9r ZW5zIHdob3NlIGNvbnRlbnQgdGhlIGF0dGFja2VyIGNhbiBjb250cm9sLjwvdD4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSJVbmljb2RlIENvbXBhcmlzb24gU2VjdXJpdHkgSXNzdWVzIj4KCiAgICAg ICAgPHQ+Q2xhaW0gbmFtZXMgaW4gSldUcyBhcmUgVW5pY29kZSBzdHJpbmdzLiAgRm9yIHNlY3Vy aXR5CiAgICAgICAgcmVhc29ucywgdGhlIHJlcHJlc2VudGF0aW9ucyB0aGVzZSBuYW1lcyBtdXN0 IGJlIGNvbXBhcmVkIHZlcmJhdGltIGFmdGVyIHBlcmZvcm1pbmcKICAgICAgICBhbnkgZXNjYXBl IHByb2Nlc3NpbmcgKGFzIHBlciA8eHJlZiB0YXJnZXQ9IlJGQzQ2MjciPlJGQwogICAgICAgIDQ2 Mjc8L3hyZWY+LCBTZWN0aW9uIDIuNSkuICBJbiBwYXJ0aWN1bGFyLCA8eHJlZgogICAgICAgIHRh cmdldD0iVVNBMTUiPlVuaWNvZGUgTm9ybWFsaXphdGlvbjwveHJlZj4gb3IgY2FzZSBmb2xkaW5n CiAgICAgICAgTVVTVCBOT1QgYmUgYXBwbGllZCBhdCBhbnkgcG9pbnQgdG8gZWl0aGVyIHRoZSBK U09OIHN0cmluZyBvcgogICAgICAgIHRvIHRoZSBzdHJpbmcgaXQgaXMgdG8gYmUgY29tcGFyZWQg YWdhaW5zdC48L3Q+CgogICAgICAgIDx0PlRoaXMgbWVhbnMsIGZvciBpbnN0YW5jZSwgdGhhdCB0 aGVzZSBKU09OIHN0cmluZ3MgbXVzdAogICAgICAgIGNvbXBhcmUgYXMgYmVpbmcgZXF1YWwgKCJK V1QiLCAiXHUwMDRhV1QiKSwgd2hlcmVhcyB0aGVzZSBtdXN0CiAgICAgICAgYWxsIGNvbXBhcmUg YXMgYmVpbmcgbm90IGVxdWFsIHRvIHRoZSBmaXJzdCBzZXQgb3IgdG8gZWFjaCBvdGhlcgogICAg ICAgICgiand0IiwgIkp3dCIsICJKV1x1MDA3NCIpLjwvdD4KCgk8dD5KU09OIHN0cmluZ3MgTUFZ IGNvbnRhaW4gY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBVbmljb2RlCiAgICAgICAgQmFzaWMgTXVs dGlsaW5ndWFsIFBsYW5lLiAgRm9yIGluc3RhbmNlLCB0aGUgRyBjbGVmIGNoYXJhY3RlcgogICAg ICAgIChVKzFEMTFFKSBtYXkgYmUgcmVwcmVzZW50ZWQgaW4gYSBKU09OIHN0cmluZyBhcwogICAg ICAgICJcdUQ4MzRcdUREMUUiLiAgSWRlYWxseSwgSldUIGltcGxlbWVudGF0aW9ucyBTSE9VTEQg ZW5zdXJlCiAgICAgICAgdGhhdCBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIEJhc2ljIE11bHRpbGlu Z3VhbCBQbGFuZSBhcmUKICAgICAgICBwcmVzZXJ2ZWQgYW5kIGNvbXBhcmVkIGNvcnJlY3RseTsg YWx0ZXJuYXRpdmVseSwgaWYgdGhpcyBpcwogICAgICAgIG5vdCBwb3NzaWJsZSBkdWUgdG8gdGhl c2UgY2hhcmFjdGVycyBleGVyY2lzaW5nIGxpbWl0YXRpb25zCiAgICAgICAgcHJlc2VudCBpbiB0 aGUgdW5kZXJseWluZyBKU09OIGltcGxlbWVudGF0aW9uLCB0aGVuIGlucHV0CiAgICAgICAgY29u dGFpbmluZyB0aGVtIE1VU1QgYmUgcmVqZWN0ZWQuPC90PgoKICAgICAgPC9zZWN0aW9uPgogICAg PC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJPcGVuIElzc3VlcyIgYW5jaG9yPSJPcGVu SXNzdWVzIj4KCiAgICAgIDx0PlRoZSBmb2xsb3dpbmcgb3BlbiBpc3N1ZXMgaGF2ZSBiZWVuIGlk ZW50aWZpZWQgZHVyaW5nIHJldmlldwogICAgICBvZiBwcmV2aW91cyBkcmFmdHMuICBBZGRpdGlv bmFsIGlucHV0IG9uIHRoZW0gaXMgc29saWNpdGVkLjwvdD4KCiAgICAgIDxsaXN0IHN0eWxlPSJz eW1ib2xzIj4KCiAgICAgICAgPHQ+VGhlIGRyYWZ0IGN1cnJlbnRseSBkZWZpbmVzIG5vIG1lY2hh bmlzbShzKSBmb3IgcmV0cmlldmluZwogICAgICAgIHB1YmxpYyBrZXlzIHRoYXQgYXJlIG5vdCBl bmNvZGVkIGFzIFguNTA5IGNlcnRpZmljYXRlcy4gIEEKICAgICAgICBtZWNoYW5pc20gb3IgbWVj aGFuaXNtcyBzaW1pbGFyIHRvIHRoZSBNYWdpYyBTaWduYXR1cmVzIGtleQogICAgICAgIGRpc2Nv dmVyeSBwcm9jZXNzIGZvciBNYWdpYyBLZXlzIGNvdWxkIGJlIGFkZGVkIHRvIGZ1dHVyZQogICAg ICAgIGRyYWZ0cy4gIFNvbWUgaGF2ZSBzdWdnZXN0ZWQgdGhhdCB0aGV5IGtleXMgdGhlbXNlbHZl cyBhbHNvIGJlCiAgICAgICAgZW5jb2RlZCBhcyBKV1RzLjwvdD4KCgk8dD5SZWxhdGVkIHRvIHRo ZSBhYm92ZSwgaXQncyBub3QgY2xlYXIgd2hldGhlciB0aGUgImlzcyIKCWNsYWltIHNob3VsZCBi ZSBleHBlY3RlZCB0byBjb250YWluIGEgbG9jYXRpb24gZm9yIHJldHJpZXZpbmcKCW5vbi1YLjUw OSBwdWJsaWMga2V5cywgb3Igd2hldGhlciBhIHNlcGFyYXRlIGlzc3VlciBrZXkKCWxvY2F0aW9u IHBhcmFtZXRlciBzaG91bGQgYmUgZGVmaW5lZC4gIEFsc28sIGRvZXMgdGhpcyBiZWxvbmcKCWlu IHRoZSBlbnZlbG9wZSBvciB0aGUgY2xhaW1zPzwvdD4KCiAgICAgIDwvbGlzdD4KICAgIDwvc2Vj dGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iQWNrbm93bGVkZ2VtZW50cyIgYW5jaG9yPSJBY2tu b3dsZWRnZW1lbnRzIj4KCiAgICAgIDx0PlRoZSBhdXRob3JzIGFja25vd2xlZGdlIHRoYXQgdGhl IGRlc2lnbiBvZiBKV1RzIHdhcwogICAgICBpbnRlbnRpb25hbGx5IGluZmx1ZW5jZWQgYnkgdGhl IGRlc2lnbiBhbmQgc2ltcGxpY2l0eSBvZiA8eHJlZgogICAgICB0YXJnZXQ9IlNXVCI+U2ltcGxl IFdlYiBUb2tlbnM8L3hyZWY+LiAgU29sdXRpb25zIGZvciBzaWduaW5nCiAgICAgIEpTT04gdG9r ZW5zIHdlcmUgYWxzbyBwcmV2aW91c2x5IGV4cGxvcmVkIGJ5IDx4cmVmCiAgICAgIHRhcmdldD0i TWFnaWNTaWduYXR1cmVzIj5NYWdpYyBTaWduYXR1cmVzPC94cmVmPiwgPHhyZWYKICAgICAgdGFy Z2V0PSJKU1MiPkpTT04gU2ltcGxlIFNpZ248L3hyZWY+LCBhbmQgPHhyZWYKICAgICAgdGFyZ2V0 PSJDYW52YXNBcHAiPkNhbnZhcyBBcHBsaWNhdGlvbnM8L3hyZWY+LCBhbGwgb2Ygd2hpY2ggaW5m bHVlbmNlZCB0aGlzIGRyYWZ0LjwvdD4KCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0 bGU9IkFwcGVuZGl4IC0gTm9uLU5vcm1hdGl2ZSAtIEpXVCBFeGFtcGxlcyIgYW5jaG9yPSJKV1RF eGFtcGxlcyI+CgogICAgICA8c2VjdGlvbiB0aXRsZT0iSldUIHVzaW5nIEhNQUMgU0hBLTI1NiIg YW5jaG9yPSJITUFDU0hBMjU2RXhhbXBsZSI+CgkJICA8c2VjdGlvbiB0aXRsZT0iRW5jb2Rpbmci PgogICAgICAgIDx0PlRoZSBEZWNvZGVkIEpXVCBDbGFpbSBTZWdtZW50IHVzZWQgaW4gdGhpcyBl eGFtcGxlIGlzOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW3siaXNzIjoiam9lIiwKICJl eHAiOjEzMDA4MTkzODAsCiAiaHR0cDovL2V4YW1wbGUuY29tL2lzX3Jvb3QiOnRydWV9XV0+PC9h cnR3b3JrPgoKICAgIDx0Pk5vdGUgdGhhdCB3aGl0ZSBzcGFjZSBpcyBleHBsaWNpdGx5IGFsbG93 ZWQgaW4gRGVjb2RlZCBKV1QgQ2xhaW0gU2VnbWVudHMKICAgIGFuZCBubyBjYW5vbmljYWxpemF0 aW9uIGlzIHBlcmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuIFRoZQogICAgZm9sbG93aW5nIGJ5dGUg YXJyYXkgY29udGFpbnMgdGhlIFVURi04IGNoYXJhY3RlcnMgZm9yIHRoZQogICAgRGVjb2RlZCBK V1QgQ2xhaW0gU2VnbWVudDo8L3Q+CgogICAgPHQ+CgpbMTIzLCAzNCwgMTA1LCAxMTUsIDExNSwg MzQsIDU4LCAzNCwgMTA2LCAxMTEsIDEwMSwgMzQsCiAgNDQsIDEzLCAxMCwgMzIsIDM0LCAxMDEs IDEyMCwgMTEyLCAzNCwgNTgsIDQ5LCA1MSwKICA0OCwgNDgsIDU2LCA0OSwgNTcsIDUxLCA1Niwg NDgsIDQ0LCAxMywgMTAsIDMyLCAzNCwKICAxMDQsIDExNiwgMTE2LCAxMTIsIDU4LCA0NywgNDcs IDEwMSwgMTIwLCA5NywgMTA5LCAxMTIsCiAgMTA4LCAxMDEsIDQ2LCA5OSwgMTExLCAxMDksIDQ3 LCAxMDUsIDExNSwgOTUsIDExNCwgMTExLAogIDExMSwgMTE2LCAzNCwKNTgsIDExNiwgMTE0LCAx MTcsIDEwMSwgMTI1XQoKICAgIDwvdD4KCiAgICA8dD5CYXNlNjR1cmwgZW5jb2RpbmcgdGhlIGFi b3ZlIHlpZWxkcyB0aGUgSldUIENsYWltIFNlZ21lbnQgdmFsdWU6PC90PgoKICAgICAgPGFydHdv cms+PCFbQ0RBVEFbZXlKcGMzTWlPaUpxYjJVaUxBMEtJQ0psZUhBaU9qRXpNREE0TVRrek9EQXNE UW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUV1dPjwvYXJ0 d29yaz4KCiAgICAgIDx0PlRoZSBmb2xsb3dpbmcgZXhhbXBsZSBKU09OIGVudmVsb3BlIG9iamVj dCBkZWNsYXJlcyB0aGF0IHRoZQogICAgICBlbmNvZGVkIG9iamVjdCBpcyBhIEpTT04gV2ViIFRv a2VuIChKV1QpIGFuZCB0aGUgSldUIENsYWltCiAgICAgIFNlZ21lbnQgaXMgc2lnbmVkIHVzaW5n IHRoZSBITUFDIFNIQS0yNTYgYWxnb3JpdGhtOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRB W3sidHlwIjoiSldUIiwKICJhbGciOiJIUzI1NiJ9XV0+PC9hcnR3b3JrPgoKICAgICAgPHQ+IFRo ZSBmb2xsb3dpbmcgYnl0ZSBhcnJheSBjb250YWlucyB0aGUgVVRGLTggY2hhcmFjdGVycyBmb3IK ICAgICAgdGhlIERlY29kZWQgSldUIEVudmVsb3BlIFNlZ21lbnQ6PC90PgoKICAgIDx0PgoKWzEy MywgMzQsIDExNiwgMTIxLCAxMTIsIDM0LCA1OCwgMzQsIDc0LCA4NywgODQsIDM0LAogIDQ0LCAx MywgMTAsIDMyLCAzNCwgOTcsIDEwOCwgMTAzLCAzNCwgNTgsIDM0LCA3MiwgODMsCiAgNTAsIDUz LCA1NCwgMzQsIDEyNV0KCiAgICA8L3Q+CgogICAgICA8dD5CYXNlNjR1cmwgZW5jb2RpbmcgdGhp cyBVVEYtOCByZXByZXNlbnRhdGlvbiB5aWVsZHMgdGhpcyBKV1QKICAgICAgRW52ZWxvcGUgU2Vn bWVudCB2YWx1ZTo8L3Q+CgogICAgICA8YXJ0d29yaz48IVtDREFUQVtleUowZVhBaU9pSktWMVFp TEEwS0lDSmhiR2NpT2lKSVV6STFOaUo5XV0+PC9hcnR3b3JrPgoKICAgIDx0PkhNQUNzIGFyZSBn ZW5lcmF0ZWQgdXNpbmcga2V5cy4gVGhpcyBleGFtcGxlIHVzZWQgdGhlCiAgICBrZXkgcmVwcmVz ZW50ZWQgYnkgdGhlIGZvbGxvd2luZyBieXRlIGFycmF5OjwvdD4KCiAgICA8dD4KCls4MywgMTU5 LCAxMTcsIDEyLCAyMzUsIDE2OSwgMTY4LCAyMDAsIDEzMSwgMTUyLCAyMjcsCiAgMjQ2LCAyMTQs IDIxMiwgMTg4LCA3NCwgNzEsIDgzLCAyNDQsIDE2NiwgOTAsIDI0LCAyMzksCiAgMjUxLCAzMiwg MTI0LCA2LCAyMDEsIDE5NCwgMTA0LCAyNDEsIDYyLCAxNzQsIDI0NiwgNjUsCiAgMTExLCA0OSwg NTIsIDIxMCwgMTE4LCAyMTIsIDEyNCwgMzQsIDg4LCAxNjcsIDExMiwgODQsCiAgODgsIDgzLCA2 NSwgMTU1LCAxOCwgMjM0LCAyNTAsIDIyNCwgMTAxLCAxNDcsIDIyMSwgMjMsCiAgMTA0LCAyMTks IDE3MCwgMTQ2LCAyMTVdCiAgICAKICAgIDwvdD4KCiAgICA8dD5SdW5uaW5nIHRoZSBITUFDIFNI QS0yNTYgYWxnb3JpdGhtIG9uIHRoZSBKV1QgQ2xhaW0gU2VnbWVudAogICAgd2l0aCB0aGlzIGtl eSB5aWVsZHMgdGhlIGZvbGxvd2luZyBieXRlIGFycmF5OjwvdD4KCiAgICA8dD4KClsyMjMsIDE1 NSwgMTcyLCA5MCwgNjMsIDg3LCAyNDAsIDEyNCwgNiwgNzUsIDIyNCwgMTMxLAogIDExNSwgMjks IDczLCA2MywgOTksIDEwMiwgMTY5LCAyMDIsIDIwMywgMTkzLCAxNTgsIDQsCiAgNDIsIDE1OSwg NDQsIDUzLCA1NiwgOTUsIDIyMSwgMTk4XQoKICAgIDwvdD4KCiAgICA8dD5CYXNlNjR1cmwgZW5j b2RpbmcgdGhlIGFib3ZlIEhNQUMgb3V0cHV0IHlpZWxkcyB0aGUgSldUIENyeXB0byBTZWdtZW50 IHZhbHVlOjwvdD4KCiAgICA8YXJ0d29yaz48IVtDREFUQVszNXVzV2o5WDhId0dTLUNEY3gxSlAy Tm1xY3JMd1o0RUtwOHNOVGhmM2NZXV0+PC9hcnR3b3JrPgoKICAgICAgPHQ+Q29tYmluaW5nIHRo ZXNlIHNlZ21lbnRzIGluIHRoZSBvcmRlcgogICAgICBFbnZlbG9wZS5DbGFpbXMuU2lnbmF0dXJl IHdpdGggcGVyaW9kIGNoYXJhY3RlcnMgYmV0d2VlbiB0aGUKICAgICAgc2VnbWVudHMgeWllbGRz IHRoaXMgY29tcGxldGUgSldUICh3aXRoIGxpbmUgYnJlYWtzIGZvciBkaXNwbGF5CiAgICAgIHB1 cnBvc2VzIG9ubHkpOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW2V5SjBlWEFpT2lKS1Yx UWlMQTBLSUNKaGJHY2lPaUpJVXpJMU5pSjkKLgpleUpwYzNNaU9pSnFiMlVpTEEwS0lDSmxlSEFp T2pFek1EQTRNVGt6T0RBc0RRb2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJ anAwY25WbGZRCi4KMzV1c1dqOVg4SHdHUy1DRGN4MUpQMk5tcWNyTHdaNEVLcDhzTlRoZjNjWV1d PjwvYXJ0d29yaz4KCjwvc2VjdGlvbj4KPHNlY3Rpb24gdGl0bGU9IkRlY29kaW5nIj4KCiAgICAg IDx0PkRlY29kaW5nIHRoZSBKV1QgZmlyc3QgcmVxdWlyZXMgcmVtb3ZpbmcgdGhlIGJhc2U2NHVy bAogICAgICBlbmNvZGluZyBmcm9tIHRoZSBKV1QgRW52ZWxvcGUgU2VnbWVudCBhbmQgdGhlIEpX VCBDbGFpbQogICAgICBTZWdtZW50LiBXZSBiYXNlNjR1cmwgZGVjb2RlIHRoZSBzZWdtZW50cyBw ZXIgPHhyZWYKICAgICAgdGFyZ2V0PSJiYXNlNjR1cmxsb2dpYyI+PC94cmVmPiBhbmQgdHVybiB0 aGVtIGludG8gdGhlCiAgICAgIGNvcnJlc3BvbmRpbmcgVVRGLTggYnl0ZSBhcnJheXMsIHdoaWNo IHdlIHRoZW4gdHJhbnNsYXRlIGludG8KICAgICAgdGhlIERlY29kZWQgSldUIEVudmVsb3BlIFNl Z21lbnQgYW5kIERlY29kZWQgSldUIENsYWltIFNlZ21lbnQKICAgICAgc3RyaW5ncy48L3Q+Cgo8 L3NlY3Rpb24+CjxzZWN0aW9uIHRpdGxlPSJWYWxpZGF0aW5nIj4KCiAgICAgIDx0Pk5leHQgd2Ug dmFsaWRhdGUgdGhlIGRlY29kZWQgcmVzdWx0cy4gIFNpbmNlIHRoZSAiYWxnIgogICAgICBwYXJh bWV0ZXIgaW4gdGhlIGVudmVsb3BlIGlzICJIUzI1NiIsIHdlIHZhbGlkYXRlIHRoZSBITUFDCiAg ICAgIFNIQS0yNTYgc2lnbmF0dXJlIGNvbnRhaW5lZCBpbiB0aGUgSldUIENyeXB0byBTZWdtZW50 LiAgSWYgYW55CiAgICAgIG9mIHRoZSB2YWxpZGF0aW9uIHN0ZXBzIGZhaWwsIHRoZSB0b2tlbiBN VVNUIGJlIHJlamVjdGVkLjwvdD4KCiAgICAgIDx0PkZpcnN0LCB3ZSB2YWxpZGF0ZSB0aGF0IHRo ZSBkZWNvZGVkIGVudmVsb3BlIGFuZCBjbGFpbQogICAgICBzZWdtZW50IHN0cmluZ3MgYXJlIGJv dGggbGVnYWwgSlNPTi48L3Q+CgogICAgICA8dD5UbyB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlLCB3 ZSByZXBlYXQgdGhlIHByZXZpb3VzIHByb2Nlc3Mgb2YKICAgICAgdXNpbmcgdGhlIGNvcnJlY3Qg a2V5IGFuZCB0aGUgSldUIENsYWltIFNlZ21lbnQgYXMgaW5wdXQgdG8gYQogICAgICBTSEEtMjU2 IEhNQUMgZnVuY3Rpb24gYW5kIHRoZW4gdGFraW5nIHRoZSBvdXRwdXQsIGJhc2U2NHVybAogICAg ICBlbmNvZGluZyBpdCwgYW5kIGRldGVybWluaW5nIGlmIGl0IG1hdGNoZXMgdGhlIEpXVCBDcnlw dG8KICAgICAgU2VnbWVudCBpbiB0aGUgSldULiAgSWYgaXQgbWF0Y2hlcyBleGFjdGx5LCB0aGUg dG9rZW4gaGFzIGJlZW4KICAgICAgdmFsaWRhdGVkLjwvdD4KCiAgICA8L3NlY3Rpb24+CiAgPC9z ZWN0aW9uPgoKICA8c2VjdGlvbiB0aXRsZT0iSldUIHVzaW5nIFJTQSBTSEEtMjU2Ij4KCiAgICA8 c2VjdGlvbiB0aXRsZT0iRW5jb2RpbmciPgogICAgICA8dD5UaGUgRGVjb2RlZCBKV1QgQ2xhaW0g U2VnbWVudCB1c2VkIGluIHRoaXMgZXhhbXBsZSBpcyB0aGUgc2FtZSBhcyBpbiB0aGUgcHJldmlv dXMgZXhhbXBsZTo8L3Q+CgogICAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW3siaXNzIjoiam9lIiwK ICJleHAiOjEzMDA4MTkzODAsCiAiaHR0cDovL2V4YW1wbGUuY29tL2lzX3Jvb3QiOnRydWV9XV0+ PC9hcnR3b3JrPgoKICAgICAgPHQ+U2luY2UgdGhlIEpXVCBDbGFpbSBTZWdtZW50IHdpbGwgdGhl cmVmb3JlIGJlIHRoZSBzYW1lLCBpdHMKICAgICAgY29tcHV0YXRpb24gaXMgbm90IHJlcGVhdGVk IGhlcmUuICBIb3dldmVyLCB0aGUgRGVjb2RlZCBKV1QKICAgICAgRW52ZWxvcGUgU2VnbWVudCBp cyBkaWZmZXJlbnQgaW4gdHdvIHdheXM6IEZpcnN0LCBiZWNhdXNlIGEKICAgICAgZGlmZmVyZW50 IGFsZ29yaXRobSBpcyBiZWluZyB1c2VkLCB0aGUgImFsZyIgdmFsdWUgaXMKICAgICAgZGlmZmVy ZW50LiAgU2Vjb25kLCBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvc2VzIG9ubHksIHRoZQogICAgICBv cHRpb25hbCAidHlwIiBwYXJhbWV0ZXIgaXMgbm90IHVzZWQuICAoVGhpcyBkaWZmZXJlbmNlIGlz IG5vdAogICAgICByZWxhdGVkIHRvIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGVtcGxveWVkLikg IFRoZSBEZWNvZGVkIEpXVAogICAgICBFbnZlbG9wZSBTZWdtZW50IHVzZWQgaXM6PC90PgoKICAg ICAgPGFydHdvcms+PCFbQ0RBVEFbeyJhbGciOiJSUzI1NiJ9XV0+PC9hcnR3b3JrPgoKICAgICAg PHQ+IFRoZSBmb2xsb3dpbmcgYnl0ZSBhcnJheSBjb250YWlucyB0aGUgVVRGLTggY2hhcmFjdGVy cyBmb3IKICAgICAgdGhlIERlY29kZWQgSldUIEVudmVsb3BlIFNlZ21lbnQ6PC90PgoKICAgIDx0 PgoKIFsxMjMsIDM0LCA5NywgMTA4LCAxMDMsIDM0LCA1OCwgMzQsIDgyLCA4MywgNTAsIDUzLAog IDU0LCAzNCwgMTI1XQoKICAgIDwvdD4KCiAgICAgIDx0PkJhc2U2NHVybCBlbmNvZGluZyB0aGlz IFVURi04IHJlcHJlc2VudGF0aW9uIHlpZWxkcyB0aGlzIEpXVAogICAgICBFbnZlbG9wZSBTZWdt ZW50IHZhbHVlOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW2V5SmhiR2NpT2lKU1V6STFO aUo5XV0+PC9hcnR3b3JrPgoKICAgICAgICA8dD5UaGUgUlNBIGtleSBjb25zaXN0cyBvZiBhIHB1 YmxpYyBwYXJ0IChuLCBlKSwgYW5kIGEKICAgICAgICBwcml2YXRlIGV4cG9uZW50IGQuICBUaGUg dmFsdWVzIG9mIHRoZSBSU0Ega2V5IHVzZWQgaW4gdGhpcwogICAgICAgIGV4YW1wbGUsIHByZXNl bnRlZCBhcyB0aGUgYnl0ZSBhcnJheXMgcmVwcmVzZW50aW5nCiAgICAgICAgYmlnIGVuZGlhbiBp bnRlZ2VycyBhcmU6PC90PgoKICAgICAgICA8dGV4dHRhYmxlPgoJICA8dHRjb2wgYWxpZ249Imxl ZnQiPlBhcmFtZXRlciBOYW1lPC90dGNvbD4KCSAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5WYWx1ZTwv dHRjb2w+CgoJICA8Yz5uPC9jPgoJICA8Yz4KClsyMTAsIDI1MiwgMTIzLCAxMDYsIDEwLCAzMCwg MTA4LCAxMDMsIDE2LCA3NCwgMjM1LCAxNDMsCjEzNiwgMTc4LCA4NywgMTAyLCAxNTUsIDc3LCAy NDYsIDEyMSwgMjIxLCAxNzMsIDksIDE1NSwKOTIsIDc0LCAxMDgsIDIxNywgMTY4LCAxMjgsIDIx LCAxODEsIDE2MSwgNTEsIDE5MSwgMTEsCjEzMywgMTA4LCAxMjAsIDExMywgMTgyLCAyMjMsIDAs IDExLCA4NSwgNzksIDIwNiwgMTc5LAoxOTQsIDIzNywgODEsIDQzLCAxODIsIDE0MywgMjAsIDky LCAxMTAsIDEzMiwgNTIsIDExNywKNDcsIDE3MSwgODIsIDE2MSwKMjA3LCAxOTMsIDM2LCA2NCwg MTQzLCAxMjEsIDE4MSwgMTM4LCA2OSwgMTIwLCAxOTMsCjEwMCwgNDAsIDEzMywgODcsIDEzNywg MjQ3LCAxNjIsIDczLCAyMjcsIDEzMiwgMjAzLCA0NSwKMTU5LCAxNzQsIDQ1LCAxMDMsIDI1Mywg MTUwLCAyNTEsIDE0NiwgMTA4LCAyNSwgMTQyLCA3LAoxMTUsIDE1MywgMjUzLCAyMDAsIDIxLCAx OTIsIDE3NSwgOSwgMTI1LCAyMjIsIDkwLCAxNzMsCjIzOSwgMjQ0LCA3NywgMjMxLCAxNCwgMTMw LCAxMjcsIDcyLCAxMjAsIDY3LCAzNiwgNTcsCjE5MSwgMjM4LCAxODUsIDk2LCAxMDQsCjIwOCwg NzEsIDc5LCAxOTcsIDEzLCAxMDksIDE0NCwgMTkxLCA1OCwgMTUyLCAyMjMsIDE3NSwKMTYsIDY0 LCAyMDAsIDE1NiwgMiwgMjE0LCAxNDYsIDE3MSwgNTksIDYwLCA0MCwgMTUwLAo5NiwgMTU3LCAx MzQsIDI1MywgMTE1LCAxODMsIDExNiwgMjA2LCA3LCA2NCwgMTAwLCAxMjQsCjIzOCwgMjM0LCAx NjMsIDE2LCAxODksIDE4LCAyNDksIDEzMywgMTY4LCAyMzUsIDE1OSwKODksIDI1MywgMjEyLCAz OCwgMjA2LCAxNjUsIDE3OCwgMTgsIDE1LCA3OSwgNDIsIDUyLAoxODgsIDE3MSwgMTE4LCA3NSwg MTI2LAoxMDgsIDg0LCAyMTQsIDEzMiwgMiwgNTYsIDE4OCwgMTk2LCA1LCAxMzUsIDE2NSwgMTU4 LAoxMDIsIDIzNywgMzEsIDUxLCAxMzcsIDY5LCAxMTksIDk5LCA5MiwgNzEsIDEwLCAyNDcsCjky LCAyNDksIDQ0LCAzMiwgMjA5LCAyMTgsIDY3LCAyMjUsIDE5MSwgMTk2LCAyNSwgMjI2LAozNCwg MTY2LCAyNDAsIDIwOCwgMTg3LCA1MywgMTQwLCA5NCwgNTYsIDI0OSwgMjAzLCA1LAoxMCwgMjM0 LCAyNTQsIDE0NCwgNzIsIDIwLCAyNDEsIDE3MiwgMjYsIDE2NCwgMTU2LCAyMDIsCjE1OCwgMTYw LCAyMDIsIDEzMV0KCgkgIDwvYz4KCgkgIDxjPmU8L2M+CgkgIDxjPgoKWzEsIDAsIDFdCgoJICA8 L2M+CgoJICA8Yz5kPC9jPgoJICA8Yz4KCls5NSwgMTM1LCAxOSwgMTgxLCAyMjYsIDg4LCAyNTQs IDksIDI0OCwgMjEsIDEzMSwgMjM2LAo5MiwgMzEsIDQzLCAxMTcsIDEyMCwgMTc3LCAyMzAsIDI1 MiwgNDQsIDEzMSwgODEsIDc1LAo1NSwgMTQ1LCA1NSwgMTcsIDE2MSwgMTg2LCA2OCwgMTU0LCAy MSwgMzEsIDIyNSwgMjAzLAo0NCwgMTYwLCAyNTMsIDUxLCAxODMsIDExMywgMjMwLCAxMzgsIDU5 LCAyNSwgNjgsIDEwMCwKMTU3LCAyMDAsIDEwMywgMTczLCAyOCwgMzAsIDgyLCA2NCwgMTg3LCAx MzMsIDYyLCA5NSwKMzYsIDE3OSwgNTIsIDg5LAoxNzcsIDY0LCA0MCwgMjEwLCAyMTQsIDk5LCAx MDcsIDIzOSwgMjM2LCAzMCwgMTQxLCAxNjksCjExNiwgMTc5LCA4MiwgMjUyLCA4MywgMjExLCAy NDYsIDE4LCAxMjYsIDE2OCwgMTYzLAoxOTQsIDE1NywgMjA5LCA3OSwgNTcsIDY1LCAxMDQsIDQ0 LCA4NiwgMTY3LCAxMzUsIDEwNCwKMjIsIDc4LCA3NywgMjE4LCAxNDMsIDYsIDIwMywgMjQ5LCAx OTksIDUyLCAxNzAsIDIzMiwKMCwgNTAsIDM2LCAzOSwgMTQyLCAxNjksIDY5LCA3NCwgMzMsIDE3 NywgMTI0LCAxNzYsCjEwOSwgMjMsIDEyOCwgMTE3LCAxMzQsCjE0MCwgMTkyLCA5MSwgNjEsIDE4 MiwgMjU1LCAyOSwgMjUzLCAxOTUsIDIxMywgOTksIDEyMCwKMTgwLCAyMzcsIDE3MywgMjM3LCAy NDAsIDE5NSwgMTIyLCA3NiwgMjIwLCAzOCwgMjA5LAoyMTIsIDE1NCwgMTk0LCAxMTEsIDExMSwg MjI3LCAxODEsIDM0LCAxMCwgOTMsIDIxMCwKMTQ3LCAxNTAsIDk4LCAyNywgMTg4LCAxMDQsIDE0 MCwgMjQyLCAyMzgsIDIyNiwgMTk4LAoyMjQsIDIxMywgNzcsIDE2MywgMTk5LCAxMzAsIDEsIDc2 LCAyMDgsIDExNSwgMTU3LCAxNzgsCjgyLCAyMDQsIDgxLCAyMDIsIDIzNSwgMTY4LCAyMTEsCjI0 MSwgMTg0LCAzNiwgMTg2LCAxNzEsIDM2LCAyMDgsIDEwNCwgMjM2LCAxNDQsIDUwLAoxMDAsIDIx NSwgMjE0LCAxMjAsIDE3MSwgOCwgMjQwLCAxMTAsIDIwMSwgMjMxLCAyMjYsCjYxLCAxNTAsIDYs IDQwLCAxODMsIDY4LCAxOTEsIDE0OCwgMTc5LCAxMDUsIDcwLCA4NiwKNzAsIDYwLCAxMjYsIDY1 LCAxMTUsIDE1MywgMjM3LCAxMTUsIDIwOCwgMTE4LCAyMDAsCjE0NSwgMjUyLCAyNDQsIDk5LCAx NjksIDE3MCwgMTU2LCAyMzAsIDQ1LCAxNjksIDIwNSwKMjMsIDIyNiwgNTUsIDIyMCwgNDIsIDEy OCwgMiwgMjQxXQoKCSAgPC9jPgogICAgICAgIDwvdGV4dHRhYmxlPgoKCTx0PlRoZSBSU0EgcHJp dmF0ZSBrZXkgKG4sIGQpIGlzIHRoZW4gcGFzc2VkIHRvIHRoZSBSU0EKCXNpZ25pbmcgZnVuY3Rp b24sIHdoaWNoIGFsc28gdGFrZXMgdGhlIGhhc2ggdHlwZSwgU0hBLTI1NiwgYW5kCgl0aGUgSldU IENsYWltIFNlZ21lbnQgYXMgaW5wdXRzLiAgVGhlIHJlc3VsdCBvZiB0aGUgc2lnbmF0dXJlCglp cyBhIGJ5dGUgYXJyYXkgUywgd2hpY2ggcmVwcmVzZW50cyBhIGJpZyBlbmRpYW4gaW50ZWdlci4g IEluCgl0aGlzIGV4YW1wbGUsIFMgaXM6PC90PgoKCTx0ZXh0dGFibGU+CgkgIDx0dGNvbCBhbGln bj0ibGVmdCI+UmVzdWx0IE5hbWU8L3R0Y29sPgoJICA8dHRjb2wgYWxpZ249ImxlZnQiPlZhbHVl PC90dGNvbD4KCgkgIDxjPlM8L2M+CgkgIDxjPgoKWzIwOCwgMTQxLCAyMTksIDQ0LCA2NiwgMTI5 LCAxNzksIDIzMCwgNjksIDEyMCwgMTIzLAoxMDgsIDIwMywgOTYsIDE4MiwgMTQ1LCA2NiwgMTc5 LCAxOTgsIDEwNCwgNDMsIDE4NywKMTk5LCAxNTksIDE3NSwgNSwgMjE3LCAxMDEsIDEwOSwgMjM2 LCA4OCwgMTM2LCAxOTMsCjEzMywgNzksIDM5LCAxNjIsIDEzMSwgNTgsIDExNCwgMTMzLCAyMDIs IDE3MSwgMjI3LAoxMzUsIDE1NywgMTIzLCAxODgsIDkwLCAxMTEsIDY2LCAyNDEsIDM4LCAyMzgs IDU5LCAxOCwKMTI1LCAxNDYsIDEyOSwgMTQsIDU0LCAxODMsIDEwLCAyMjEsCjMzLCAxMDUsIDM3 LCAxNzMsIDExOSwgMjM5LCA5MiwgMjcsIDIzMiwgMTc1LCAxNzMsIDQ5LAoyMSwgMjgsIDI1Miwg MjM3LCAxODMsIDEwNywgOTgsIDE1NiwgMTEzLCAxMTYsIDE2MiwKMjE5LCA1MywgOTYsIDQ0LCAy MTQsIDE3NSwgMTU0LCA2MSwgMTAwLCAxNzUsIDkwLCAxMTgsCjI0NywgNDIsIDE5NiwgNDUsIDc0 LCAyMTcsIDE0NSwgOTIsIDM5LCAxMjMsIDIyNCwgMjQ3LAoxNzEsIDIwNiwgMjAzLCA5MSwgMTY3 LCAxMDMsIDU3LCAxNjMsIDg3LCAxNzIsIDY3LCA3NywKMjU1LCA5LCAyMTgsIDEwNywgNjIsCjIy OCwgNzEsIDIzOSwgMzYsIDI0NiwgMjMsIDk2LCAxMDgsIDI4LCAxOSwgMTc5LCAyNCwKMTY3LCAx OTYsIDQyLCA5NywgMTk4LCA4MCwgMjQxLCA3OSwgMzEsIDAsIDg1LCAxNywKNTAsIDYsIDE0Mywg MjM4LCAyMTQsIDEzMSwgMjQ2LCAxMywgNDksIDExMSwgMzAsIDE0MiwKMTgyLCAxNDUsIDIwMCwg MTcsIDEyNywgNzYsIDIzNiwgNjksIDY2LCAxMzMsIDE5OCwgMTM3LAoxMDMsIDQ1LCAzLCA0OCwg MTIzLCAyMDMsIDE3LCAxNjIsIDEsIDEwNSwgMTMzLCAyMiwKMTA1LCAyNSwgNjMsIDE3MywKMTg2 LCAyMzEsIDIwNiwgMjQ2LCAyMiwgMjQzLCAyNTAsIDUzLCAyMzcsIDIwOSwgMzYsCjExMSwgMTY4 LCAxMSwgNDAsIDIzNywgMTc5LCA4MywgMTI1LCAxODAsIDg0LCAyMzEsIDEyOSwKMzcsIDIzNiwg MTcyLCAyMiwgMjM0LCA1OCwgMTk4LCAxODcsIDEyNCwgNjUsIDE0NSwgMTQ4LAoyMjcsIDEyMiwg MTc3LCAxNiwgMTc2LCA4NCwgMjgsIDEsIDE0MSwgMTc5LCA1NywgOTYsCjIzMiwgMjE1LCA1MSwg NywgNDksIDYzLCAxOTUsIDE1NSwgOTQsIDUxLCAyMiwgMjM5LAo5MCwgMTM4LCAyMDcsIDQxLCA2 Ml0KCgkgIDwvYz4KCTwvdGV4dHRhYmxlPgoKCTx0PkJhc2U2NHVybCBlbmNvZGluZyB0aGUgc2ln bmF0dXJlIHByb2R1Y2VzIHRoaXMgdmFsdWUgZm9yIHRoZSBKV1QKCUNyeXB0byBTZWdtZW50Ojwv dD4KCgk8YXJ0d29yaz48IVtDREFUQVswSTNiTEVLQnMtWkZlSHRzeTJDMmtVS3p4bWdydThlZnJ3 WFpaVzNzV0lqQmhVOG5vb002Y29YS3EtT0huWHU4V205QzhTYnVPeEo5a29FT05yY0szU0ZwSmEx Mzcxd2I2Sy10TVJVY19PMjNhMktjY1hTaTJ6VmdMTmF2bWoxa3IxcDI5eXJFTFVyWmtWd25lLUQz cTg3TFc2ZG5PYU5YckVOTl93bmFhejdrUi04azloZGdiQndUc3hpbnhDcGh4bER4VHg4QVZSRXlC b191MW9QMkRURnZIbzYya2NnUmYwenNSVUtGeG9sbkxRTXdlOHNSb2dGcGhSWnBHVC10dXVmTzlo Ynotalh0MFNSdnFBc283Yk5UZmJSVTU0RWw3S3dXNmpyR3UzeEJrWlRqZXJFUXNGUWNBWTJ6T1dE bzF6TUhNVF9EbTE0ekZ1OWFpczhwUGddXT48L2FydHdvcms+CgogICAgICA8dD5Db21iaW5pbmcg dGhlc2Ugc2VnbWVudHMgaW4gdGhlIG9yZGVyCiAgICAgIEVudmVsb3BlLkNsYWltcy5TaWduYXR1 cmUgd2l0aCBwZXJpb2QgY2hhcmFjdGVycyBiZXR3ZWVuIHRoZQogICAgICBzZWdtZW50cyB5aWVs ZHMgdGhpcyBjb21wbGV0ZSBKV1QgKHdpdGggbGluZSBicmVha3MgZm9yIGRpc3BsYXkKICAgICAg cHVycG9zZXMgb25seSk6PC90PgoKICAgICAgPGFydHdvcms+PCFbQ0RBVEFbZXlKaGJHY2lPaUpT VXpJMU5pSjkKLgpleUpwYzNNaU9pSnFiMlVpTEEwS0lDSmxlSEFpT2pFek1EQTRNVGt6T0RBc0RR b2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAwY25WbGZRCi4KMEkzYkxF S0JzLVpGZUh0c3kyQzJrVUt6eG1ncnU4ZWZyd1haWlczc1dJakJoVThub29NNmNvWEtxLU9Iblh1 OFdtOUM4U2J1T3hKOWtvRU9OcmNLM1NGcEphMTM3MXdiNkstdE1SVWNfTzIzYTJLY2NYU2kyelZn TE5hdm1qMWtyMXAyOXlyRUxVclprVnduZS1EM3E4N0xXNmRuT2FOWHJFTk5fd25hYXo3a1ItOGs5 aGRnYkJ3VHN4aW54Q3BoeGxEeFR4OEFWUkV5Qm9fdTFvUDJEVEZ2SG82MmtjZ1JmMHpzUlVLRnhv bG5MUU13ZThzUm9nRnBoUlpwR1QtdHV1Zk85aGJ6LWpYdDBTUnZxQXNvN2JOVGZiUlU1NEVsN0t3 VzZqckd1M3hCa1pUamVyRVFzRlFjQVkyek9XRG8xek1ITVRfRG0xNHpGdTlhaXM4cFBnXV0+PC9h cnR3b3JrPgoKICAgIDwvc2VjdGlvbj4KICAgIDxzZWN0aW9uIHRpdGxlPSJEZWNvZGluZyI+Cgog ICAgICA8dD5EZWNvZGluZyB0aGUgSldUIGZyb20gdGhpcyBleGFtcGxlIHJlcXVpcmVzIHByb2Nl c3NpbmcgdGhlCiAgICAgIEpXVCBFbnZlbG9wZSBTZWdtZW50IGFuZCBDbGFpbSBTZWdtZW50IGV4 YWN0bHkgYXMgZG9uZSBpbiB0aGUKICAgICAgZmlyc3QgZXhhbXBsZS48L3Q+CgogICAgPC9zZWN0 aW9uPgogICAgPHNlY3Rpb24gdGl0bGU9IlZhbGlkYXRpbmciPgoKICAgICAgPHQ+U2luY2UgdGhl ICJhbGciIHBhcmFtZXRlciBpbiB0aGUgZW52ZWxvcGUgaXMgIlJTMjU2Iiwgd2UKICAgICAgdmFs aWRhdGUgdGhlIFJTQSBTSEEtMjU2IHNpZ25hdHVyZSBjb250YWluZWQgaW4gdGhlIEpXVCBDcnlw dG8KICAgICAgU2VnbWVudC4gIElmIGFueSBvZiB0aGUgdmFsaWRhdGlvbiBzdGVwcyBmYWlsLCB0 aGUgdG9rZW4gTVVTVCBiZQogICAgICByZWplY3RlZC48L3Q+CgogICAgICA8dD5GaXJzdCwgd2Ug dmFsaWRhdGUgdGhhdCB0aGUgZGVjb2RlZCBlbnZlbG9wZSBhbmQgY2xhaW0KICAgICAgc2VnbWVu dCBzdHJpbmdzIGFyZSBib3RoIGxlZ2FsIEpTT04uPC90PgoKICAgICAgPHQ+VmFsaWRhdGluZyB0 aGUgSldUIENyeXB0byBTZWdtZW50IGlzIGEgbGl0dGxlIGRpZmZlcmVudCBmcm9tCiAgICAgIHRo ZSBwcmV2aW91cyBleGFtcGxlLiBGaXJzdCwgd2UgYmFzZTY0dXJsIGRlY29kZSB0aGUgSldUIENy eXB0bwogICAgICBTZWdtZW50IHRvIHByb2R1Y2UgYSBzaWduYXR1cmUgUyB0byBjaGVjay4gIFdl IHRoZW4gcGFzcyAobiwgZSksCiAgICAgIFMgYW5kIHRoZSBKV1QgQ2xhaW0gU2VnbWVudCB0byBh biBSU0Egc2lnbmF0dXJlIHZlcmlmaWVyIHRoYXQKICAgICAgaGFzIGJlZW4gY29uZmlndXJlZCB0 byB1c2UgdGhlIFNIQS0yNTYgaGFzaCBmdW5jdGlvbi48L3Q+CgogICAgPC9zZWN0aW9uPgogIDwv c2VjdGlvbj4KCiAgPHNlY3Rpb24gdGl0bGU9IkpXVCB1c2luZyBFQ0RTQSBQLTI1NiBTSEEtMjU2 Ij4KICAgIDxzZWN0aW9uIHRpdGxlPSJFbmNvZGluZyI+CiAgICAgIDx0PlRoZSBEZWNvZGVkIEpX VCBDbGFpbSBTZWdtZW50IHVzZWQgaW4gdGhpcyBleGFtcGxlIGlzIHRoZSBzYW1lIGFzIGluIHRo ZSBwcmV2aW91cyBleGFtcGxlczo8L3Q+CgogICAgICA8YXJ0d29yaz48IVtDREFUQVt7ImlzcyI6 ImpvZSIsCiAiZXhwIjoxMzAwODE5MzgwLAogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0 cnVlfV1dPjwvYXJ0d29yaz4KCiAgICAgIDx0PlNpbmNlIHRoZSBKV1QgQ2xhaW0gU2VnbWVudCB3 aWxsIHRoZXJlZm9yZSBiZSB0aGUgc2FtZSwgaXRzCiAgICAgIGNvbXB1dGF0aW9uIGlzIG5vdCBy ZXBlYXRlZCBoZXJlLiAgSG93ZXZlciwgdGhlIERlY29kZWQgSldUCiAgICAgIEVudmVsb3BlIFNl Z21lbnQgaXMgZGlmZmVycyBmcm9tIHRoZSBwcmV2aW91cyBleGFtcGxlIGJlY2F1c2UgYQogICAg ICBkaWZmZXJlbnQgYWxnb3JpdGhtIGlzIGJlaW5nIHVzZWQuICBUaGUgRGVjb2RlZCBKV1QgRW52 ZWxvcGUKICAgICAgU2VnbWVudCB1c2VkIGlzOjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRB W3siYWxnIjoiRVMyNTYifV1dPjwvYXJ0d29yaz4KCiAgICAgIDx0PiBUaGUgZm9sbG93aW5nIGJ5 dGUgYXJyYXkgY29udGFpbnMgdGhlIFVURi04IGNoYXJhY3RlcnMgZm9yCiAgICAgIHRoZSBEZWNv ZGVkIEpXVCBFbnZlbG9wZSBTZWdtZW50OjwvdD4KCiAgICA8dD4KClsxMjMsIDM0LCA5NywgMTA4 LCAxMDMsIDM0LCA1OCwgMzQsIDY5LCA4MywgNTAsIDUzLAogIDU0LCAzNCwgMTI1XQoKICAgIDwv dD4KCiAgICAgIDx0PkJhc2U2NHVybCBlbmNvZGluZyB0aGlzIFVURi04IHJlcHJlc2VudGF0aW9u IHlpZWxkcyB0aGlzIEpXVAogICAgICBFbnZlbG9wZSBTZWdtZW50IHZhbHVlOjwvdD4KCiAgICAg IDxhcnR3b3JrPjwhW0NEQVRBW2V5SmhiR2NpT2lKRlV6STFOaUo5XV0+PC9hcnR3b3JrPgoKICAg ICAgPHQ+VGhlIEVDRFNBIGtleSBjb25zaXN0cyBvZiBhIHB1YmxpYyBwYXJ0LCB0aGUgRUMgcG9p bnQgKHgsIHkpLCBhbmQgYQogICAgICBwcml2YXRlIHBhcnQgZC4gIFRoZSB2YWx1ZXMgb2YgdGhl IEVDRFNBIGtleSB1c2VkIGluIHRoaXMKICAgICAgZXhhbXBsZSwgcHJlc2VudGVkIGFzIHRoZSBi eXRlIGFycmF5cyByZXByZXNlbnRpbmcKICAgICAgYmlnIGVuZGlhbiBpbnRlZ2VycyBhcmU6PC90 PgoKICAgICAgPHRleHR0YWJsZT4KCTx0dGNvbCBhbGlnbj0ibGVmdCI+UGFyYW1ldGVyIE5hbWU8 L3R0Y29sPgoJPHR0Y29sIGFsaWduPSJsZWZ0Ij5WYWx1ZTwvdHRjb2w+CgoJPGM+eDwvYz4KCTxj PgoKWzQ4LCAxNjAsIDY2LCA3NiwgMjEwLCAyOCwgNDEsIDY4LCAxMzEsIDEzOCwgNDUsIDExNywK MjAxLCA0MywgNTUsIDIzMSwgMTEwLCAxNjIsIDEzLCAxNTksIDAsIDEzNywgNTgsIDU5LAo3OCwg MjM4LCAxMzgsIDYwLCAxMCwgMTc1LCAyMzYsIDYyXQoKCTwvYz4KCgk8Yz55PC9jPgoJPGM+Cgpb MjI0LCA3NSwgMTAxLCAyMzMsIDM2LCA4NiwgMjE3LCAxMzYsIDEzOSwgODIsIDE3OSwgMTIxLAox ODksIDI1MSwgMjEzLCAzMCwgMjMyLCAxMDUsIDIzOSwgMzEsIDE1LCAxOTgsIDkxLCAxMDIsCjg5 LCAxMDUsIDkxLCAxMDgsIDIwNiwgOCwgMjMsIDM1XQoKCTwvYz4KCgk8Yz5kPC9jPgoJPGM+Cgpb MjQzLCAxODksIDEyLCA3LCAxNjgsIDMxLCAxODUsIDUwLCAxMjAsIDMwLCAyMTMsIDM5LAo4Miwg MjQ2LCAxMiwgMjAwLCAxNTQsIDEwNywgMjI5LCAyMjksIDI1LCA1MiwgMjU0LCAxLAoxNDcsIDE0 MSwgMjE5LCA4NSwgMjE2LCAyNDcsIDEyMCwgMV0KCgk8L2M+CiAgICAgIDwvdGV4dHRhYmxlPgoK ICAgICAgPHQ+VGhlIEVDRFNBIHByaXZhdGUgcGFydCBkIGlzIHRoZW4gcGFzc2VkIHRvIGFuIEVD RFNBCiAgICAgIHNpZ25pbmcgZnVuY3Rpb24sIHdoaWNoIGFsc28gdGFrZXMgdGhlIGN1cnZlIHR5 cGUsCiAgICAgIFAtMjU2LCB0aGUgaGFzaCB0eXBlLCBTSEEtMjU2LCBhbmQgdGhlIEpXVCBDbGFp bQogICAgICBTZWdtZW50IGFzIGlucHV0cy4gIFRoZSByZXN1bHQgb2YgdGhlIHNpZ25hdHVyZSBp cyB0aGUKICAgICAgRUMgcG9pbnQgKFIsIFMpLCB3aGVyZSBSIGFuZCBTIGFyZSB1bnNpZ25lZCBp bnRlZ2Vycy4KICAgICAgSW4gdGhpcyBleGFtcGxlLCB0aGUgUiBhbmQgUyB2YWx1ZXMsIGdpdmVu IGFzCiAgICAgIGJ5dGUgYXJyYXlzIHJlcHJlc2VudGluZyBiaWcgZW5kaWFuIGludGVnZXJzIGFy ZTo8L3Q+CgogICAgICA8dGV4dHRhYmxlPgoJPHR0Y29sIGFsaWduPSJsZWZ0Ij5SZXN1bHQgTmFt ZTwvdHRjb2w+Cgk8dHRjb2wgYWxpZ249ImxlZnQiPlZhbHVlPC90dGNvbD4KCgk8Yz5SPC9jPgoJ PGM+CgpbMTc1LCAxMSwgMTE1LCA0MiwgMTYwLCAxODIsIDE4MSwgMjgsIDEzNSwgMjIyLCA1Miwg MTU0LAogIDE4MiwgMjM3LCAyMDYsIDEzNywgODIsIDIwLCAyNDMsIDcsIDEyLCAxNjQsIDEwNywg NzIsCiAgMjM2LCAxODcsIDI0MSwgMTkwLCAyNiwgNzYsIDMyLCAxODFdCgoJPC9jPgoKCTxjPlM8 L2M+Cgk8Yz4KClsxMjAsIDIzLCAxODksIDIwNSwgMjAyLCAxMywgMTc3LCAxODcsIDIzLCA0Nywg MTIsIDIyNywKICAyMzcsIDI1MCwgMjMwLCAyMzMsIDI0NSwgMjE2LCA5LCAxNzAsIDI0LCAxODUs IDE5OCwKICAxODcsIDE5MywgOTQsIDE1OCwgMTE3LCAxNjcsIDg4LCAxNTMsIDE5Nl0KCgk8L2M+ CiAgICAgIDwvdGV4dHRhYmxlPgoKICAgICAgPHQ+Q29uY2F0ZW5hdGluZyB0aGUgUyBhcnJheSB0 byB0aGUgZW5kIG9mIHRoZSBSIGFycmF5IGFuZAogICAgICBiYXNlNjR1cmwgZW5jb2RpbmcgdGhl IHJlc3VsdCBwcm9kdWNlcyB0aGlzIHZhbHVlIGZvciB0aGUgSldUCiAgICAgIENyeXB0byBTZWdt ZW50OjwvdD4KCiAgICAgIDxhcnR3b3JrPjwhW0NEQVRBW3J3dHpLcUMydFJ5SDNqU2F0dTNPaVZJ VTh3Y01wR3RJN0x2eHZocE1JTFY0RjczTnlnMnh1eGN2RE9QdC11YnA5ZGdKcWhpNXhydkJYcDUx cDFpWnhBXV0+PC9hcnR3b3JrPgoKCiAgICAgIDx0PkNvbWJpbmluZyB0aGVzZSBzZWdtZW50cyBp biB0aGUgb3JkZXIKICAgICAgRW52ZWxvcGUuQ2xhaW1zLlNpZ25hdHVyZSB3aXRoIHBlcmlvZCBj aGFyYWN0ZXJzIGJldHdlZW4gdGhlCiAgICAgIHNlZ21lbnRzIHlpZWxkcyB0aGlzIGNvbXBsZXRl IEpXVCAod2l0aCBsaW5lIGJyZWFrcyBmb3IgZGlzcGxheQogICAgICBwdXJwb3NlcyBvbmx5KTo8 L3Q+CgogICAgICA8YXJ0d29yaz48IVtDREFUQVtleUpoYkdjaU9pSkZVekkxTmlKOQouCmV5SnBj M01pT2lKcWIyVWlMQTBLSUNKbGVIQWlPakV6TURBNE1Ua3pPREFzRFFvZ0ltaDBkSEE2THk5bGVH RnRjR3hsTG1OdmJTOXBjMTl5YjI5MElqcDBjblZsZlEKLgpyd3R6S3FDMnRSeUgzalNhdHUzT2lW SVU4d2NNcEd0STdMdnh2aHBNSUxWNEY3M055ZzJ4dXhjdkRPUHQtdWJwOWRnSnFoaTV4cnZCWHA1 MXAxaVp4QV1dPjwvYXJ0d29yaz4KCiAgICA8L3NlY3Rpb24+CiAgICA8c2VjdGlvbiB0aXRsZT0i RGVjb2RpbmciPgoKICAgICAgPHQ+RGVjb2RpbmcgdGhlIEpXVCBmcm9tIHRoaXMgZXhhbXBsZSBy ZXF1aXJlcyBwcm9jZXNzaW5nIHRoZQogICAgICBKV1QgRW52ZWxvcGUgU2VnbWVudCBhbmQgQ2xh aW0gU2VnbWVudCBleGFjdGx5IGFzIGRvbmUgaW4gdGhlCiAgICAgIGZpcnN0IGV4YW1wbGUuPC90 PgoKICAgIDwvc2VjdGlvbj4KICAgIDxzZWN0aW9uIHRpdGxlPSJWYWxpZGF0aW5nIj4KCiAgICAg IDx0PlNpbmNlIHRoZSAiYWxnIiBwYXJhbWV0ZXIgaW4gdGhlIGVudmVsb3BlIGlzICJFUzI1NiIs IHdlCiAgICAgIHZhbGlkYXRlIHRoZSBFQ0RTQSBQLTI1NiBTSEEtMjU2IHNpZ25hdHVyZSBjb250 YWluZWQgaW4gdGhlIEpXVAogICAgICBDcnlwdG8gU2VnbWVudC4gIElmIGFueSBvZiB0aGUgdmFs aWRhdGlvbiBzdGVwcyBmYWlsLCB0aGUgdG9rZW4KICAgICAgTVVTVCBiZSByZWplY3RlZC48L3Q+ CgogICAgICA8dD5GaXJzdCwgd2UgdmFsaWRhdGUgdGhhdCB0aGUgZGVjb2RlZCBlbnZlbG9wZSBh bmQgY2xhaW0KICAgICAgc2VnbWVudCBzdHJpbmdzIGFyZSBib3RoIGxlZ2FsIEpTT04uPC90PgoK ICAgICAgPHQ+VmFsaWRhdGluZyB0aGUgSldUIENyeXB0byBTZWdtZW50IGlzIGEgbGl0dGxlIGRp ZmZlcmVudCBmcm9tCiAgICAgIHRoZSBmaXJzdCBleGFtcGxlLiBGaXJzdCwgd2UgYmFzZTY0dXJs IGRlY29kZSB0aGUgSldUIENyeXB0bwogICAgICBTZWdtZW50IGFzIGluIHRoZSBwcmV2aW91cyBl eGFtcGxlcyBidXQgd2UgdGhlbiBuZWVkIHRvIHNwbGl0CiAgICAgIHRoZSA2NCBtZW1iZXIgYnl0 ZSBhcnJheSB0aGF0IG11c3QgcmVzdWx0IGludG8gdHdvIDMyIGJ5dGUKICAgICAgYXJyYXlzLCB0 aGUgZmlyc3QgUiBhbmQgdGhlIHNlY29uZCBTLiBXZSB0aGVuIHBhc3MgKHgsIHkpLCAoUiwKICAg ICAgUykgYW5kIHRoZSBKV1QgQ2xhaW0gU2VnbWVudCB0byBhbiBFQ0RTQSBzaWduYXR1cmUgdmVy aWZpZXIgdGhhdAogICAgICBoYXMgYmVlbiBjb25maWd1cmVkIHRvIHVzZSB0aGUgUC0yNTYgY3Vy dmUgd2l0aCB0aGUgU0hBLTI1NiBoYXNoCiAgICAgIGZ1bmN0aW9uLjwvdD4KCiAgICAgIDx0PkFz IGV4cGxhaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IkRlZmluaW5nRUNEU0EiPjwveHJlZj4sIHRoZQog ICAgICB1c2Ugb2YgdGhlIGsgdmFsdWUgaW4gRUNEU0EgbWVhbnMgdGhhdCB3ZSBjYW5ub3QgdmFs aWRhdGUgdGhlCiAgICAgIGNvcnJlY3RuZXNzIG9mIHRoZSBzaWduYXR1cmUgaW4gdGhlIHNhbWUg d2F5IHdlIHZhbGlkYXRlZCB0aGUKICAgICAgY29ycmVjdG5lc3Mgb2YgdGhlIEhNQUMuIEluc3Rl YWQsIGltcGxlbWVudGF0aW9ucyBNVVNUIHVzZSBhbgogICAgICBFQ0RTQSB2YWxpZGF0b3IgdG8g dmFsaWRhdGUgdGhlIHNpZ25hdHVyZS48L3Q+CgogICAgPC9zZWN0aW9uPgogIDwvc2VjdGlvbj4K PC9zZWN0aW9uPgoKPHNlY3Rpb24gdGl0bGU9IkFwcGVuZGl4IC0gTm9uLU5vcm1hdGl2ZSAtIE5v dGVzIG9uIGltcGxlbWVudGluZyBiYXNlNjR1cmwgZW5jb2Rpbmcgd2l0aG91dCBwYWRkaW5nIiBh bmNob3I9ImJhc2U2NHVybG5vdGVzIj4KCiAgPHQ+VGhpcyBhcHBlbmRpeCBkZXNjcmliZXMgaG93 IHRvIGltcGxlbWVudCBiYXNlNjR1cmwgZW5jb2RpbmcKICBhbmQgZGVjb2RpbmcgZnVuY3Rpb25z IHdpdGhvdXQgcGFkZGluZyBiYXNlZCB1cG9uIHN0YW5kYXJkCiAgYmFzZTY0IGVuY29kaW5nIGFu ZCBkZWNvZGluZyBmdW5jdGlvbnMgdGhhdCBkbyB1c2UgcGFkZGluZy48L3Q+CgogIDx0PlRvIGJl IGNvbmNyZXRlLCBleGFtcGxlIEMjIGNvZGUgaW1wbGVtZW50aW5nIHRoZXNlIGZ1bmN0aW9ucwog IGlzIHNob3duIGJlbG93LiAgU2ltaWxhciBjb2RlIGNvdWxkIGJlIHVzZWQgaW4gb3RoZXIKICBs YW5ndWFnZXMuPC90PgoKPGFydHdvcms+PCFbQ0RBVEFbc3RhdGljIHN0cmluZyBiYXNlNjR1cmxl bmNvZGUoYnl0ZSBbXSBhcmcpCnsKICBzdHJpbmcgcyA9IENvbnZlcnQuVG9CYXNlNjRTdHJpbmco YXJnKTsgLy8gU3RhbmRhcmQgYmFzZTY0IGVuY29kZXIKICBzID0gcy5TcGxpdCgnPScpWzBdOyAv LyBSZW1vdmUgYW55IHRyYWlsaW5nICc9J3MKICBzID0gcy5SZXBsYWNlKCcrJywgJy0nKTsgLy8g NjJuZCBjaGFyIG9mIGVuY29kaW5nCiAgcyA9IHMuUmVwbGFjZSgnLycsICdfJyk7IC8vIDYzcmQg Y2hhciBvZiBlbmNvZGluZwogIHJldHVybiBzOwp9CgpzdGF0aWMgYnl0ZSBbXSBiYXNlNjR1cmxk ZWNvZGUoc3RyaW5nIGFyZykKewogIHN0cmluZyBzID0gYXJnOwogIHMgPSBzLlJlcGxhY2UoJy0n LCAnKycpOyAvLyA2Mm5kIGNoYXIgb2YgZW5jb2RpbmcKICBzID0gcy5SZXBsYWNlKCdfJywgJy8n KTsgLy8gNjNyZCBjaGFyIG9mIGVuY29kaW5nCiAgc3dpdGNoIChzLkxlbmd0aCAlIDQpIC8vIFBh ZCB3aXRoIHRyYWlsaW5nICc9J3MKICB7CiAgICBjYXNlIDA6IGJyZWFrOyAvLyBObyBwYWQgY2hh cnMgaW4gdGhpcyBjYXNlCiAgICBjYXNlIDI6IHMgKz0gIj09IjsgYnJlYWs7IC8vIFR3byBwYWQg Y2hhcnMKICAgIGNhc2UgMzogcyArPSAiPSI7IGJyZWFrOyAvLyBPbmUgcGFkIGNoYXIKICAgIGRl ZmF1bHQ6IHRocm93IG5ldyBTeXN0ZW0uRXhjZXB0aW9uKAogICAgICAiSWxsZWdhbCBiYXNlNjR1 cmwgc3RyaW5nISIpOwogIH0KICByZXR1cm4gQ29udmVydC5Gcm9tQmFzZTY0U3RyaW5nKHMpOyAv LyBTdGFuZGFyZCBiYXNlNjQgZGVjb2Rlcgp9XV0+PC9hcnR3b3JrPgoKICA8dD5BcyBwZXIgdGhl IGV4YW1wbGUgY29kZSBhYm92ZSwgdGhlIG51bWJlciBvZiAnPScgcGFkZGluZwogIGNoYXJhY3Rl cnMgdGhhdCBuZWVkcyB0byBiZSBhZGRlZCB0byB0aGUgZW5kIG9mIGEgYmFzZTY0dXJsCiAgZW5j b2RlZCBzdHJpbmcgd2l0aG91dCBwYWRkaW5nIHRvIHR1cm4gaXQgaW50byBvbmUgd2l0aCBwYWRk aW5nCiAgaXMgYSBkZXRlcm1pbmlzdGljIGZ1bmN0aW9uIG9mIHRoZSBsZW5ndGggb2YgdGhlIGVu Y29kZWQgc3RyaW5nLgogIFNwZWNpZmljYWxseSwKICBpZiB0aGUgbGVuZ3RoIG1vZCA0IGlzIDAs IG5vIHBhZGRpbmcgaXMgYWRkZWQ7CiAgaWYgdGhlIGxlbmd0aCBtb2QgNCBpcyAyLCB0d28gJz0n IHBhZGRpbmcgY2hhcmFjdGVycyBhcmUgYWRkZWQ7CiAgaWYgdGhlIGxlbmd0aCBtb2QgNCBpcyAz LCBvbmUgJz0nIHBhZGRpbmcgY2hhcmFjdGVyIGlzIGFkZGVkOwogIGlmIHRoZSBsZW5ndGggbW9k IDQgaXMgMSwgdGhlIGlucHV0IGlzIG1hbGZvcm1lZC48L3Q+CgogIDx0PkFuIGV4YW1wbGUgY29y cmVzcG9uZGVuY2UgYmV0d2VlbiB1bmVuY29kZWQgYW5kIGVuY29kZWQKICB2YWx1ZXMgZm9sbG93 cy4gIFRoZSBieXRlIHNlcXVlbmNlIGJlbG93IGVuY29kZXMgaW50byB0aGUgc3RyaW5nCiAgYmVs b3csIHdoaWNoIHdoZW4gZGVjb2RlZCwgcmVwcm9kdWNlcyB0aGUgYnl0ZSBzZXF1ZW5jZS48L3Q+ CgogIDxhcnR3b3JrPjMgMjM2IDI1NSAyMjQgMTkzPC9hcnR3b3JrPgoKICA8YXJ0d29yaz5BLXpf NE1FPC9hcnR3b3JrPgo8L3NlY3Rpb24+Cgo8c2VjdGlvbiB0aXRsZT0iQXBwZW5kaXggLSBOb24t Tm9ybWF0aXZlIC0gUmVsYXRpb25zaGlwIG9mIEpXVHMgdG8gU0FNTCBUb2tlbnMiPgogIDx0Pjx4 cmVmIHRhcmdldD0iT0FTSVMuc2FtbC1jb3JlLTIuMC1vcyI+U0FNTCAyLjA8L3hyZWY+CiAgcHJv dmlkZXMgYSBzdGFuZGFyZCBmb3IgY3JlYXRpbmcgdG9rZW5zIHdpdGggbXVjaCBncmVhdGVyCiAg ZXhwcmVzc2l2aXR5IGFuZCBtb3JlIHNlY3VyaXR5IG9wdGlvbnMgdGhhbiBzdXBwb3J0ZWQgYnkK ICBKV1RzLiBIb3dldmVyLCB0aGUgY29zdCBvZiB0aGlzIGZsZXhpYmlsaXR5IGFuZCBleHByZXNz aXZlbmVzcwogIGlzIGJvdGggc2l6ZSBhbmQgY29tcGxleGl0eS4gSW4gYWRkaXRpb24sIFNBTUwn cyB1c2Ugb2YgPHhyZWYKICB0YXJnZXQ9IlczQy5DUi14bWwxMS0yMDAyMTAxNSI+WE1MPC94cmVm PiBhbmQgPHhyZWYKICB0YXJnZXQ9IlJGQzMyNzUiPlhNTCBEU0lHPC94cmVmPiBvbmx5IGNvbnRy aWJ1dGVzIHRvIHRoZSBzaXplIG9mCiAgU0FNTCB0b2tlbnMuPC90PgoKICA8dD5KV1RzIGFyZSBp bnRlbmRlZCB0byBwcm92aWRlIGEgc2ltcGxlIHRva2VuIGZvcm1hdAogIHRoYXQgaXMgc21hbGwg ZW5vdWdoIHRvIGZpdCBpbnRvIEhUVFAgaGVhZGVycyBhbmQgcXVlcnkgYXJndW1lbnRzIGluCiAg VVJJcy4gSXQgZG9lcyB0aGlzIGJ5IHN1cHBvcnRpbmcgYSBtdWNoIHNpbXBsZXIgdG9rZW4gbW9k ZWwgdGhhbgogIFNBTUwgYW5kIHVzaW5nIHRoZSA8eHJlZiB0YXJnZXQ9IlJGQzQ2MjciPkpTT048 L3hyZWY+IG9iamVjdCBlbmNvZGluZwogIHN5bnRheC4gSXQgYWxzbyBzdXBwb3J0cyBzZWN1cmlu ZyB0b2tlbnMgdXNpbmcgSGFzaC1iYXNlZCBNZXNzYWdlCiAgQXV0aGVudGljYXRpb24gQ29kZXMg KEhNQUNzKSBhbmQgZGlnaXRhbCBzaWduYXR1cmVzIHVzaW5nIGEgc21hbGxlciAoYW5kCiAgbGVz cyBmbGV4aWJsZSkgZm9ybWF0IHRoYW4gWE1MIERTSUcuPC90PgoKICA8dD5UaGVyZWZvcmUsIHdo aWxlIEpXVHMgY2FuIGRvIHNvbWUgb2YgdGhlIHRoaW5ncyBTQU1MIHRva2VucwogIGRvLCBKV1Rz IGFyZSBub3QgaW50ZW5kZWQgYXMgYSBmdWxsIHJlcGxhY2VtZW50IGZvciBTQU1MIHRva2Vucywg YnV0CiAgcmF0aGVyIGFzIGEgY29tcHJvbWlzZSB0b2tlbiBmb3JtYXQgdG8gYmUgdXNlZCB3aGVu IHNwYWNlIGlzIGF0IGEKICBwcmVtaXVtLjwvdD4KPC9zZWN0aW9uPgoKPHNlY3Rpb24gdGl0bGU9 IkFwcGVuZGl4IC0gTm9uLU5vcm1hdGl2ZSAtIFJlbGF0aW9uc2hpcCBvZiBKV1RzIHRvIFNpbXBs ZSBXZWIgVG9rZW5zIChTV1RzKSI+CgogIDx0PkJvdGggSldUcyBhbmQgU2ltcGxlIFdlYiBUb2tl bnMgPHhyZWYKICB0YXJnZXQ9IlNXVCI+U1dUPC94cmVmPiwgYXQgdGhlaXIgY29yZSwgZW5hYmxl IHNldHMgb2YgY2xhaW1zIHRvCiAgYmUgY29tbXVuaWNhdGVkIGJldHdlZW4gYXBwbGljYXRpb25z LiAgRm9yIFNXVHMsIGJvdGggdGhlIGNsYWltCiAgbmFtZXMgYW5kIGNsYWltIHZhbHVlcyBhcmUg c3RyaW5ncy4gIEZvciBKV1RzLCB3aGlsZQogIGNsYWltIG5hbWVzIGFyZSBzdHJpbmdzLCBjbGFp bSB2YWx1ZXMgY2FuIGJlIGFueSBKU09OIHR5cGUuCiAgQm90aCB0b2tlbiB0eXBlcyBvZmZlciBj cnlwdG9ncmFwaGljIHByb3RlY3Rpb24gb2YgdGhlaXIKICBjb250ZW50OiBTV1RzIHdpdGggSE1B QyBTSEEtMjU2IGFuZCBKV1RzIHdpdGggYSBjaG9pY2Ugb2YKICBhbGdvcml0aG1zLCBpbmNsdWRp bmcgSE1BQyBTSEEtMjU2LCBSU0EgU0hBLTI1NiwgYW5kIEVDRFNBIFAtMjU2CiAgU0hBLTI1Ni48 L3Q+Cgo8L3NlY3Rpb24+CjwvbWlkZGxlPgoKICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxl PSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICZSRkMyMDQ1OwoKICAgICAgJlJGQzIxMDQ7 CgogICAgICAmcmZjMjExOTsKCiAgICAgICZSRkMzMzM5OwoKICAgICAgJlJGQzM0NDc7CgogICAg ICAmUkZDMzYyOTsKCiAgICAgICZSRkMzOTg2OwoKICAgICAgJlJGQzQ2Mjc7CgogICAgICAmUkZD NDY0ODsKCiAgICAgICZSRkM1MjI2OwoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkZJUFMuMTgw LTMiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5TZWN1cmUgSGFzaCBTdGFuZGFy ZCAoU0hTKTwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvcj4KICAgICAgICAgICAgPG9yZ2FuaXph dGlvbj5OYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZAogICAgICAgICAgICBUZWNo bm9sb2d5PC9vcmdhbml6YXRpb24+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0 ZSBtb250aD0iT2N0b2JlciIgeWVhcj0iMjAwOCIgLz4KICAgICAgICA8L2Zyb250PgogICAgICAg IDxmb3JtYXQgdGFyZ2V0PSJodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvZmlwcy9m aXBzMTgwLTMvZmlwczE4MC0zX2ZpbmFsLnBkZiIgdHlwZT0iUERGIiAvPgogICAgICAgIDxzZXJp ZXNJbmZvIG5hbWU9IkZJUFMiIHZhbHVlPSJQVUIgMTgwLTMiIC8+CiAgICAgIDwvcmVmZXJlbmNl PgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkZJUFMuMTg2LTMiPgogICAgICAgIDxmcm9udD4K ICAgICAgICAgIDx0aXRsZT5EaWdpdGFsIFNpZ25hdHVyZSBTdGFuZGFyZCAoRFNTKTwvdGl0bGU+ CgogICAgICAgICAgPGF1dGhvcj4KICAgICAgICAgICAgPG9yZ2FuaXphdGlvbj5OYXRpb25hbCBJ bnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZAogICAgICAgICAgICBUZWNobm9sb2d5PC9vcmdhbml6 YXRpb24+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0ZSBtb250aD0iSnVuZSIg eWVhcj0iMjAwOSIgLz4KICAgICAgICA8L2Zyb250PgogICAgICAgIDxmb3JtYXQgdGFyZ2V0PSJo dHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvZmlwcy9maXBzMTg2LTMvZmlwc18xODYt My5wZGYiIHR5cGU9IlBERiIgLz4KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJGSVBTIiB2YWx1 ZT0iUFVCIDE4Ni0zIiAvPgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5j aG9yPSJVU0ExNSI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPlVuaWNvZGUgTm9y bWFsaXphdGlvbiBGb3JtczwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iTWFy ayBEYXZpcyIgaW5pdGlhbHM9Ik0uIiBzdXJuYW1lPSJEYXZpcyI+CiAgICAgICAgICAgIDxhZGRy ZXNzPgogICAgICAgICAgICAgIDxlbWFpbD5tYXJrZGF2aXNAZ29vZ2xlLmNvbTwvZW1haWw+CiAg ICAgICAgICAgIDwvYWRkcmVzcz4KICAgICAgICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxhdXRo b3IgZnVsbG5hbWU9IktlbiBXaGlzdGxlciIgaW5pdGlhbHM9IksuIiBzdXJuYW1lPSJXaGlzdGxl ciI+CiAgICAgICAgICAgIDxhZGRyZXNzPgogICAgICAgICAgICAgIDxlbWFpbD5rZW5AdW5pY29k ZS5vcmc8L2VtYWlsPgogICAgICAgICAgICA8L2FkZHJlc3M+CiAgICAgICAgICA8L2F1dGhvcj4K CiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJNYXJ0aW4gRCZ1dW1sO3JzdCIgaW5pdGlhbHM9 Ik0uIgogICAgICAgICAgICAgICAgICBzdXJuYW1lPSJEJnV1bWw7cnN0Ij48L2F1dGhvcj4KCiAg ICAgICAgICA8ZGF0ZSBkYXk9IjAzIiBtb250aD0iMDkiIHllYXI9IjIwMDkiIC8+CiAgICAgICAg PC9mcm9udD4KCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iVW5pY29kZSBTdGFuZGFyZCBBbm5l eCIgdmFsdWU9IjE1IiAvPgogICAgICA8L3JlZmVyZW5jZT4KICAgIDwvcmVmZXJlbmNlcz4KCiAg ICA8cmVmZXJlbmNlcyB0aXRsZT0iSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICZPQVNJ Uy5zYW1sLWNvcmUtMi4wLW9zOwoKICAgICAgJlczQy5DUi14bWwxMS0yMDAyMTAxNTsKCiAgICAg ICZSRkMzMjc1OwoKICAgICAgJlJGQzQxMjI7CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iU1dU Ij4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+U2ltcGxlIFdlYiBUb2tlbiAoU1dU KTwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iRGljayBIYXJkdCIgaW5pdGlh bHM9IkQuIiBzdXJuYW1lPSJIYXJkdCI+PC9hdXRob3I+CgogICAgICAgICAgPGF1dGhvciBmdWxs bmFtZT0iWWFyb24gWS4gR29sYW5kIiBpbml0aWFscz0iWS5ZLiIgc3VybmFtZT0iR29sYW5kIj48 L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0ZSBtb250aD0iTm92ZW1iZXIiIHllYXI9IjIwMDkiIC8+ CiAgICAgICAgPC9mcm9udD4KICAgICAgICA8Zm9ybWF0IHRhcmdldD0iaHR0cDovL29hdXRoLXdy YXAtd2cuZ29vZ2xlZ3JvdXBzLmNvbS93ZWIvU1dULXYwLjkuNS4xLnBkZj9nZGE9U240TXNFTUFB QUJGQjdQRkFGaVZlZFB0amNxVDh1dUlJbUhYVWtzTlVLTVhMeXJTdW1Bc19kRjJ0emxRMzNSaFQx d1c4QkZZTzFReXRpSi1IZEdZWWNQaV8wOXBsOE43RldMdmVPYVdqemJZbnBua3BteGNXZyIgdHlw ZT0iUERGIiAvPgogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlZlcnNpb24iIHZhbHVlPSIwLjku NS4xIiAvPgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJNYWdp Y1NpZ25hdHVyZXMiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5NYWdpYyBTaWdu YXR1cmVzPC90aXRsZT4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJKb2huIFBhbnplciAo ZWRpdG9yKSIgaW5pdGlhbHM9IkouIiBzdXJuYW1lPSJQYW56ZXIgKGVkaXRvcikiPjwvYXV0aG9y PgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IkJlbiBMYXVyaWUiIGluaXRpYWxzPSJCLiIg c3VybmFtZT0iTGF1cmllIj48L2F1dGhvcj4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJE aXJrIEJhbGZhbnoiIGluaXRpYWxzPSJELiIgc3VybmFtZT0iQmFsZmFueiI+PC9hdXRob3I+Cgog ICAgICAgICAgPGRhdGUgbW9udGg9IkF1Z3VzdCIgeWVhcj0iMjAxMCIgLz4KICAgICAgICA8L2Zy b250PgogICAgICAgIDxmb3JtYXQgdGFyZ2V0PSJodHRwOi8vc2FsbW9uLXByb3RvY29sLmdvb2ds ZWNvZGUuY29tL3N2bi90cnVuay9kcmFmdC1wYW56ZXItbWFnaWNzaWctZXhwZXJpbWVudGFsLTAw Lmh0bWwiIHR5cGU9IkhUTUwiIC8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5j ZSBhbmNob3I9IkpTUyI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPkpTT04gU2lt cGxlIFNpZ248L3RpdGxlPgoKCSAgPGF1dGhvciBmdWxsbmFtZT0iSm9obiBCcmFkbGV5IiBpbml0 aWFscz0iSi4iIHN1cm5hbWU9IkJyYWRsZXkiPgoJICAgIDxvcmdhbml6YXRpb24+aW5kZXBlbmRl bnQ8L29yZ2FuaXphdGlvbj4KCSAgPC9hdXRob3I+CgoJICA8YXV0aG9yIGZ1bGxuYW1lPSJOYXQg U2FraW11cmEgKGVkaXRvcikiIGluaXRpYWxzPSJOLiAiIHN1cm5hbWU9IlNha2ltdXJhIChlZGl0 b3IpIj4KCSAgICA8b3JnYW5pemF0aW9uPk5vbXVyYSBSZXNlYXJjaCBJbnN0aXR1dGU8L29yZ2Fu aXphdGlvbj4KCSAgPC9hdXRob3I+CgogICAgICAgICAgPGRhdGUgbW9udGg9IlNlcHRlbWJlciIg eWVhcj0iMjAxMCIgLz4KICAgICAgICA8L2Zyb250PgogICAgICAgIDxmb3JtYXQgdGFyZ2V0PSJo dHRwOi8vanNvbmVuYy5pbmZvL2pzcy8xLjAvIiB0eXBlPSJIVE1MIiAvPgogICAgICA8L3JlZmVy ZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJDYW52YXNBcHAiPgogICAgICAgIDxmcm9u dD4KICAgICAgICAgIDx0aXRsZT5DYW52YXMgQXBwbGljYXRpb25zPC90aXRsZT4KCiAgICAgICAg ICA8YXV0aG9yIGZ1bGxuYW1lPSJGYWNlYm9vayIgc3VybmFtZT0iRmFjZWJvb2siPjwvYXV0aG9y PgoKICAgICAgICAgIDxkYXRlIHllYXI9IjIwMTAiIC8+CiAgICAgICAgPC9mcm9udD4KICAgICAg ICA8Zm9ybWF0IHRhcmdldD0iaHR0cDovL2RldmVsb3BlcnMuZmFjZWJvb2suY29tL2RvY3MvYXV0 aGVudGljYXRpb24vY2FudmFzIiB0eXBlPSJIVE1MIiAvPgogICAgICA8L3JlZmVyZW5jZT4KCiAg ICA8L3JlZmVyZW5jZXM+CiAgPC9iYWNrPgo8L3JmYz4K --_005_4E1F6AAD24975D4BA5B168042967394324589908TK5EX14MBXC201r_-- From kristoffer.gronowski@ericsson.com Tue Oct 26 10:17:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9C63A69C5 for ; Tue, 26 Oct 2010 10:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcwBFvU0kXa6 for ; Tue, 26 Oct 2010 10:17:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 182D13A69CF for ; Tue, 26 Oct 2010 10:17:15 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9QHd04b024900 for ; Tue, 26 Oct 2010 12:39:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 26 Oct 2010 13:18:54 -0400 From: Kristoffer Gronowski To: "oauth@ietf.org" Date: Tue, 26 Oct 2010 13:18:53 -0400 Thread-Topic: Draf 10 OAuth chapter 2.1 question Thread-Index: Act1MZiEzxFBD0XQQ1+jz60a7Grs0gAABllQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Draf 10 OAuth chapter 2.1 question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:17:26 -0000 Hi! Just wondering for clarification on the example. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code&client_id=3Ds6BhdRkqt3&code=3Di1WsRn1u= B1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb Alternatively, the client MAY include the password in the request body using the following parameter: client_secret REQUIRED. The client password. For example (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dauthorization_code&client_id=3Ds6BhdRkqt3& client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb When searching for the password should also the user part be used? If you Base64 decode czZCaGRSa3F0MzpnWDFmQmF0M2JW you get: s6BhdRkqt3:gX1fBat3bV So it is sending client_id:client_secret. In that case the FORM has a redundant client_id parameter. Should an implementation search for client_id in the basic header or not? If not I guess that a valid basic auth header could be just :client_secret = or in this case :gX1fBat3bV? Might be good with a clarification here. BR Kristoffer From Michael.Jones@microsoft.com Tue Oct 26 16:32:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C5D3A6879 for ; Tue, 26 Oct 2010 16:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz8-XGEj7EFr for ; Tue, 26 Oct 2010 16:31:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C2F173A6822 for ; Tue, 26 Oct 2010 16:31:40 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 26 Oct 2010 16:33:28 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.105]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Tue, 26 Oct 2010 16:33:28 -0700 From: Mike Jones To: "oauth@ietf.org" , "openid-specs-ab@lists.openid.net" , "openid-specs-connect@lists.openid.net" Thread-Topic: Simple Web Discovery Thread-Index: Act1ZjJjDCe6rYI9TGy/HfaZ555Xaw== Date: Tue, 26 Oct 2010 23:33:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 23:32:11 -0000 --_004_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_" --_000_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having a simple discovery method for services and resources is key to enabl= ing many Internet scenarios that require interactions among parties that do= not have pre-established relationships. For instance, if Joe, with e-mail= address joe@example.com, wants to share his calendar with Mary, then Mary'= s calendar service, in the general case, will need to discover the location= of Joe's calendar service. For example, Mary's calendar service might dis= cover that Joe's calendar service is located at http://calendars.proseware.= com/calendar/joseph by doing discovery for a service named urn:adatum.com:c= alendar at example.com for the account joe. Yaron Goland and I are submitting this Simple Web D= iscovery (SWD) draft (attached and at http://self-issued.info/docs/draft-jones-= simple-web-discovery-00.html) for consideration by the community to address= this need. SWD is simple to understand and implement, enables different p= ermissions to be applied to discovery of different services, and is JSON-ba= sed. I look forward to discussing this with many of you next week at IIW. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ha= ving a simple discovery method for services and resources is key to enablin= g many Internet scenarios that require interactions among parties that do n= ot have pre-established relationships.  For instance, if Joe, with e-mail address joe@example.com, wants to share = his calendar with Mary, then Mary’s calendar service, in the general = case, will need to discover the location of Joe’s calendar service.&n= bsp; For example, Mary’s calendar service might discover that Joe’s calendar service is located at http://calendars.proseware= .com/calendar/joseph by doing discovery for a service named urn:adatum.com:= calendar  at example.com for the account joe.

 

Yaron Goland and I are submitting this Simple Web Discovery (SWD) draft (attached and at http://self-issued.info/docs/draft-jones-simple-web-discovery-00.htm= l) for consideration by the community to address this need.  SWD i= s simple to understand and implement, enables different permissions to be applied to discovery of different services, an= d is JSON-based.  I look forward to discussing this with many of you n= ext week at IIW.

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_-- --_004_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_ Content-Type: text/html; name="draft-jones-simple-web-discovery-00.html" Content-Description: draft-jones-simple-web-discovery-00.html Content-Disposition: attachment; filename="draft-jones-simple-web-discovery-00.html"; size=30798; creation-date="Mon, 25 Oct 2010 23:30:09 GMT"; modification-date="Tue, 26 Oct 2010 20:36:07 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+U2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNXRCk8L3RpdGxlPgo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 dGYtOCI+CjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJTaW1wbGUgV2ViIERpc2Nv dmVyeSAoU1dEKSI+CjxtZXRhIG5hbWU9ImtleXdvcmRzIiBjb250ZW50PSJSRkMsIFJlcXVlc3Qg Zm9yIENvbW1lbnRzLCBJLUQsIEludGVybmV0LURyYWZ0LCBEaXNjb3ZlcnksIEZpbmdlciI+Cjxt ZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0ieG1sMnJmYyB2MS4zNSAoaHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvKSI+CjxzdHlsZSB0eXBlPSd0ZXh0L2Nzcyc+PCEtLQogICAgICAgIGJvZHkg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IHZlcmRhbmEsIGNoYXJjb2FsLCBoZWx2ZXRp Y2EsIGFyaWFsLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsg Y29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7CiAgICAgICAgICAgICAgICBtYXJn aW46IDJlbTsKICAgICAgICB9CiAgICAgICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgICAg ICAgICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBtb25hY28sICJNUyBTYW5zIFNlcmlm IiwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsg Zm9udC1zdHlsZTogbm9ybWFsOwogICAgICAgIH0KICAgICAgICBoMSB7IGNvbG9yOiAjOTAwOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgdGV4dC1hbGlnbjogcmlnaHQ7IH0KICAgICAg ICBoMyB7IGNvbG9yOiAjMzMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAg ICAgICB0ZC5SRkNidWcgewogICAgICAgICAgICAgICAgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7CiAgICAgICAgICAgICAgICB3aWR0aDogMzBweDsgaGVpZ2h0OiAz MHB4OyBwYWRkaW5nLXRvcDogMnB4OwogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjoganVzdGlm eTsgdmVydGljYWwtYWxpZ246IG1pZGRsZTsKICAgICAgICAgICAgICAgIGJhY2tncm91bmQtY29s b3I6ICMwMDA7CiAgICAgICAgfQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLlJGQyB7CiAgICAgICAg ICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBT ZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZv bnQtd2VpZ2h0OiBib2xkOyBjb2xvcjogIzY2NjsKICAgICAgICB9CiAgICAgICAgdGQuUkZDYnVn IHNwYW4uaG90VGV4dCB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogY2hhcmNvYWwsIG1v bmFjbywgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1z ZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtYWxpZ246IGNl bnRlcjsgY29sb3I6ICNGRkY7CiAgICAgICAgfQoKICAgICAgICB0YWJsZS5UT0NidWcgeyB3aWR0 aDogMzBweDsgaGVpZ2h0OiAxNXB4OyB9CiAgICAgICAgdGQuVE9DYnVnIHsKICAgICAgICAgICAg ICAgIHRleHQtYWxpZ246IGNlbnRlcjsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVweDsKICAgICAg ICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjOTAwOwogICAgICAgIH0K ICAgICAgICB0ZC5UT0NidWcgYSB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNv LCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgc2Fucy1zZXJp ZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXNpemU6IHgtc21hbGw7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNr Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsKICAgICAgICB9CgogICAgICAgIHRkLmhlYWRlciB7 CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiB4LXNtYWxsOwogICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246IHRv cDsgd2lkdGg6IDMzJTsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNv bG9yOiAjNjY2OwogICAgICAgIH0KICAgICAgICB0ZC5hdXRob3IgeyBmb250LXdlaWdodDogYm9s ZDsgZm9udC1zaXplOiB4LXNtYWxsOyBtYXJnaW4tbGVmdDogNGVtOyB9CiAgICAgICAgdGQuYXV0 aG9yLXRleHQgeyBmb250LXNpemU6IHgtc21hbGw7IH0KCiAgICAgICAgLyogaW5mbyBjb2RlIGZy b20gU2FudGFLbGF1c3MgYXQgaHR0cDovL3d3dy5tYWRhYm91dHN0eWxlLmNvbS90b29sdGlwMi5o dG1sICovCiAgICAgICAgYS5pbmZvIHsKICAgICAgICAgICAgICAgIC8qIFRoaXMgaXMgdGhlIGtl eS4gKi8KICAgICAgICAgICAgICAgIHBvc2l0aW9uOiByZWxhdGl2ZTsKICAgICAgICAgICAgICAg IHotaW5kZXg6IDI0OwogICAgICAgICAgICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAg ICAgIH0KICAgICAgICBhLmluZm86aG92ZXIgewogICAgICAgICAgICAgICAgei1pbmRleDogMjU7 CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAg ICAgICB9CiAgICAgICAgYS5pbmZvIHNwYW4geyBkaXNwbGF5OiBub25lOyB9CiAgICAgICAgYS5p bmZvOmhvdmVyIHNwYW4uaW5mbyB7CiAgICAgICAgICAgICAgICAvKiBUaGUgc3BhbiB3aWxsIGRp c3BsYXkganVzdCBvbiA6aG92ZXIgc3RhdGUuICovCiAgICAgICAgICAgICAgICBkaXNwbGF5OiBi bG9jazsKICAgICAgICAgICAgICAgIHBvc2l0aW9uOiBhYnNvbHV0ZTsKICAgICAgICAgICAgICAg IGZvbnQtc2l6ZTogc21hbGxlcjsKICAgICAgICAgICAgICAgIHRvcDogMmVtOyBsZWZ0OiAtNWVt OyB3aWR0aDogMTVlbTsKICAgICAgICAgICAgICAgIHBhZGRpbmc6IDJweDsgYm9yZGVyOiAxcHgg c29saWQgIzMzMzsKICAgICAgICAgICAgICAgIGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9y OiAjRUVFOwogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogbGVmdDsKICAgICAgICB9CgogICAg ICAgIGEgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIGE6bGluayAgICB7IGNvbG9yOiAj OTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgICAgIGE6dmlzaXRlZCB7 IGNvbG9yOiAjNjMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgICAgIGE6 YWN0aXZlICB7IGNvbG9yOiAjNjMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoK ICAgICAgICBwIHsgbWFyZ2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAg ICBwLmNvcHlyaWdodCB7IGZvbnQtc2l6ZTogeC1zbWFsbDsgfQogICAgICAgIHAudG9jIHsgZm9u dC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6IGJvbGQ7IG1hcmdpbi1sZWZ0OiAzZW07IH0KICAg ICAgICB0YWJsZS50b2MgeyBtYXJnaW46IDAgMCAwIDNlbTsgcGFkZGluZzogMDsgYm9yZGVyOiAw OyB2ZXJ0aWNhbC1hbGlnbjogdGV4dC10b3A7IH0KICAgICAgICB0ZC50b2MgeyBmb250LXNpemU6 IHNtYWxsOyBmb250LXdlaWdodDogYm9sZDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9Cgog ICAgICAgIG9sLnRleHQgeyBtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQog ICAgICAgIHVsLnRleHQgeyBtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQog ICAgICAgIGxpICAgICAgeyBtYXJnaW4tbGVmdDogM2VtOyB9CgogICAgICAgIC8qIFJGQy0yNjI5 IDxzcGFueD5zIGFuZCA8YXJ0d29yaz5zLiAqLwogICAgICAgIGVtICAgICB7IGZvbnQtc3R5bGU6 IGl0YWxpYzsgfQogICAgICAgIHN0cm9uZyB7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAg ZGZuICAgIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAg IGNpdGUgICB7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAg ICAgIHR0ICAgICB7IGNvbG9yOiAjMDM2OyB9CiAgICAgICAgdHQsIHByZSwgcHJlIGRmbiwgcHJl IGVtLCBwcmUgY2l0ZSwgcHJlIHNwYW4gewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6ICJD b3VyaWVyIE5ldyIsIENvdXJpZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsKICAgICAg ICB9CiAgICAgICAgcHJlIHsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGxlZnQ7IHBhZGRp bmc6IDRweDsKICAgICAgICAgICAgICAgIGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAj Q0NDOwogICAgICAgIH0KICAgICAgICBwcmUgZGZuICB7IGNvbG9yOiAjOTAwOyB9CiAgICAgICAg cHJlIGVtICAgeyBjb2xvcjogIzY2RjsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQzsgZm9udC13ZWln aHQ6IG5vcm1hbDsgfQogICAgICAgIHByZSAua2V5IHsgY29sb3I6ICMzM0M7IGZvbnQtd2VpZ2h0 OiBib2xkOyB9CiAgICAgICAgcHJlIC5pZCAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSAu c3RyIHsgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNDRkY7IH0KICAgICAgICBwcmUg LnZhbCB7IGNvbG9yOiAjMDY2OyB9CiAgICAgICAgcHJlIC5yZXAgeyBjb2xvcjogIzkwOTsgfQog ICAgICAgIHByZSAub3RoIHsgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNGQ0Y7IH0K ICAgICAgICBwcmUgLmVyciB7IGJhY2tncm91bmQtY29sb3I6ICNGQ0M7IH0KCiAgICAgICAgLyog UkZDLTI2MjkgPHRleHR0YWJsZT5zLiAqLwogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCwg dGFibGUuaGVhZGVycywgdGFibGUubm9uZSB7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNt YWxsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGJvcmRlci13aWR0aDogMnB4OwogICAgICAgICAgICAg ICAgdmVydGljYWwtYWxpZ246IHRvcDsgYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZTsKICAgICAg ICB9CiAgICAgICAgdGFibGUuYWxsLCB0YWJsZS5mdWxsIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsg Ym9yZGVyLWNvbG9yOiBibGFjazsgfQogICAgICAgIHRhYmxlLmhlYWRlcnMsIHRhYmxlLm5vbmUg eyBib3JkZXItc3R5bGU6IG5vbmU7IH0KICAgICAgICB0aCB7CiAgICAgICAgICAgICAgICBmb250 LXdlaWdodDogYm9sZDsgYm9yZGVyLWNvbG9yOiBibGFjazsKICAgICAgICAgICAgICAgIGJvcmRl ci13aWR0aDogMnB4IDJweCAzcHggMnB4OwogICAgICAgIH0KICAgICAgICB0YWJsZS5hbGwgdGgs IHRhYmxlLmZ1bGwgdGggeyBib3JkZXItc3R5bGU6IHNvbGlkOyB9CiAgICAgICAgdGFibGUuaGVh ZGVycyB0aCB7IGJvcmRlci1zdHlsZTogbm9uZSBub25lIHNvbGlkIG5vbmU7IH0KICAgICAgICB0 YWJsZS5ub25lIHRoIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9CiAgICAgICAgdGFibGUuYWxsIHRk IHsKICAgICAgICAgICAgICAgIGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogIzMz MzsKICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDogMXB4IDJweDsKICAgICAgICB9CiAgICAg ICAgdGFibGUuZnVsbCB0ZCwgdGFibGUuaGVhZGVycyB0ZCwgdGFibGUubm9uZSB0ZCB7IGJvcmRl ci1zdHlsZTogbm9uZTsgfQoKICAgICAgICBociB7IGhlaWdodDogMXB4OyB9CiAgICAgICAgaHIu aW5zZXJ0IHsKICAgICAgICAgICAgICAgIHdpZHRoOiA4MCU7IGJvcmRlci1zdHlsZTogbm9uZTsg Ym9yZGVyLXdpZHRoOiAwOwogICAgICAgICAgICAgICAgY29sb3I6ICNDQ0M7IGJhY2tncm91bmQt Y29sb3I6ICNDQ0M7CiAgICAgICAgfQotLT48L3N0eWxlPgo8L2hlYWQ+Cjxib2R5Pgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIHdpZHRoPSI2NiUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIj48dHI+PHRkPjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSIxMDAlIiBib3JkZXI9 IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMSI+Cjx0cj48dGQgY2xhc3M9ImhlYWRl ciI+TmV0d29yayBXb3JraW5nIEdyb3VwPC90ZD48dGQgY2xhc3M9ImhlYWRlciI+TS4gSm9uZXMg KGVkaXRvcik8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+SW50ZXJuZXQtRHJhZnQ8 L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ZLiBHb2xhbmQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImhlYWRlciI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8L3RkPjx0ZCBjbGFzcz0i aGVhZGVyIj5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+RXhwaXJl czogQXByaWwgMjksIDIwMTE8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5PY3RvYmVyIDI2LCAyMDEw PC90ZD48L3RyPgo8L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPgo8aDE+PGJyIC8+U2ltcGxlIFdl YiBEaXNjb3ZlcnkgKFNXRCk8YnIgLz5kcmFmdC1qb25lcy1zaW1wbGUtd2ViLWRpc2NvdmVyeS0w MDwvaDE+Cgo8aDM+QWJzdHJhY3Q8L2gzPgoKPHA+CiAgICAgICAgU2ltcGxlIFdlYiBEaXNjb3Zl cnkgKFNXRCkgZGVmaW5lcyBhIEhUVFBTIEdFVCBiYXNlZCBtZWNoYW5pc20gdG8gZGlzY292ZXIg dGhlIGxvY2F0aW9uIG9mIGEgZ2l2ZW4gdHlwZSBvZiBzZXJ2aWNlIGZvciBhIGdpdmVuIHByaW5j aXBhbAogICAgICAgIHN0YXJ0aW5nIG9ubHkgd2l0aCBhIGRvbWFpbiBuYW1lLgogICAgICAKPC9w Pgo8aDM+UmVxdWlyZW1lbnRzIExhbmd1YWdlPC9oMz4KCjxwPgogICAgICAgIFRoZSBrZXkgd29y ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwK ICAgICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpcwogICAgICAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMTE5Jz5SRkMgMjEx OTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CcmFkbmVyLCBTLiwgJmxkcXVvO0tl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzLCZy ZHF1bzsgTWFyY2gmbmJzcDsxOTk3Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzIxMTld LgogICAgICAKPC9wPgo8aDM+U3RhdHVzIG9mIHRoaXMgTWVtbzwvaDM+CjxwPgpUaGlzIEludGVy bmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCAgaW4gZnVsbApjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92 aXNpb25zIG9mIEJDUCZuYnNwOzc4IGFuZCBCQ1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQp3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBj dXJyZW50CkludGVybmV0LURyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZHJhZnRzL2N1cnJlbnQvLjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLgpJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1h dGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhlciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHByb2dy ZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFw cmlsIDI5LCAyMDExLjwvcD4KCjxoMz5Db3B5cmlnaHQgTm90aWNlPC9oMz4KPHA+CkNvcHlyaWdo dCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQpk b2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3A+CjxwPgpUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsClByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCnB1YmxpY2F0aW9uIG9mIHRo aXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwpjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QK dG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9j dW1lbnQgbXVzdAppbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiA0LmUgb2YKdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCmRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBC U0QgTGljZW5zZS48L3A+CjxhIG5hbWU9InRvYyI+PC9hPjxiciAvPjxociAvPgo8aDM+VGFibGUg b2YgQ29udGVudHM8L2gzPgo8cCBjbGFzcz0idG9jIj4KPGEgaHJlZj0iI2FuY2hvcjEiPjEuPC9h PiZuYnNwOwpJbnRyb2R1Y3Rpb248YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjIiPjIuPC9hPiZuYnNw OwpBIFNpbXBsZSBXZWIgRGlzY292ZXJ5IFJlcXVlc3Q8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjMi PjMuPC9hPiZuYnNwOwpTaW1wbGUgV2ViIERpc2NvdmVyeSBSZXNwb25zZXM8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjMuMS48L2E+Jm5ic3A7CkEgcmVz cG9uc2UgY29udGFpbmluZyBvbmUgb3IgbW9yZSBsb2NhdGlvbnM8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUiPjMuMi48L2E+Jm5ic3A7ClJlZGlyZWN0aW5n IGFsbCBTaW1wbGUgV2ViIERpc2NvdmVyeSBSZXF1ZXN0czxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNiI+My4zLjwvYT4mbmJzcDsKNDAxIFVuYXV0aG9yaXpl ZCBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y NyI+My40LjwvYT4mbmJzcDsKT3RoZXIgSFRUUCAxLjEgUmVzcG9uc2VzPGJyIC8+CjxhIGhyZWY9 IiNJQU5BIj40LjwvYT4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczxiciAvPgo8YSBocmVmPSIj U2VjdXJpdHkiPjUuPC9hPiZuYnNwOwpTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciAvPgo8YSBo cmVmPSIjcmZjLnJlZmVyZW5jZXMxIj42LjwvYT4mbmJzcDsKUmVmZXJlbmNlczxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj42LjEuPC9hPiZu YnNwOwpOb3JtYXRpdmUgUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMyIj42LjIuPC9hPiZuYnNwOwpJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzPGJyIC8+CjxhIGhyZWY9IiNyZmMuYXV0aG9ycyI+JiMxNjc7PC9hPiZuYnNwOwpBdXRo b3JzJyBBZGRyZXNzZXM8YnIgLz4KPC9wPgo8YnIgY2xlYXI9ImFsbCIgLz4KCjxhIG5hbWU9ImFu Y2hvcjEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xIj48L2E+PGgzPjEuJm5ic3A7Cklu dHJvZHVjdGlvbjwvaDM+Cgo8cD4KICAgICAgICBTaW1wbGUgV2ViIERpc2NvdmVyeSAoU1dEKSBk ZWZpbmVzIGEgSFRUUFMgR0VUIGJhc2VkIG1lY2hhbmlzbSB0byBkaXNjb3ZlciB0aGUgbG9jYXRp b24gb2YgYSBnaXZlbiB0eXBlIG9mIHNlcnZpY2UgZm9yIGEgZ2l2ZW4gcHJpbmNpcGFsCiAgICAg ICAgc3RhcnRpbmcgb25seSB3aXRoIGEgZG9tYWluIG5hbWUuIFNXRCByZXF1ZXN0cyB1c2UgdGhl IHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBmb3JtYXQgdG8gc3BlY2lmeSBhIFVSSSBmb3IgdGhlIHBy aW5jaXBhbCBhbmQgYW5vdGhlciBVUkkKICAgICAgICBmb3IgdGhlIHR5cGUgb2Ygc2VydmljZSBi ZWluZyBzb3VnaHQuIElmIHRoZSByZXF1ZXN0IGlzIHN1Y2Nlc3NmdWwgdGhlbiB0aGUgcmVzcG9u c2UsIGJ5IGRlZmF1bHQsIGlzIGEgSlNPTiBvYmplY3QgY29udGFpbmluZyBhbiBhcnJheSBvZiBV UklzIHRoYXQgcG9pbnQgdG8gd2hlcmUgdGhlCiAgICAgICAgcHJpbmNpcGFsIGhhcyBpbnN0YW5j ZXMgb2Ygc2VydmljZXMgb2YgdGhlIHJlcXVlc3RlZCB0eXBlLgogICAgICAKPC9wPgo8cD5Gb3Ig ZXhhbXBsZSwgbGV0IHVzIHNheSB0aGF0IGEgcmVxdWVzdGVyIHdhbnRzIHRvIGRpc2NvdmVyIHdo ZXJlIEpvZSBrZWVwcyBoaXMgY2FsZW5kYXIuIFRoZSByZXF1ZXN0ZXIgY291bGQgdGFrZSBKb2Un cyBlLW1haWwgYWRkcmVzcywKICAgICAgam9lQGV4YW1wbGUuY29tIGFuZCB0YWtlIGZyb20gaXQg aXRzIGRvbWFpbiB0byBjcmVhdGUgYSBIVFRQUyBHRVQgcmVxdWVzdCBvZiB0aGUgZm9sbG93aW5n IGZvcm06CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KR0VUIC8ud2VsbC1rbm93bi9zaW1w bGUtd2ViLWRpc2NvdmVyeT9wcmluY2lwYWw9bWFpbHRvOmpvZUBleGFtcGxlLmNvbSZhbXA7c2Vy dmljZT11cm46YWRhdHVtLmNvbTpjYWxlbmRhciBIVFRQLzEuMQpIb3N0OiBleGFtcGxlLmNvbQoK SFRUUC8xLjEgMjAwIE8uSy4KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCgp7CiAibG9j YXRpb25zIjpbImh0dHA6Ly9jYWxlbmRhcnMucHJvc2V3YXJlLmNvbS9jYWxlbmRhcnMvam9zZXBo Il0KfQo8L3ByZT48L2Rpdj4KPHA+Tm90ZTogVGhlIHJlcXVlc3QtVVJJIGlzIGxlZnQgdW4tZW5j b2RlZCBpbiB0aGUgYWJvdmUgZXhhbXBsZQogICAgICBmb3IgdGhlIHNha2Ugb2YgcmVhZGFiaWxp dHkgaW4gdGhlIGFib3ZlIGV4YW1wbGUuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMiI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjIiPjwvYT48aDM+Mi4mbmJzcDsKQSBTaW1wbGUgV2ViIERpc2Nv dmVyeSBSZXF1ZXN0PC9oMz4KCjxwPkRvbWFpbnMgdGhhdCBzdXBwb3J0IFNXRCByZXF1ZXN0cyBN VVNUIG1ha2UgYXZhaWxhYmxlIGEgU1dEIHNlcnZlciBmb3IgdGhlaXIgZG9tYWluIGF0IHRoZSBw YXRoIC53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292ZXJ5LiAKICAgICAgVGhlIHN5bnRheCBh bmQgc2VtYW50aWNzIG9mICIud2VsbC1rbm93biIgYXJlIGRlZmluZWQgaW4gPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkM1Nzg1Jz5SRkMgNTc4NTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5Ob3R0aW5naGFtLCBNLiBhbmQgRS4gSGFtbWVyLUxhaGF2LCAmbGRxdW87RGVmaW5pbmcg V2VsbC1Lbm93biBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXJzIChVUklzKSwmcmRxdW87IEFw cmlsJm5ic3A7MjAxMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM1Nzg1XS4KICAgICAg InNpbXBsZS13ZWItZGlzY292ZXJ5IiBNVVNUIHBvaW50IHRvIGEgU1dEIHNlcnZlciBjb21wbGlh bnQgd2l0aCB0aGlzIHNwZWNpZmljYXRpb24uCjwvcD4KPHA+CiAgICAgICAgU1dEIHNlcnZlcnMg TVVTVCBzdXBwb3J0IHJlY2VpdmluZyBTV0QgcmVxdWVzdHMgdmlhIFRMUyAxLjIgYXMgZGVmaW5l ZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUyNDYnPlJGQyA1MjQ2PHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkRpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAmbGRxdW87 VGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiwm cmRxdW87IEF1Z3VzdCZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNTI0 Nl0gYW5kIE1BWSBzdXBwb3J0IAogICAgICAgIG90aGVyIHRyYW5zcG9ydCBsYXllciBzZWN1cml0 eSBtZWNoYW5pc21zIG9mIGVxdWl2YWxlbnQgc2VjdXJpdHkuIFNXRCBzZXJ2ZXJzIE1VU1QgcmVq ZWN0IFNXRCByZXF1ZXN0cyBzZW50IG92ZXIgcGxhaW4gSFRUUCBvciBhbnkgb3RoZXIKICAgICAg ICB0cmFuc3BvcnQgdGhhdCBkb2VzIG5vdCBwcm92aWRlIGJvdGggcHJpdmFjeSBhbmQgdmFsaWRh dGlvbiBvZiB0aGUgc2VydmVyJ3MgaWRlbnRpdHkuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIEEg U1dEIHNlcnZlciBpcyBxdWVyaWVkIHVzaW5nIGEgSFRUUFMgR0VUIHJlcXVlc3Qgd2l0aCB0aGUg cHJldmlvdXNseSBzcGVjaWZpZWQgcGF0aCBhbG9uZyB3aXRoIGEgcXVlcnkgc2VnbWVudCBjb250 YWluaW5nIGEgeC13d3ctZm9ybS11cmxlbmNvZGVkCiAgICAgICAgZm9ybSBhcyBkZWZpbmVkIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0Jz5IVE1MIDQu MDE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQsIEQu LCBhbmQgSS4gSmFjb2JzLCAmbGRxdW87SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVvOyBE ZWNlbWJlciZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbVzNDLlJFQyYjODIw OTtodG1sNDAxJiM4MjA5OzE5OTkxMjI0XS4gVGhlIGZvcm0gTVVTVCBjb250YWluIHR3byBuYW1l L3ZhbHVlIHBhaXJzIHRoYXQgTVVTVAogICAgICAgIGFwcGVhciBleGFjdGx5IG9uY2UsIHByaW5j aXBhbCBhbmQgc2VydmljZS4gQm90aCBuYW1lL3ZhbHVlIHBhaXJzIE1VU1QgaGF2ZSB2YWx1ZXMg dGhhdCBhcmUgc2V0IHRvIFVSSXMgKGFzIGRlZmluZWQgaW4gCiAgICAgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkMzOTg2Jz5SRkMgMzk4NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRx dW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRx dW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW1JGQzM5ODZd IC4gSWYgYW55IG9mIHRoZSBwcmV2aW91cyByZXF1aXJlbWVudHMKICAgICAgICBhcmUgbm90IG1l dCBpbiBhIFNXRCByZXF1ZXN0IHRoZW4gdGhlIHJlcXVlc3QgTVVTVCBiZSByZWplY3RlZCB3aXRo IGEgNDAwIEJhZCBSZXF1ZXN0LgogICAgICAKPC9wPgo8cD4KICAgICAgICBUaGUgU1dEIHJlcXVl c3QgZm9ybSBNQVkgY29udGFpbiBhZGRpdGlvbmFsIG5hbWUvdmFsdWUgcGFpcnMgYnV0IGlmIHRo b3NlIG5hbWUvdmFsdWUgcGFpcnMgYXJlIG5vdCByZWNvZ25pemVkIGJ5IHRoZSBTV0Qgc2VydmVy IHRoZW4gdGhlIFNXRAogICAgICAgIHNlcnZlciBNVVNUIGlnbm9yZSB0aGVtIGZvciBwcm9jZXNz aW5nIHB1cnBvc2VzLgogICAgICAKPC9wPgo8cD4KICAgICAgICBUaGUgcHJpbmNpcGFsIHF1ZXJ5 IGNvbXBvbmVudCBpcyBhIFVSSSB0aGF0IGlkZW50aWZpZXMgYW4gZW50aXR5LiBUaGUgc2Vydmlj ZSBxdWVyeSBjb21wb25lbnQgaXMgYSBVUkkgdGhhdCBpZGVudGlmaWVzIGEgc2VydmljZSB0eXBl LiBUaGUgc2VtYW50aWNzCiAgICAgICAgb2YgdGhlIFNXRCBxdWVyeSBpcyAiUGxlYXNlIHJldHVy biB0aGUgbG9jYXRpb24ocykgb2YgaW5zdGFuY2VzIG9mIHRoZSBzcGVjaWZpZWQgc2VydmljZSB0 eXBlIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWVkIHByaW5jaXBhbCIuIFRoZSBkZWZpbml0 aW9uCiAgICAgICAgb2YgVVJJcyB1c2VkIHRvIGlkZW50aWZ5IHByaW5jaXBhbHMgYW5kIHNlcnZp Y2VzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uCiAgICAgIAo8 L3A+CjxhIG5hbWU9ImFuY2hvcjMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zIj48L2E+ PGgzPjMuJm5ic3A7ClNpbXBsZSBXZWIgRGlzY292ZXJ5IFJlc3BvbnNlczwvaDM+Cgo8YSBuYW1l PSJhbmNob3I0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xIj48L2E+PGgzPjMuMS4m bmJzcDsKQSByZXNwb25zZSBjb250YWluaW5nIG9uZSBvciBtb3JlIGxvY2F0aW9uczwvaDM+Cgo8 cD5Vbmxlc3MgYW5vdGhlciBjb250ZW50LXR5cGUgaXMgbmVnb3RpYXRlZCwgYSAyMDAgTy5LLiBy ZXNwb25zZSB0byBhIFNXRCByZXF1ZXN0IHRoYXQgY29udGFpbnMgdGhlIGluZm9ybWF0aW9uIHJl cXVlc3RlZAogICAgICAgIE1VU1QgcmV0dXJuIGNvbnRlbnQgb2YgdHlwZSBhcHBsaWNhdGlvbi9q c29uIAogICAgICAgIGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjI3 Jz5SRkMgNDYyNzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9ja2ZvcmQsIEQu LCAmbGRxdW87VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlwZSBmb3IgSmF2YVNjcmlwdCBP YmplY3QgTm90YXRpb24gKEpTT04pLCZyZHF1bzsgSnVseSZuYnNwOzIwMDYuPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiBbUkZDNDYyN10uIFRoZSBKU09OIHJlc3BvbnNlIE1VU1QgY29udGFpbiBh IEpTT04gb2JqZWN0IHRoYXQgY29udGFpbnMgYSBtZW1iZXIgcGFpciB3aG9zZQogICAgICAgIG5h bWUgaXMgdGhlIHN0cmluZyAibG9jYXRpb25zIiBhbmQgd2hvc2UgdmFsdWUgaXMgYW4gYXJyYXkg b2Ygc3RyaW5ncyB0aGF0IGFyZSBlYWNoIGEgVVJJIHBvaW50aW5nIHRvIGEgbG9jYXRpb24gd2hl cmUgdGhlCiAgICAgICAgZGVzaXJlZCBzZXJ2aWNlIHR5cGUgYmVsb25naW5nIHRvIHRoZSBzcGVj aWZpZWQgcHJpbmNpcGFsIGNhbiBiZSBmb3VuZC4gVGhlcmUgYXJlIG5vIHNlbWFudGljcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIG9yZGVyIGluCiAgICAgICAgd2hpY2ggdGhlIFVSSXMgYXJlIGxpc3Rl ZCBpbiB0aGUgYXJyYXkuCjwvcD4KPHA+VGhlIEpTT04gb2JqZWN0IE1BWSBjb250YWluIG90aGVy IG1lbWJlcnMgYnV0IGEgcmVjZWl2ZXIgb2YgdGhlIG9iamVjdCBNQVkgaWdub3JlIGFueSBtZW1i ZXIgcGFpcnMgd2hvc2UgbmFtZSBpdCBkb2VzIG5vdCByZWNvZ25pemUuCjwvcD4KPGEgbmFtZT0i YW5jaG9yNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMiI+PC9hPjxoMz4zLjIuJm5i c3A7ClJlZGlyZWN0aW5nIGFsbCBTaW1wbGUgV2ViIERpc2NvdmVyeSBSZXF1ZXN0czwvaDM+Cgo8 cD4KICAgICAgICAgIFNXRCByZXF1ZXN0cyBieSBkZWZpbml0aW9uIHN0YXJ0IG9mZiBieSBiZWlu ZyBpc3N1ZWQgdG8gdGhlIC53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292ZXJ5IGxvY2F0aW9u LiBCdXQgbG9jYXRpbmcgYSBTV0Qgc2VydmVyIGF0IGEgcm9vdCBsb2NhdGlvbgoKICAgICAgICAg IGNhbiBwcm92ZSBpbmNvbnZlbmllbnQuIFRvIGVuYWJsZSBzZXJ2aWNlIGxldmVsIHJlZGlyZWN0 aW9uIGEgU1dEIHNlcnZlciBNQVkgcmV0dXJuCiAgICAgICAgICBhIDIwMCBPLmsuIHRvIGEgSFRU UFMgcmVxdWVzdCB3aXRoIGEgY29udGVudCB0eXBlIG9mIGFwcGxpY2F0aW9uL2pzb24gKG9yIHdo YXRldmVyIG90aGVyIGNvbnRlbnQgdHlwZSBoYXMgYmVlbiBuZWdvdGlhdGVkKSB0aGF0IGNvbnRh aW5zIGEgCiAgICAgICAgICBKU09OIG9iamVjdCB0aGF0IGNvbnRhaW5zIGEgbWVtYmVyIHBhaXIg d2hvc2UgbmFtZSBpcyB0aGUgc3RyaW5nICJTV0Rfc2VydmljZV9yZWRpcmVjdCIgd2hvc2UgdmFs dWUgaXMgYSBKU09OIG9iamVjdCB3aXRoIGEgbWVtYmVyIHBhaXIgd2hvc2UgbmFtZSAKICAgICAg ICAgIGlzICJsb2NhdGlvbiIgYW5kIHdob3NlCiAgICAgICAgICB2YWx1ZSBpcyBhIHN0cmluZyB0 aGF0IGVuY29kZXMgYSBVUkkuIE9wdGlvbmFsbHkgdGhlIEpTT04gb2JqZWN0IHZhbHVlIG9mICJT V0Rfc2VydmljZV9yZWRpcmVjdCIgTUFZIGFsc28gY29udGFpbiBhIG1lbWJlciB3aG9zZSBuYW1l IGlzICJleHBpcmVzIiAKICAgICAgICAgIGFuZCB3aG9zZSB2YWx1ZSBpcwogICAgICAgICAgYSBK U09OIG51bWJlciB0aGF0IGVuY29kZXMgYW4gaW50ZWdlci4KICAgICAgICAKPC9wPgo8cD4KCSAg ICAgICAgQSBTV0MgY29tcGxpYW50IGNsaWVudCBNVVNUIHN1cHBvcnQgdGhlIFNXRF9zZXJ2aWNl X3JlZGlyZWN0IHJlc3BvbnNlLgoJICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgSlNPTiBv YmplY3RzIE1BWSBjb250YWluIG90aGVyIG1lbWJlcnMgYnV0IGEgcmVjZWl2ZXIgb2YgdGhlIG9i amVjdHMgTUFZIGlnbm9yZSBhbnkgcGFpcnMgd2hvc2UgbmFtZSBpdCBkb2VzIG5vdCByZWNvZ25p emUuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgbG9jYXRpb24gbWVtYmVyIGlkZW50 aWZpZXMgdGhlIFVSSSB0aGF0IHRoZSBjYWxsZXIgTVVTVCByZWRpcmVjdCBhbGwgU1dEIHJlcXVl c3RzIGZvciB0aGF0IGRvbWFpbiB0byB1bnRpbCB0aGUgZXhwaXJlcyB0aW1lIGlzIG1ldC4gU1dE CiAgICAgICAgICByZXF1ZXN0cyBmb3IgdGhlIHJlZGlyZWN0ZWQgZG9tYWluIE1VU1QgYmUgY29u c3RydWN0ZWQgYnkgdGFraW5nIHRoZSBVUkkgcmV0dXJuZWQgaW4gdGhlIGxvY2F0aW9uIGFuZCB1 c2luZyBpdCBhcyB0aGUgYmFzZSBVUkkgdG8gd2hpY2ggCiAgICAgICAgICB0aGUgU1dEIGZvcm0g YXJndW1lbnRzIGFyZSB0aGVuIGFkZGVkIGFzIHF1ZXJ5IHBhcmFtZXRlcnMuIFRoZSBsb2NhdGlv biBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIHF1ZXJ5IGNvbXBvbmVudC4KICAgICAgICAKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPgpHRVQgLy53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292 ZXJ5P3ByaW5jaXBhbD1tYWlsdG86am9lQGV4YW1wbGUuY29tJmFtcDtzZXJ2aWNlPXVybjphZGF0 dW0uY29tOmNhbGVuZGFyIEhUVFAvMS4xCkhvc3Q6IGV4YW1wbGUuY29tCgpIVFRQLzEuMSAyMDAg Ty5LLgpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb24KCnsKICJTV0Rfc2VydmljZV9yZWRp cmVjdCI6CiAgewogICAibG9jYXRpb24iOiJodHRwczovL3N3ZC5wcm9zZXdhcmUuY29tL3N3ZF9z ZXJ2ZXIiLAogICAiZXhwaXJlcyI6IDEzMDA3NTIwMDEKICB9Cn0KCkdFVCAvc3dkX3NlcnZlcj9w cmluY2lwYWw9bWFpbHRvOmpvZUBleGFtcGxlLmNvbSZhbXA7c2VydmljZT11cm46YWRhdHVtLmNv bTpjYWxlbmRhciBIVFRQLzEuMQpIb3N0OiBzd2QucHJvc2V3YXJlLmNvbQoKSFRUUC8xLjEgMjAw IE8uSy4KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uCgp7CiAibG9jYXRpb25zIjpbImh0 dHA6Ly9jYWxlbmRhcnMucHJvc2V3YXJlLmNvbS9jYWxlbmRhcnMvam9zZXBoIl0KfQo8L3ByZT48 L2Rpdj4KPHA+Tm90ZTogVGhlIHJlcXVlc3QtVVJJcyBhcmUgbGVmdCB1bi1lbmNvZGVkIGluIHRo ZSBhYm92ZQogICAgICAgIGV4YW1wbGUgZm9yIHRoZSBzYWtlIG9mIHJlYWRhYmlsaXR5IGluIHRo ZSBhYm92ZSBleGFtcGxlLgo8L3A+CjxwPgogICAgICAgICAgVGhlIGxvY2F0aW9uIFVSSSBNVVNU IGJlIGEgSFRUUFMgVVJMLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIG9wdGlvbmFs IGV4cGlyZXMgbWVtYmVyIGlkZW50aWZpZXMgdGhlIHBvaW50IGluIHRpbWUgYXQgd2hpY2ggdGhl IGNhbGxlciBNVVNUIE5PVCByZWRpcmVjdCBpdHMgU1dEIHJlcXVlc3RzIGZvciB0aGF0IGRvbWFp biB0byB0aGUgcHJldmlvdXNseQogICAgICAgICAgb2J0YWluZWQgbG9jYXRpb24gYW5kIE1VU1Qg aW5zdGVhZCByZXR1cm4gdG8gdGhlIC53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292ZXJ5IGxv Y2F0aW9uLiBUaGUgdmFsdWUgb2YgdGhlIGV4cGlyZXMgbWVtYmVyIE1VU1QgZW5jb2RlCiAgICAg ICAgICB0aGUgbnVtYmVyIG9mIHNlY29uZHMgZnJvbSAxOTcwLTAxLTAxVDA6MDowWiBhcyBtZWFz dXJlZCBpbiBVVEMgdW50aWwgdGhlIGRlc2lyZWQgZGF0ZS90aW1lLiBTZWUgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkMzMzM5Jz5SRkMgMzMzOTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5LbHluZSwgRy4sIEVkLiBhbmQgQy4gTmV3bWFuLCAmbGRxdW87RGF0ZSBhbmQgVGltZSBv biB0aGUgSW50ZXJuZXQ6IFRpbWVzdGFtcHMsJnJkcXVvOyBKdWx5Jm5ic3A7MjAwMi48L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMzMzM5XSBmb3IgCiAgICAgICAgICBkZXRhaWxzIHJlZ2Fy ZGluZyBkYXRlL3RpbWVzIGluIGdlbmVyYWwgYW5kIFVUQyBpbiBwYXJ0aWN1bGFyLiBJZiB0aGUg ZXhwaXJlcyB2YWx1ZSBpcyBpbiB0aGUgcGFzdCBvciBpZiB0aGUgdmFsdWUgaXMgbW9yZSB0aGFu CiAgICAgICAgICBvbmUgaG91ciBpbiB0aGUgZnV0dXJlIHRoZW4gdGhlIHJlc3BvbnNlIE1VU1Qg YmUgdHJlYXRlZCBhcyBpZiBpdCBkaWRuJ3QgY29udGFpbiBhbiBleHBpcmVzIHZhbHVlLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgSWYgdGhlIGV4cGlyZXMgdmFsdWUgaXMgb21pdHRlZCBv ciBpZiBpdHMgdmFsdWUgaXMgaW5jb3JyZWN0IHRoZW4gdGhlIGV4cGlyZXMgdmFsdWUgTVVTVCBi ZSB0cmVhdGVkIGFzIGhhdmluZyBhIHZhbHVlIG9mIGV4YWN0bHkgb25lIGhvdXIgaW50byB0aGUg ZnV0dXJlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgSWYgYSBKU09OIHJlc3BvbnNlIGlz IHJlY2VpdmVkIHRoYXQgY29udGFpbnMgYm90aCBhIG1lbWJlciBwYWlyIHdpdGggdGhlIG5hbWUg IlNXRF9zZXJ2aWNlX3JlZGlyZWN0IiBhbmQgYSBtZW1iZXIgcGFpciB3aXRoIHRoZSBuYW1lICJs b2NhdGlvbnMiCiAgICAgICAgICBhcyBjaGlsZHJlbiBvZiB0aGUgb2JqZWN0IHJvb3QgdGhlbiB0 aGUgIlNXRF9zZXJ2aWNlX3JlZGlyZWN0IiBtZW1iZXIgcGFpciBNVVNUIGJlIGlnbm9yZWQuCiAg ICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjMuMyI+PC9hPjxoMz4zLjMuJm5ic3A7CjQwMSBVbmF1dGhvcml6ZWQgUmVzcG9uc2U8L2gzPgoK PHA+CiAgICAgICAgICBBIFNXRCBzZXJ2ZXIgTUFZIHJlc3BvbmQgdG8gYSByZXF1ZXN0IHdpdGgg YSA0MDEKICAgICAgICAgIFVuYXV0aG9yaXplZCBSZXNwb25zZSwgYXMgZGVzY3JpYmVkIGluIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNic+UkZDIDI2MTY8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+RmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0 eWssIEguLCBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAmbGRx dW87SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xLCZyZHF1bzsgSnVuZSZu YnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDMjYxNl0sIFNlY3Rpb24gMTAu ICBQZXIgdGhlIFJGQywKICAgICAgICAgIHRoZSByZXF1ZXN0IE1BWSBiZSByZXBlYXRlZCB3aXRo IGEgc3VpdGFibGUgQXV0aG9yaXphdGlvbgogICAgICAgICAgaGVhZGVyIGZpZWxkLiAgQXV0aG9y aXphdGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUgY29tbXVuaWNhdGVkCiAgICAgICAgICBpbiB0aGlz IG1hbm5lciwgaW5jbHVkaW5nIGEgSlNPTiBXZWIgVG9rZW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNKV1QnPltKV1RdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzIChlZGl0 b3IpLCBNLiwgQmFsZmFueiwgRC4sIEJyYWRsZXksIEouLCBHb2xhbmQsIFkuLCBQYW56ZXIsIEou LCBhbmQgTi4gU2FraW11cmEsICZsZHF1bztKU09OIFdlYiBUb2tlbiAoSldUKSwmcmRxdW87IE9j dG9iZXImbmJzcDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCgkKPC9wPgo8YSBuYW1l PSJhbmNob3I3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy40Ij48L2E+PGgzPjMuNC4m bmJzcDsKT3RoZXIgSFRUUCAxLjEgUmVzcG9uc2VzPC9oMz4KCjxwPgogICAgICAgICAgQSBTV0Qg c2VydmVyIE1BWSByZXR1cm4gb3RoZXIgSFRUUCAxLjEgcmVzcG9uc2VzLCBpbmNsdWRpbmcKICAg ICAgICAgIDQwNCBOb3QgRm91bmQsIDQwMCBCYWQgUmVxdWVzdCwgYW5kIDQwMyBGb3JiaWRkZW4u ICBTV0QKICAgICAgICAgIGltcGxlbWVudGF0aW9ucyBNVVNUIGNvcnJlY3RseSBoYW5kbGUgdGhl c2UgcmVzcG9uc2VzLgoJCjwvcD4KPGEgbmFtZT0iSUFOQSI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjQiPjwvYT48aDM+NC4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD5Q ZXIgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1Nzg1Jz5SRkMgNTc4NTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5Ob3R0aW5naGFtLCBNLiBhbmQgRS4gSGFtbWVyLUxhaGF2LCAm bGRxdW87RGVmaW5pbmcgV2VsbC1Lbm93biBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXJzIChV UklzKSwmcmRxdW87IEFwcmlsJm5ic3A7MjAxMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtS RkM1Nzg1XSB0aGUgZm9sbG93aW5nIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBpcyBvZmZlcmVkOgog ICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PlVSSSBzdWZmaXg8 L2R0Pgo8ZGQ+c2ltcGxlLXdlYi1kaXNjb3ZlcnkKPC9kZD4KPGR0PkNoYW5nZSBjb250cm9sbGVy PC9kdD4KPGRkPklFVEYKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24gZG9jdW1lbnQ8L2R0Pgo8ZGQ+ VGhpcyBSRkMKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgIAo8L3A+CjxhIG5hbWU9 IlNlY3VyaXR5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNSI+PC9hPjxoMz41LiZuYnNw OwpTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD4KICAgICAgICBTV0QgcmVzcG9uc2Vz IGNhbiBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gIFRoZXJlZm9yZQogICAgICAg IGEsIGdlbmVyYWwgYXBwcm9hY2ggaXMgdXNlZCB0byByZXF1aXJlIFRMUyBpbiBhbGwgY2FzZXMu IEJ1dAogICAgICAgIFRMUyBjYW4gb25seSBwcm92aWRlIGZvciBwcml2YWN5IGFuZCBzZXJ2ZXIg dmFsaWRhdGlvbiwgaXQKICAgICAgICBjYW5ub3QgdmFsaWRhdGUgdGhhdCB0aGUgcmVxdWVzdGVy IGlzIGF1dGhvcml6ZWQgdG8gc2VlIHRoZQogICAgICAgIHJlc3VsdHMgb2YgYSBxdWVyeS4gIFRo ZSBleGFjdCBtZWNoYW5pc20gdXNlZCB0byBkZXRlcm1pbmUgaWYKICAgICAgICB0aGUgcmVxdWVz dGVyIGlzIGF1dGhvcml6ZWQgdG8gc2VlIHRoZSByZXN1bHQgb2YgdGhlIHF1ZXJ5IGlzCiAgICAg ICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgogICAgICAKPC9wPgo8 cD4KCUJlY2F1c2UgU1dEIHJlc3BvbnNlcyBjYW4gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24sCgl0aGUgcmVxdWVzdG9yIG1heSBuZWVkIGF1dGhvcml6YXRpb24gdG8gcmVjZWl2ZSB0 aGVtLgoJU3RhbmRhcmQgSFRUUCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgTUFZIGJlIGVtcGxv eWVkIHRvCglyZXF1ZXN0IGF1dGhvcml6ZWQgYWNjZXNzLCBpbmNsdWRpbmcgdGhlIHVzZSBvZiBh biBIVFRQCglBdXRob3JpemF0aW9uIGhlYWRlciBmaWVsZCBpbiByZXF1ZXN0cywgd2hpY2ggaW4g dHVybiwgbWF5Cgljb250YWluIGEgSlNPTiBXZWIgVG9rZW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNKV1QnPltKV1RdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzIChlZGl0 b3IpLCBNLiwgQmFsZmFueiwgRC4sIEJyYWRsZXksIEouLCBHb2xhbmQsIFkuLCBQYW56ZXIsIEou LCBhbmQgTi4gU2FraW11cmEsICZsZHF1bztKU09OIFdlYiBUb2tlbiAoSldUKSwmcmRxdW87IE9j dG9iZXImbmJzcDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFtb25nCglvdGhlciBh dXRob3JpemF0aW9uIGRhdGEgZm9ybWF0cy4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhlIGFi aWxpdHkgdG8gcmVkaXJlY3QgYW4gZW50aXJlIFNXRCBzZXJ2ZXIgYXMgZGVmaW5lZCBpbgogICAg ICAgIHRoaXMgZG9jdW1lbnQgaXMgYW4gb2J2aW91cyBhdHRhY2sgcG9pbnQuIFRoaXMgaXMgYW5v dGhlcgogICAgICAgIHJlYXNvbiB3aHkgd2UgaGF2ZSBtYW5kYXRlZCBUTFMsIHNvIGFzIHRvIGJl IHN1cmUgdGhhdCB0aGUKICAgICAgICByZWRpcmVjdCBjYW4gb25seSBiZSByZWNlaXZlZCBvdmVy IGEgc2VjdXJlIGNvbm5lY3Rpb24uIFdlCiAgICAgICAgaGF2ZSBhbHNvIHB1dCBpbiB0aGUgdXBw ZXIgbGltaXQgb2YgNjAgbWludXRlcyBmb3IgYSByZWRpcmVjdAogICAgICAgIHNvIGFzIHRvIHBy b3ZpZGUgYSBwYXRoIGZvciByZWdhaW5pbmcgY29udHJvbCBvdmVyIHF1ZXJpZXMKICAgICAgICBz aG91bGQgYSBzdWNjZXNzZnVsIGF0dGFjayBiZSBsYXVuY2hlZCB0byByZXR1cm4gZmFsc2UKICAg ICAgICByZWRpcmVjdHMuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoZSBTV0Rfc2VydmljZV9y ZWRpcmVjdCBjYXBhYmlsaXR5IG1heSBjYXVzZSB1bmFudGljaXBhdGVkCiAgICAgICAgZmFpbHVy ZXMgaW4gY2FzZXMgd2hlcmUgYSByZXF1ZXN0b3IgbWF5IGhhdmUgcGVybWlzc2lvbnMgdG8KICAg ICAgICBkaXNjb3ZlciBjb250ZW50IGF0IHRoZSBvcmlnaW5hbCBTV0QgZW5kcG9pbnQgYnV0IG5v dCB0aGUgb25lCiAgICAgICAgcmVkaXJlY3RlZCB0bywgb3IgdmljZS12ZXJzYS4KICAgICAgCjwv cD4KPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42 Ij48L2E+PGgzPjYuJm5ic3A7ClJlZmVyZW5jZXM8L2gzPgoKPGEgbmFtZT0icmZjLnJlZmVyZW5j ZXMxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGgzPjYuMS4mbmJzcDtOb3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJs ZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFs aWduPSJ0b3AiPjxhIG5hbWU9IlJGQzIxMTkiPltSRkMyMTE5XTwvYT48L3RkPgo8dGQgY2xhc3M9 ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86c29iQGhhcnZhcmQuZWR1Ij5CcmFkbmVyLCBT LjwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMTE5 Ij5LZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVs czwvYT4sJnJkcXVvOyBCQ1AmbmJzcDsxNCwgUkZDJm5ic3A7MjExOSwgTWFyY2gmbmJzcDsxOTk3 ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTE5LnR4dCI+VFhU PC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3Jm YzIxMTkuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1 YmxpYy9yZmMveG1sL3JmYzIxMTkueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjYxNiI+W1JGQzI2MTZd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpmaWVsZGlu Z0BpY3MudWNpLmVkdSI+RmllbGRpbmcsIFIuPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpnQHczLm9y ZyI+R2V0dHlzLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzptb2d1bEB3cmwuZGVjLmNvbSI+TW9n dWwsIEouPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmZyeXN0eWtAdzMub3JnIj5GcnlzdHlrLCBILjwv YT4sIDxhIGhyZWY9Im1haWx0bzptYXNpbnRlckBwYXJjLnhlcm94LmNvbSI+TWFzaW50ZXIsIEwu PC9hPiwgPGEgaHJlZj0ibWFpbHRvOnBhdWxsZUBtaWNyb3NvZnQuY29tIj5MZWFjaCwgUC48L2E+ LCBhbmQgPGEgaHJlZj0ibWFpbHRvOnRpbWJsQHczLm9yZyI+VC4gQmVybmVycy1MZWU8L2E+LCAm bGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNiI+SHlwZXJ0 ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xPC9hPiwmcmRxdW87IFJGQyZuYnNwOzI2 MTYsIEp1bmUmbmJzcDsxOTk5ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3Jm Yy9yZmMyNjE2LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y Zy9yZmMvcmZjMjYxNi5wcyI+UFM8L2E+LCA8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmMyNjE2LnBkZiI+UERGPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJj ZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzI2MTYuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzI2MTYueG1sIj5YTUw8L2E+ KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEg bmFtZT0iUkZDMzMzOSI+W1JGQzMzMzldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PjxhIGhyZWY9Im1haWx0bzpHS0BBQ00uT1JHIj5LbHluZSwgRy4sIEVkLjwvYT4gYW5kIDxhIGhy ZWY9Im1haWx0bzpjaHJpcy5uZXdtYW5Ac3VuLmNvbSI+Qy4gTmV3bWFuPC9hPiwgJmxkcXVvOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMzMzkiPkRhdGUgYW5kIFRpbWUg b24gdGhlIEludGVybmV0OiBUaW1lc3RhbXBzPC9hPiwmcmRxdW87IFJGQyZuYnNwOzMzMzksIEp1 bHkmbmJzcDsyMDAyICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMz MzM5LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy9odG1sL3JmYzMzMzkuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzMzMzkueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzk4 NiI+W1JGQzM5ODZdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1h aWx0bzp0aW1ibEB3My5vcmciPkJlcm5lcnMtTGVlLCBULjwvYT4sIDxhIGhyZWY9Im1haWx0bzpm aWVsZGluZ0BnYml2LmNvbSI+RmllbGRpbmcsIFIuPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzpM TU1AYWNtLm9yZyI+TC4gTWFzaW50ZXI8L2E+LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjMzk4NiI+VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkp OiBHZW5lcmljIFN5bnRheDwvYT4sJnJkcXVvOyBTVEQmbmJzcDs2NiwgUkZDJm5ic3A7Mzk4Niwg SmFudWFyeSZuYnNwOzIwMDUgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZj L3JmYzM5ODYudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL2h0bWwvcmZjMzk4Ni5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0iaHR0cDovL3ht bC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMzk4Ni54bWwiPlhNTDwvYT4pLjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJS RkM0NjI3Ij5bUkZDNDYyN108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Q3JvY2tm b3JkLCBELiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2 MjciPlRoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2JqZWN0 IE5vdGF0aW9uIChKU09OKTwvYT4sJnJkcXVvOyBSRkMmbmJzcDs0NjI3LCBKdWx5Jm5ic3A7MjAw NiAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDYyNy50eHQiPlRY VDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w Ij48YSBuYW1lPSJSRkM1MjQ2Ij5bUkZDNTI0Nl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+RGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICZsZHF1bzs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2Ij5UaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5 IChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4yPC9hPiwmcmRxdW87IFJGQyZuYnNwOzUyNDYsIEF1 Z3VzdCZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm YzUyNDYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTc4NSI+W1JGQzU3ODVdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPk5vdHRpbmdoYW0sIE0uIGFuZCBFLiBIYW1tZXItTGFoYXYsICZs ZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzg1Ij5EZWZpbmlu ZyBXZWxsLUtub3duIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllcnMgKFVSSXMpPC9hPiwmcmRx dW87IFJGQyZuYnNwOzU3ODUsIEFwcmlsJm5ic3A7MjAxMCAoPGEgaHJlZj0iaHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTc4NS50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQiPltXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkhvcnMsIEEuLCBSYWdnZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxk cXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEy MjQiPkhUTUwgNC4wMSBTcGVjaWZpY2F0aW9uPC9hPiwmcmRxdW87IFdvcmxkIFdpZGUgV2ViIENv bnNvcnRpdW0gUmVjb21tZW5kYXRpb24mbmJzcDtSRUMtaHRtbDQwMS0xOTk5MTIyNCwgRGVjZW1i ZXImbmJzcDsxOTk5ICg8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy1odG1s NDAxLTE5OTkxMjI0Ij5IVE1MPC9hPikuPC90ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFtZT0icmZj LnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjYuMi4mbmJzcDtJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz PC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSldUIj5bSldUXTwvYT48L3RkPgo8dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij5Kb25lcyAoZWRpdG9yKSwgTS4sIEJhbGZhbnosIEQuLCBCcmFkbGV5 LCBKLiwgR29sYW5kLCBZLiwgUGFuemVyLCBKLiwgYW5kIE4uIFNha2ltdXJhLCAmbGRxdW87PGEg aHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1qc29uLXdlYi10 b2tlbi0wMC5odG1sIj5KU09OIFdlYiBUb2tlbiAoSldUKTwvYT4sJnJkcXVvOyBPY3RvYmVyJm5i c3A7MjAxMC48L3RkPjwvdHI+CjwvdGFibGU+Cgo8YSBuYW1lPSJyZmMuYXV0aG9ycyI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxoMz5BdXRob3JzJyBBZGRyZXNzZXM8L2gzPgo8dGFibGUgd2lkdGg9Ijk5JSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRob3It dGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TWljaGFlbCBCLiBKb25l cyAoRWRpdG9yKTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyIGNlbGxw YWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+WWFy b24gWS4gR29sYW5kPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7 PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TWljcm9zb2Z0PC90ZD48L3RyPgo8L3RhYmxl Pgo8L2JvZHk+PC9odG1sPgoK --_004_4E1F6AAD24975D4BA5B16804296739432459E77DTK5EX14MBXC207r_-- From rs@dailymotion.com Tue Oct 26 17:25:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E1F3A6879 for ; Tue, 26 Oct 2010 17:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ojmyGXx3xg for ; Tue, 26 Oct 2010 17:25:22 -0700 (PDT) Received: from intsvc-02.dailymotion.com (intsvc-02.dailymotion.com [195.8.215.88]) by core3.amsl.com (Postfix) with ESMTP id 99A023A682E for ; Tue, 26 Oct 2010 17:25:22 -0700 (PDT) Received: from EXCHANGE-02.daily.local (unknown [195.8.215.118]) by intsvc-02.dailymotion.com (Postfix) with ESMTP id 91AE5A4773 for ; Wed, 27 Oct 2010 02:27:08 +0200 (CEST) Received: from EXCHANGE-02.daily.local ([195.8.215.118]) by exchange-02 ([195.8.215.118]) with mapi; Wed, 27 Oct 2010 02:23:39 +0200 From: Olivier POITREY To: OAuth WG Date: Wed, 27 Oct 2010 02:27:06 +0200 Thread-Topic: Dailymotion API using OAuth 2.0 draft 10 Thread-Index: Act1bTQG8hW8Xq4nTfmMV5EKv98z0g== Message-ID: Accept-Language: en-US, fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Dailymotion API using OAuth 2.0 draft 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:25:24 -0000 Hi, I'm proud to announce that Dailymotion released the first beta of its new A= PI fully based on OAuth 2.0 draft 10. We are sticking 100% to the spec (we = hope) and are supporting all client profiles. It's currently in beta, some = parts are not polished yet (i.e.: authorization page is not skinned) and on= ly a few methods are available but the basics are there and fully functiona= l. The documentation of our API can be found here: http://www.dailymotion.com/doc/api Here is the part specific to OAuth 2.0: http://www.dailymotion.com/doc/api/authentication.html We have client SDKs for PHP and Objective-C already available on GitHub (ht= tp://github.com/dailymotion). We will add Javascript, Python, Actionscript = and Android SDKs soon. We are very interested by feedbacks about our implementation before it goes= final. BTW, our API implements some interesting cache mechanism, but this= is OT :) Best, From dick.hardt@gmail.com Tue Oct 26 21:39:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F433A69A3 for ; Tue, 26 Oct 2010 21:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxk+INFRuFED for ; Tue, 26 Oct 2010 21:38:43 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AA8223A68F7 for ; Tue, 26 Oct 2010 21:38:26 -0700 (PDT) Received: by pxi13 with SMTP id 13so45292pxi.31 for ; Tue, 26 Oct 2010 21:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=42mpLXVMkMl1ecaAdE7icgNUm9FmWKPFZ/cpkmmtRw4=; b=skGUHw7Hyruu59b/MCsGp1q5RgHdxyKaKQzL7ncofwiJ0+Gt2KcazyExqoRHT8HiKB EEmylJdRaJ+my2cFx5jGCYwDvgWs27lIrgUaoLfpIGh3jjjPL1kL/oqap/ZP0pI4yyRA FEUXId3Fcg/KmQx7RndrqVEbAzYcEZL5yqCfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=x7fydV93w0ME/Xro0l4sTx9+zUNqtHD47yK/ZlYJGVNeMae348Lk+CoCgYVNt3xv9y ueGHRSLSvBQNVYvXLoZKtNM+JmYnCzmJ1nsD8TiC5O3y18odjEgJKcBM2nuXTXBa7/+W ggE2uilVK3ExPxZyTyIG6UlSOxXmweAGYKDnI= Received: by 10.143.156.4 with SMTP id i4mr7282965wfo.371.1288154309686; Tue, 26 Oct 2010 21:38:29 -0700 (PDT) Received: from [192.168.1.16] ([24.130.35.170]) by mx.google.com with ESMTPS id v19sm14168565wfh.0.2010.10.26.21.38.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Oct 2010 21:38:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-25-609460336 From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Tue, 26 Oct 2010 21:38:25 -0700 Message-Id: <44E8DE65-84D7-4FD9-BACF-1E2F58E4FD82@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1081) Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:39:59 -0000 X-List-Received-Date: Wed, 27 Oct 2010 04:39:59 -0000 --Apple-Mail-25-609460336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2010-10-26, at 4:33 PM, Mike Jones wrote: > Having a simple discovery method for services and resources is key to = enabling many Internet scenarios that require interactions among parties = that do not have pre-established relationships. For instance, if Joe, = with e-mail address joe@example.com, wants to share his calendar with = Mary, then Mary=92s calendar service, in the general case, will need to = discover the location of Joe=92s calendar service. For example, Mary=92s = calendar service might discover that Joe=92s calendar service is located = at http://calendars.proseware.com/calendar/joseph by doing discovery for = a service named urn:adatum.com:calendar at example.com for the account = joe. I think it would be really useful to complete the scenario. What happens = when Mary's service discovers Joe's calendar service? How does Joe give = Mary's calendar service permission to access his calendar? How does Joe = identify Mary? -- Dick= --Apple-Mail-25-609460336 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2010-10-26, at 4:33 PM, Mike Jones = wrote:

 joe@example.com, wants to share his calendar with Mary, = then Mary=92s calendar service, in the general case, will need to = discover the location of Joe=92s calendar service.  For example, = Mary=92s calendar service might discover that Joe=92s calendar service = is located at  by doing discovery for a = service named urn:adatum.com:calendar  at example.com for the account = joe.

I think it = would be really useful to complete the scenario. What happens when = Mary's service discovers Joe's calendar service? How does Joe give = Mary's calendar service permission to access his calendar? How does Joe = identify Mary?

-- Dick
= --Apple-Mail-25-609460336-- From skylar@kiva.org Wed Oct 27 00:58:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D6D3A677E for ; Wed, 27 Oct 2010 00:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qJMsLMP4n-v for ; Wed, 27 Oct 2010 00:58:51 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id E86D03A6887 for ; Wed, 27 Oct 2010 00:58:50 -0700 (PDT) Received: by wwi18 with SMTP id 18so1216643wwi.1 for ; Wed, 27 Oct 2010 01:00:39 -0700 (PDT) Received: by 10.216.157.132 with SMTP id o4mr459112wek.7.1288166439230; Wed, 27 Oct 2010 01:00:39 -0700 (PDT) Received: from [10.0.1.3] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id p4sm5684785wej.28.2010.10.27.01.00.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 01:00:38 -0700 (PDT) From: Skylar Woodward Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 10:00:35 +0200 Message-Id: <525AA51F-7DD3-4789-8DE1-63B0A8B2CBA4@kiva.org> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Kiva OAuth design decisions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 07:58:52 -0000 Kiva is in the process of implementing OAuth for our API. The current = 2.0 draft lacks signatures which we determined as a necessary layer of = protection for some of our transactions. However, 1.0 is unnecessarily = complex and offers a misleading sense of security for apps that can't = keep secrets. We've decided on a hybrid approach for now that uses 2.0 = mechanics but 1.0 signatures (leveraging existing libraries and = know-how). We've posted our plans here: http://developers.wiki.kiva.org/OAuth-1_5k Hopefully another real-world provider implementation can help put some = decisions in context as work continues to finalize the spec. Recently, there have been discussions of both formal and informal = meetings on this list. This Saturday, October 30, at La Cantine in = Paris, we're expecting to have a lively session on OAuth, the evolving = 2.0 spec, and where it's headed. Anyone who is in the area or otherwise = able to make it is welcome to join - no one who shows up will be refused = (regardless of what the registration pages say): http://barcamp.org/WebWorkersCamp10 Cheers, skylar From hannes.tschofenig@nsn.com Wed Oct 27 04:32:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459DD3A67CF for ; Wed, 27 Oct 2010 04:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98l1aECzWasD for ; Wed, 27 Oct 2010 04:32:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C601E3A6778 for ; Wed, 27 Oct 2010 04:32:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBYPQF004679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 13:34:25 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBYMQK025577; Wed, 27 Oct 2010 13:34:25 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:34:20 +0200 Received: from 10.144.234.211 ([10.144.234.211]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Oct 2010 11:34:19 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 27 Oct 2010 14:34:12 +0300 From: Hannes Tschofenig To: Blaine Cook , Message-ID: Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: Act1yuB4nnV+n4cFSUyDuOuRzYtZnw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 11:34:20.0940 (UTC) FILETIME=[E5CC34C0:01CB75CA] Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:32:39 -0000 Hi all, based on the feedback from the group on the list we go forward with the document split. Mike had kindly offered to edit the bearer specification and we are happy to hear that. Thank you Mike. I am looking forward to see the first document. Ciao Hannes On 10/14/10 3:32 AM, "Blaine Cook" wrote: > Over the past few weeks, the working group debated the issues around > the introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current > specification into two parts: one including section 5 (bearer token) > and the other including the rest (how to obtain a token), with an > additional specification covering signature use cases. > > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if > anyone has any concerns or objections against this proposal. > > In addition, the chairs are seeking a volunteer to take over the > bearer token specification (section 5) as editor. > > Please submit your comments by Wednesday, October 20th. > > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Wed Oct 27 04:38:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38F23A693B for ; Wed, 27 Oct 2010 04:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utJ-yMNfheZq for ; Wed, 27 Oct 2010 04:38:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 395793A6905 for ; Wed, 27 Oct 2010 04:38:43 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBeUGF022130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Oct 2010 13:40:30 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBeTQm022155 for ; Wed, 27 Oct 2010 13:40:29 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:40:29 +0200 Received: from 10.144.234.211 ([10.144.234.211]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Oct 2010 11:40:28 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 27 Oct 2010 14:40:22 +0300 From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: Thread-Topic: OAuth Tutorial, Monday, November 8, 0900-1130 Thread-Index: Act1y70BOI6fnqlXIkuaA7w/pEFo9w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 11:40:29.0844 (UTC) FILETIME=[C1AE7D40:01CB75CB] Subject: [OAUTH-WG] OAuth Tutorial, Monday, November 8, 0900-1130 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:38:45 -0000 Hi all, Based on the positive response at the last IETF meeting we decided to hold another Oauth tutorial, namely on Monday, November 8,0900-1130 If you plan to participate drop me a note. I will post information about the meeting room to the Oauth mailing list in time before the meeting. Ciao Hannes From hannes.tschofenig@nsn.com Wed Oct 27 04:38:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C6A3A69AA for ; Wed, 27 Oct 2010 04:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqJYeDmd5UmJ for ; Wed, 27 Oct 2010 04:38:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A833D3A69B7 for ; Wed, 27 Oct 2010 04:38:49 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBeceW022510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Oct 2010 13:40:38 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9RBeXAG022351 for ; Wed, 27 Oct 2010 13:40:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:40:34 +0200 Received: from 10.144.234.211 ([10.144.234.211]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Oct 2010 11:40:32 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 27 Oct 2010 14:40:29 +0300 From: Hannes Tschofenig To: Message-ID: Thread-Topic: OAuth Security Session, Monday, November 8, 1300-1500 Thread-Index: Act1y8Et/Cb1HxQiukS1NX4yWyZ0KQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 11:40:34.0229 (UTC) FILETIME=[C44B9650:01CB75CB] Subject: [OAUTH-WG] OAuth Security Session, Monday, November 8, 1300-1500 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:38:53 -0000 Hi all, We will start our conversations about Oauth security on Monday, November 8, 1300-1500. As a starting point I suggest to look at: http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt I will post information about the meeting room to the Oauth mailing list in time before the meeting. Ciao Hannes From alexey.melnikov@isode.com Wed Oct 27 05:12:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0353A68A0 for ; Wed, 27 Oct 2010 05:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9fF+5zH+rKR for ; Wed, 27 Oct 2010 05:12:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4190C3A6918 for ; Wed, 27 Oct 2010 05:12:11 -0700 (PDT) Received: from [172.16.2.175] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 27 Oct 2010 13:13:59 +0100 Message-ID: <4CC81779.8070204@isode.com> Date: Wed, 27 Oct 2010 13:13:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Hannes Tschofenig References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Tutorial, Monday, November 8, 0900-1130 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:12:13 -0000 Hannes Tschofenig wrote: >Hi all, > >Based on the positive response at the last IETF meeting we decided to hold >another Oauth tutorial, namely on Monday, November 8,0900-1130 > > I am sorry Hannes, but having this tutorial during the Apps Area open meeting is not cool. So "-1" from one of your Apps ADs. >If you plan to participate drop me a note. > >I will post information about the meeting room to the Oauth mailing list in >time before the meeting. > > From hannes.tschofenig@nsn.com Wed Oct 27 05:44:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4C43A69F4 for ; Wed, 27 Oct 2010 05:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxCc52YNckOg for ; Wed, 27 Oct 2010 05:44:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1C0E43A6908 for ; Wed, 27 Oct 2010 05:44:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9RCjtZ0026041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 14:45:55 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9RCjrog020235; Wed, 27 Oct 2010 14:45:55 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 14:45:42 +0200 Received: from 10.144.234.211 ([10.144.234.211]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Oct 2010 12:45:41 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 27 Oct 2010 15:45:37 +0300 From: Hannes Tschofenig To: Alexey Melnikov Message-ID: Thread-Topic: [OAUTH-WG] OAuth Tutorial, Monday, November 8, 0900-1130 Thread-Index: Act11NqHjTbMKjflW0e0fjy3wpqHBQ== In-Reply-To: <4CC81779.8070204@isode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 12:45:42.0448 (UTC) FILETIME=[DDC67B00:01CB75D4] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Tutorial, Monday, November 8, 0900-1130 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:44:08 -0000 The APPs area people are already aware of Oauth; they are welcome in the afternoon for the security discussion. There will always be a conflict and I wanted to have it at the beginning of the week to leave room left for further sessions during the week, if necessary. On 10/27/10 3:13 PM, "Alexey Melnikov" wrote: > Hannes Tschofenig wrote: > >> Hi all, >> >> Based on the positive response at the last IETF meeting we decided to hold >> another Oauth tutorial, namely on Monday, November 8,0900-1130 >> >> > I am sorry Hannes, but having this tutorial during the Apps Area open > meeting is not cool. > So "-1" from one of your Apps ADs. > >> If you plan to participate drop me a note. >> >> I will post information about the meeting room to the Oauth mailing list in >> time before the meeting. >> >> > From hannes.tschofenig@nsn.com Wed Oct 27 06:42:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDA43A67B2 for ; Wed, 27 Oct 2010 06:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43iufpLZvI5M for ; Wed, 27 Oct 2010 06:42:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5EF8F3A6802 for ; Wed, 27 Oct 2010 06:42:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9RDhg6d023203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Oct 2010 15:43:42 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9RDhgQm024943 for ; Wed, 27 Oct 2010 15:43:42 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 15:43:42 +0200 Received: from 10.144.234.211 ([10.144.234.211]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Oct 2010 13:43:41 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Wed, 27 Oct 2010 16:43:37 +0300 From: Hannes Tschofenig To: Hannes Tschofenig , "oauth@ietf.org" Message-ID: Thread-Topic: OAuth Tutorial, Monday, November 8, after 19:30 (IAB Technical Plenary) [PROPOSAL] Thread-Index: Act1y70BOI6fnqlXIkuaA7w/pEFo9wAETfFy In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 13:43:42.0280 (UTC) FILETIME=[F7EAB480:01CB75DC] Subject: [OAUTH-WG] OAuth Tutorial, Monday, November 8, after 19:30 (IAB Technical Plenary) [PROPOSAL] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:42:04 -0000 So, after a tough fight with Alexey (which I lost) here is another proposal for the tutorial. There is the IAB technical plenary talk from 16:30 to 19:30. We would meet after the tutorial for the tutorial. Drop me a note if this alternative proposal does not work for you. Ciao Hannes On 10/27/10 2:40 PM, "Hannes Tschofenig" wrote: > Hi all, > > Based on the positive response at the last IETF meeting we decided to hold > another Oauth tutorial, namely on Monday, November 8,0900-1130 > > If you plan to participate drop me a note. > > I will post information about the meeting room to the Oauth mailing list in > time before the meeting. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Wed Oct 27 09:11:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934CB3A6979 for ; Wed, 27 Oct 2010 09:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.862 X-Spam-Level: X-Spam-Status: No, score=-100.862 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7BtaHy3w5z6 for ; Wed, 27 Oct 2010 09:11:39 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id AE05B3A6955 for ; Wed, 27 Oct 2010 09:11:38 -0700 (PDT) Received: (qmail invoked by alias); 27 Oct 2010 16:13:24 -0000 Received: from unknown (EHLO [10.254.0.90]) [192.100.123.77] by mail.gmx.net (mp001) with SMTP; 27 Oct 2010 18:13:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1801m5m0+Y07uuwL4dsQSjXLPZmVb2Gca6X8JGF44 Uc8BVg0JXd6YFK Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 27 Oct 2010 19:13:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Tutorial, Monday, November 8, after 19:30 (IAB Technical Plenary) [PROPOSAL] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:11:43 -0000 Richard Barnes just pointed me to another conflict that we want to = avoid, namely the folks from the Real-Time Communication in the Browser = workshop are going to go out for dinner Monday evening, see = http://www.alvestrand.no/pipermail/rtc-web/2010-October/000085.html.=20 Just in case you are not aware of this workshop please take a look at = the workshop slides and meeting notes available at = http://rtc-web.alvestrand.com/ So, I will have to come up with another proposal... Ciao Hannes On Oct 27, 2010, at 4:43 PM, Hannes Tschofenig wrote: > So, after a tough fight with Alexey (which I lost) here is another = proposal > for the tutorial. There is the IAB technical plenary talk from 16:30 = to > 19:30. We would meet after the tutorial for the tutorial. >=20 > Drop me a note if this alternative proposal does not work for you. >=20 > Ciao > Hannes >=20 > On 10/27/10 2:40 PM, "Hannes Tschofenig" = wrote: >=20 >> Hi all,=20 >>=20 >> Based on the positive response at the last IETF meeting we decided to = hold >> another Oauth tutorial, namely on Monday, November 8,0900-1130 >>=20 >> If you plan to participate drop me a note. >>=20 >> I will post information about the meeting room to the Oauth mailing = list in >> time before the meeting. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Wed Oct 27 09:55:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A573A69FB for ; Wed, 27 Oct 2010 09:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.387 X-Spam-Level: X-Spam-Status: No, score=-10.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1Ub7RESg6CA for ; Wed, 27 Oct 2010 09:55:02 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5F7CA3A693B for ; Wed, 27 Oct 2010 09:55:02 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Oct 2010 09:56:52 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.105]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Wed, 27 Oct 2010 09:56:52 -0700 From: Mike Jones To: Hannes Tschofenig , Blaine Cook , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGA= Date: Wed, 27 Oct 2010 16:56:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Call for Consensus on Document Split X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:55:06 -0000 Thanks for your confidence in me. I look forward to completing a specifica= tion that meets the industry needs. I plan to sync with Eran this week. I also plan to hold a "listening tour"= at IIW to understand stakeholders' perspectives on where we stand with OAu= th 2.0 today and what remains to do finish it. Please come talk to me at I= IW if you're there and you're building or deploying OAuth 2.0 and want me t= o understand your views. E-mail and phone calls are also welcome. Once I've synced with Eran and gathered input from stakeholders, I'll plan = on announcing target dates for drafts. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, October 27, 2010 4:34 AM To: Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Hi all,=20 based on the feedback from the group on the list we go forward with the doc= ument split.=20 Mike had kindly offered to edit the bearer specification and we are happy t= o hear that. Thank you Mike. I am looking forward to see the first document= . Ciao Hannes On 10/14/10 3:32 AM, "Blaine Cook" wrote: > Over the past few weeks, the working group debated the issues around=20 > the introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current=20 > specification into two parts: one including section 5 (bearer token)=20 > and the other including the rest (how to obtain a token), with an=20 > additional specification covering signature use cases. >=20 > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if=20 > anyone has any concerns or objections against this proposal. >=20 > In addition, the chairs are seeking a volunteer to take over the=20 > bearer token specification (section 5) as editor. >=20 > Please submit your comments by Wednesday, October 20th. >=20 > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Wed Oct 27 10:56:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FCE3A695E for ; Wed, 27 Oct 2010 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP+oLy2RKbN0 for ; Wed, 27 Oct 2010 10:56:48 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6C51B3A6803 for ; Wed, 27 Oct 2010 10:56:48 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Oct 2010 10:58:38 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.105]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Wed, 27 Oct 2010 10:58:38 -0700 From: Mike Jones To: Dick Hardt Thread-Topic: Simple Web Discovery Thread-Index: Act1ZjJjDCe6rYI9TGy/HfaZ555XawAZUTiAAA0ktKA= Date: Wed, 27 Oct 2010 17:58:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943245A3004@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> <44E8DE65-84D7-4FD9-BACF-1E2F58E4FD82@gmail.com> In-Reply-To: <44E8DE65-84D7-4FD9-BACF-1E2F58E4FD82@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943245A3004TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:56:53 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943245A3004TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These posts of Yaron's outline the basic vision and flows: http://www.goland.org/adhocauthentication/ http://www.goland.org/oauthgenericdelegation/ We hope to also come out with a description in Internet-draft style soon to= provide concrete details about possible implementation choices for this ki= nd of end-to-end scenario. But if you dig into these posts, I believe you'= ll find there's a lot there already at the conceptual level. -- Mike From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, October 26, 2010 9:38 PM To: Mike Jones Cc: oauth@ietf.org; openid-specs-ab@lists.openid.net Subject: Re: Simple Web Discovery On 2010-10-26, at 4:33 PM, Mike Jones wrote: Having a simple discovery method for services and resources is key to enabl= ing many Internet scenarios that require interactions among parties that do= not have pre-established relationships. For instance, if Joe, with e-mail= address joe@example.com, wants to share his calend= ar with Mary, then Mary's calendar service, in the general case, will need = to discover the location of Joe's calendar service. For example, Mary's ca= lendar service might discover that Joe's calendar service is located at htt= p://calendars.proseware.com/calendar/joseph by doing discovery for a servic= e named urn:adatum.com:calendar at example.com for the= account joe. I think it would be really useful to complete the scenario. What happens wh= en Mary's service discovers Joe's calendar service? How does Joe give Mary'= s calendar service permission to access his calendar? How does Joe identify= Mary? -- Dick --_000_4E1F6AAD24975D4BA5B1680429673943245A3004TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These posts of Yaron̵= 7;s outline the basic vision and flows:

    &= nbsp;           http://www.goland.or= g/adhocauthentication/

    &= nbsp;           http://www.goland= .org/oauthgenericdelegation/

 <= /p>

We hope to also come out = with a description in Internet-draft style soon to provide concrete details= about possible implementation choices for this kind of end-to-end scenario.  But if you dig into these posts, I believe you&= #8217;ll find there’s a lot there already at the conceptual level.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, October 26, 2010 9:38 PM
To: Mike Jones
Cc: oauth@ietf.org; openid-specs-ab@lists.openid.net
Subject: Re: Simple Web Discovery

 

 

On 2010-10-26, at 4:33 PM, Mike Jones wrote:



Having a = simple discovery method for services and resources is key to enabling many = Internet scenarios that require interactions among parties that do not have pre-established relationships.  For instance, if Joe= , with e-mail address joe@example.com, wants to share his cal= endar with Mary, then Mary’s calendar service, in the general case, will need to discover the location of Joe’s cal= endar service.  For example, Mary’s calendar service might disco= ver that Joe’s calendar service is located at http://calendars.proseware.com/calendar/joseph by doing discovery for a service named urn:adatum.com:calendar  at example.com for the = account joe.

 

I think it would be really useful to complete the sc= enario. What happens when Mary's service discovers Joe's calendar service? = How does Joe give Mary's calendar service permission to access his calendar= ? How does Joe identify Mary?

 

-- Dick

--_000_4E1F6AAD24975D4BA5B1680429673943245A3004TK5EX14MBXC207r_-- From tim.freeman@hp.com Wed Oct 27 11:09:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004533A6991 for ; Wed, 27 Oct 2010 11:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5ouI9oqJHg7 for ; Wed, 27 Oct 2010 11:09:15 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id A7B043A6803 for ; Wed, 27 Oct 2010 11:09:15 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id B1F19147FC for ; Wed, 27 Oct 2010 18:11:05 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Oct 2010 18:09:26 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Wed, 27 Oct 2010 18:09:25 +0000 From: "Freeman, Tim" To: "oauth@ietf.org" Date: Wed, 27 Oct 2010 18:09:23 +0000 Thread-Topic: So back to use cases? (was RE: [OAUTH-WG] Call for Consensus on Document Split) Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoA== Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> References: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:09:17 -0000 On the face of it, it seems that discussion of whether and how to split the= document has derailed collection of use cases. If we had consensus on a l= ist of use cases, that would mean we have identified the problems we're try= ing to solve. This would still allow slimy political manipulation of the p= rocess by manipulating the use case list, but that would be progress. It's= better to have a protocol that solves a politically-defined set of problem= s than to have a politically-defined protocol that solves no identified pro= blem. It's also possible that such collection is going on via private email and I= am not aware of it. The questions currently interesting to me about use cases are: * The only use cases that made sense to me about signatures used them for a= uditability, where they enabled blame to be properly placed after informati= on leaked to the wrong people. People were proposing use cases that claime= d that signatures improved privacy, that is, the ability to keep the inform= ation out of the hands of the wrong people. So far as I know all use cases= where signatures improved privacy seemed to fall apart after a few minutes= inspection. Do we agree that signatures improve auditability but not priv= acy, or does someone still believe in a use case where signatures improve p= rivacy? * Use cases that justify a feature seem to require two parts -- an example = where the feature is absent and therefore a particular problem cannot be so= lved, and an example where the feature is present and the same problem can = then be solved. Last I checked the existing use case list seemed to only h= ave the second type where problems were successfully solved and it was uncl= ear to me that the proposed features were really required in order to do th= at. Do we agree that justifying a feature requires both a use case where a= bsence of the feature makes a problem unsolvable and presence of the featur= e makes the same problem solvable? (Alternatives are to believe that there= is some other way to justify having a feature, or to believe we should hav= e features that do not have a clearly described technical justification. M= aybe the features are required by law, are esthetically pleasing, make use = of the right patents and not the wrong ones, look impressive on one's resum= e, etc.) * The simplest signature schemes seem have the consequence of preventing se= rver A from delegating work to server B, since the work must be done by mak= ing requests signed by server A. Do we want to support use cases where one= server delegates work to another server? Do we want to do by allowing A's= right to do certain things to be traded in for something that gives B the = right to do some of those things, by bearer tokens, by some other means, or= not at all? Tim Freeman Email: tim.freeman@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, October 27, 2010 9:57 AM To: Hannes Tschofenig; Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Thanks for your confidence in me. I look forward to completing a specifica= tion that meets the industry needs. I plan to sync with Eran this week. I also plan to hold a "listening tour"= at IIW to understand stakeholders' perspectives on where we stand with OAu= th 2.0 today and what remains to do finish it. Please come talk to me at I= IW if you're there and you're building or deploying OAuth 2.0 and want me t= o understand your views. E-mail and phone calls are also welcome. Once I've synced with Eran and gathered input from stakeholders, I'll plan = on announcing target dates for drafts. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, October 27, 2010 4:34 AM To: Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Hi all,=20 based on the feedback from the group on the list we go forward with the doc= ument split.=20 Mike had kindly offered to edit the bearer specification and we are happy t= o hear that. Thank you Mike. I am looking forward to see the first document= . Ciao Hannes On 10/14/10 3:32 AM, "Blaine Cook" wrote: > Over the past few weeks, the working group debated the issues around=20 > the introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current=20 > specification into two parts: one including section 5 (bearer token)=20 > and the other including the rest (how to obtain a token), with an=20 > additional specification covering signature use cases. >=20 > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if=20 > anyone has any concerns or objections against this proposal. >=20 > In addition, the chairs are seeking a volunteer to take over the=20 > bearer token specification (section 5) as editor. >=20 > Please submit your comments by Wednesday, October 20th. >=20 > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Oct 27 11:39:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF223A6876 for ; Wed, 27 Oct 2010 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuP6zKN5nY96 for ; Wed, 27 Oct 2010 11:39:16 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id D45EA3A6844 for ; Wed, 27 Oct 2010 11:39:16 -0700 (PDT) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id o9RIejW3093420; Wed, 27 Oct 2010 11:40:45 -0700 (PDT) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Wed, 27 Oct 2010 11:40:44 -0700 From: William Mills To: "Freeman, Tim" , "oauth@ietf.org" Date: Wed, 27 Oct 2010 11:40:42 -0700 Thread-Topic: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoIAAG3AQ Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:39:18 -0000 Another use case for signatures is gross management of relationships, contr= olling the secrets in use for (I'll misuse the term) peers allows a single = point of control for that relationship. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Freeman, Tim > Sent: Wednesday, October 27, 2010 11:09 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus > on Document Split) >=20 > On the face of it, it seems that discussion of whether and how to split > the document has derailed collection of use cases. If we had consensus > on a list of use cases, that would mean we have identified the problems > we're trying to solve. This would still allow slimy political > manipulation of the process by manipulating the use case list, but that > would be progress. It's better to have a protocol that solves a > politically-defined set of problems than to have a politically-defined > protocol that solves no identified problem. >=20 > It's also possible that such collection is going on via private email > and I am not aware of it. >=20 > The questions currently interesting to me about use cases are: >=20 > * The only use cases that made sense to me about signatures used them > for auditability, where they enabled blame to be properly placed after > information leaked to the wrong people. People were proposing use > cases that claimed that signatures improved privacy, that is, the > ability to keep the information out of the hands of the wrong people. > So far as I know all use cases where signatures improved privacy seemed > to fall apart after a few minutes inspection. Do we agree that > signatures improve auditability but not privacy, or does someone still > believe in a use case where signatures improve privacy? >=20 > * Use cases that justify a feature seem to require two parts -- an > example where the feature is absent and therefore a particular problem > cannot be solved, and an example where the feature is present and the > same problem can then be solved. Last I checked the existing use case > list seemed to only have the second type where problems were > successfully solved and it was unclear to me that the proposed features > were really required in order to do that. Do we agree that justifying > a feature requires both a use case where absence of the feature makes a > problem unsolvable and presence of the feature makes the same problem > solvable? (Alternatives are to believe that there is some other way to > justify having a feature, or to believe we should have features that do > not have a clearly described technical justification. Maybe the > features are required by law, are esthetically pleasing, make use of > the right patents and not the wrong ones, look impressive on one's > resume, etc.) >=20 > * The simplest signature schemes seem have the consequence of > preventing server A from delegating work to server B, since the work > must be done by making requests signed by server A. Do we want to > support use cases where one server delegates work to another server? > Do we want to do by allowing A's right to do certain things to be > traded in for something that gives B the right to do some of those > things, by bearer tokens, by some other means, or not at all? >=20 > Tim Freeman > Email: tim.freeman@hp.com > Desk in Palo Alto: (650) 857-2581 > Home: (408) 774-1298 > Cell: (408) 348-7536 >=20 >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Wednesday, October 27, 2010 9:57 AM > To: Hannes Tschofenig; Blaine Cook; oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >=20 > Thanks for your confidence in me. I look forward to completing a > specification that meets the industry needs. >=20 > I plan to sync with Eran this week. I also plan to hold a "listening > tour" at IIW to understand stakeholders' perspectives on where we stand > with OAuth 2.0 today and what remains to do finish it. Please come > talk to me at IIW if you're there and you're building or deploying > OAuth 2.0 and want me to understand your views. E-mail and phone calls > are also welcome. >=20 > Once I've synced with Eran and gathered input from stakeholders, I'll > plan on announcing target dates for drafts. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, October 27, 2010 4:34 AM > To: Blaine Cook; oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >=20 > Hi all, >=20 > based on the feedback from the group on the list we go forward with the > document split. >=20 > Mike had kindly offered to edit the bearer specification and we are > happy to hear that. Thank you Mike. I am looking forward to see the > first document. >=20 > Ciao > Hannes >=20 > On 10/14/10 3:32 AM, "Blaine Cook" wrote: >=20 > > Over the past few weeks, the working group debated the issues around > > the introduction of signatures and the structure of the > specification. > > The working group seems to endorse the proposal to split the current > > specification into two parts: one including section 5 (bearer token) > > and the other including the rest (how to obtain a token), with an > > additional specification covering signature use cases. > > > > This serves as a call for consensus on the proposed editorial work. > > Before we proceed with the changes, the chairs would like to ask if > > anyone has any concerns or objections against this proposal. > > > > In addition, the chairs are seeking a volunteer to take over the > > bearer token specification (section 5) as editor. > > > > Please submit your comments by Wednesday, October 20th. > > > > - The OAuth Working Group Chairs > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Wed Oct 27 12:25:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0273A6877 for ; Wed, 27 Oct 2010 12:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+BkpKlCiQdP for ; Wed, 27 Oct 2010 12:25:50 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 0C1633A6828 for ; Wed, 27 Oct 2010 12:25:49 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o9RJRcNt009303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Oct 2010 14:27:38 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9RJRca2027766 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Oct 2010 14:27:38 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 27 Oct 2010 14:27:38 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Freeman, Tim'" , "oauth@ietf.org" Date: Wed, 27 Oct 2010 14:27:38 -0500 Thread-Topic: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoIAAGjZw Message-ID: <5710F82C0E73B04FA559560098BF95B124FC20CE0D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:25:52 -0000 >* Use cases that justify a feature seem to require two parts -- an example= >where the feature is absent and therefore a particular problem cannot be = >solved, and an example where the feature is present and the same problem >= can then be solved. There are use cases that can be supported by more than one solution. For ex= ample, the use case specified in the original OAuth specifications (authori= zing a client to print private photos) relies on the signature-based soluti= ons. The same use case in OAuth 2.0 -v10 (Web Server) is supported by a sol= ution that does not use signatures, but requires to use TLS. So, the same problem is solved in two different ways and each solution just= ifies different features. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of F= reeman, Tim Sent: Wednesday, October 27, 2010 2:09 PM To: oauth@ietf.org Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Do= cument Split) On the face of it, it seems that discussion of whether and how to split the= document has derailed collection of use cases. If we had consensus on a l= ist of use cases, that would mean we have identified the problems we're try= ing to solve. This would still allow slimy political manipulation of the p= rocess by manipulating the use case list, but that would be progress. It's= better to have a protocol that solves a politically-defined set of problem= s than to have a politically-defined protocol that solves no identified pro= blem. It's also possible that such collection is going on via private email and I= am not aware of it. The questions currently interesting to me about use cases are: * The only use cases that made sense to me about signatures used them for a= uditability, where they enabled blame to be properly placed after informati= on leaked to the wrong people. People were proposing use cases that claime= d that signatures improved privacy, that is, the ability to keep the inform= ation out of the hands of the wrong people. So far as I know all use cases= where signatures improved privacy seemed to fall apart after a few minutes= inspection. Do we agree that signatures improve auditability but not priv= acy, or does someone still believe in a use case where signatures improve p= rivacy? * Use cases that justify a feature seem to require two parts -- an example = where the feature is absent and therefore a particular problem cannot be so= lved, and an example where the feature is present and the same problem can = then be solved. Last I checked the existing use case list seemed to only h= ave the second type where problems were successfully solved and it was uncl= ear to me that the proposed features were really required in order to do th= at. Do we agree that justifying a feature requires both a use case where a= bsence of the feature makes a problem unsolvable and presence of the featur= e makes the same problem solvable? (Alternatives are to believe that there= is some other way to justify having a feature, or to believe we should hav= e features that do not have a clearly described technical justification. M= aybe the features are required by law, are esthetically pleasing, make use = of the right patents and not the wrong ones, look impressive on one's resum= e, etc.) * The simplest signature schemes seem have the consequence of preventing se= rver A from delegating work to server B, since the work must be done by mak= ing requests signed by server A. Do we want to support use cases where one= server delegates work to another server? Do we want to do by allowing A's= right to do certain things to be traded in for something that gives B the = right to do some of those things, by bearer tokens, by some other means, or= not at all? Tim Freeman Email: tim.freeman@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, October 27, 2010 9:57 AM To: Hannes Tschofenig; Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Thanks for your confidence in me. I look forward to completing a specifica= tion that meets the industry needs. I plan to sync with Eran this week. I also plan to hold a "listening tour"= at IIW to understand stakeholders' perspectives on where we stand with OAu= th 2.0 today and what remains to do finish it. Please come talk to me at I= IW if you're there and you're building or deploying OAuth 2.0 and want me t= o understand your views. E-mail and phone calls are also welcome. Once I've synced with Eran and gathered input from stakeholders, I'll plan = on announcing target dates for drafts. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, October 27, 2010 4:34 AM To: Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Hi all,=20 based on the feedback from the group on the list we go forward with the doc= ument split.=20 Mike had kindly offered to edit the bearer specification and we are happy t= o hear that. Thank you Mike. I am looking forward to see the first document= . Ciao Hannes On 10/14/10 3:32 AM, "Blaine Cook" wrote: > Over the past few weeks, the working group debated the issues around=20 > the introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current=20 > specification into two parts: one including section 5 (bearer token)=20 > and the other including the rest (how to obtain a token), with an=20 > additional specification covering signature use cases. >=20 > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if=20 > anyone has any concerns or objections against this proposal. >=20 > In addition, the chairs are seeking a volunteer to take over the=20 > bearer token specification (section 5) as editor. >=20 > Please submit your comments by Wednesday, October 20th. >=20 > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Oct 27 12:55:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CB63A680A for ; Wed, 27 Oct 2010 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.782 X-Spam-Level: X-Spam-Status: No, score=-105.782 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axM8x4H4Yyf4 for ; Wed, 27 Oct 2010 12:55:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4AE7E3A69A1 for ; Wed, 27 Oct 2010 12:55:55 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o9RJviwc012518 for ; Wed, 27 Oct 2010 12:57:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288209465; bh=Ly8KLRWDU6WT95eiZxaaCKJNXfY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LQuqKWpsfNIZkHEzZh8tEmNB6K4JAhuoIi/4yNZPAxHVklvSR7nALGX/Fxjmb2TaF +Bt+NxhcO7CC879SgEtKg== Received: from yxm34 (yxm34.prod.google.com [10.190.4.34]) by hpaq6.eem.corp.google.com with ESMTP id o9RJvOB9000467 for ; Wed, 27 Oct 2010 12:57:43 -0700 Received: by yxm34 with SMTP id 34so794141yxm.14 for ; Wed, 27 Oct 2010 12:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=ZYdE80k19LTZKqjTvg/F6mLQg7u+Oq3gXZfaQajBl1A=; b=olAKOH2CTk7/UdRlmEXCGd/tFJ//bw2QzzOUUzjGLn3nvTMxUpCrXzhJlWuyyHwb9d GmXptuqWhnde2Lv4mhdA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QT/ugXC5ltkKR/ad4FWOCeIZBIgkaH5XPkCXez9x1QSf1ZQTKr9h69s9vR3ZTn43YU fLmYjxJHAAoB1k1AB+Uw== Received: by 10.100.206.20 with SMTP id d20mr1435134ang.34.1288209462227; Wed, 27 Oct 2010 12:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.240.19 with HTTP; Wed, 27 Oct 2010 12:57:22 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112705633B6@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112705633B6@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Wed, 27 Oct 2010 12:57:22 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] GOOG1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:55:56 -0000 Hi James, Finally got around to get an answer for your question: "GOOG1 is an authentication scheme specific to Google Storage for Developers, and is designed to provide interoperability with a large number of cloud storage tools and libraries that work with services such as Amazon Simple Storage Service (Amazon S3) and Eucalyptus Systems, Inc. We do not foresee this authentication scheme forming the basis of an OAuth signature scheme." Hope that helps. Cheers, Marius On Thu, Oct 14, 2010 at 4:29 PM, Manger, James H wrote: > I noticed that a new HTTP authentication scheme has been defined: GOOG1. > > http://code.google.com/apis/storage/docs/developer-guide.html#authentication > > > > Is this a candidate for the signature spec? > > It should be the sort of scheme that OAuth core can provide credentials for > (access key & secret) without the scheme needing to know about OAuth. > > > > [It is an HMAC-SHA1; carried in the Authorization header; calculated over > the method (eg GET), date, content-type, URI path (but not host or scheme), > MD5-hash of request body (optional), and some proprietary headers (eg > access-control details). It looks very similar to the Amazon S3 scheme.] > > > > > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From skylar@kiva.org Wed Oct 27 14:46:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1637E3A6768 for ; Wed, 27 Oct 2010 14:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0iAKgqY0z66 for ; Wed, 27 Oct 2010 14:46:21 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 011EC3A67E4 for ; Wed, 27 Oct 2010 14:46:20 -0700 (PDT) Received: by gwb15 with SMTP id 15so889625gwb.31 for ; Wed, 27 Oct 2010 14:48:11 -0700 (PDT) Received: by 10.100.124.20 with SMTP id w20mr8409346anc.108.1288215723069; Wed, 27 Oct 2010 14:42:03 -0700 (PDT) Received: from [10.0.1.3] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id 25sm224975anq.28.2010.10.27.14.42.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 14:42:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Skylar Woodward In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> Date: Wed, 27 Oct 2010 23:41:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> To: "Freeman, Tim" , OAuth WG X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:46:22 -0000 On Oct 27, 2010, at 8:09 PM, Freeman, Tim wrote: > The questions currently interesting to me about use cases are: >=20 > * The only use cases that made sense to me about signatures used them = for auditability, where they enabled blame to be properly placed after = information leaked to the wrong people. People were proposing use cases = that claimed that signatures improved privacy, that is, the ability to = keep the information out of the hands of the wrong people. So far as I = know all use cases where signatures improved privacy seemed to fall = apart after a few minutes inspection. Do we agree that signatures = improve auditability but not privacy, or does someone still believe in a = use case where signatures improve privacy? For Kiva, our use case would be something along the lines of "secondary = protection mechanism." To access certain types of data we want client = authentication (ie, identification) to request and use tokens. The = specification w/o signatures depends only on SSL to protect secrets, = passwords, and tokens and thus client identity. By requesting signed = requests we have a second mechanism on top of SSL to protect secrets in = the event that request is leaked to an improper endpoint - as secrets = are never sent over the wire. To reuse some of Zachary's language, we're = combining two solutions to solve one problem. We agree of course, that SSL, properly used - with no human error, is = enough to secure the secrets between the two parties. However, secondary = protection mechanisms are popular in the financial world - site keys, = RSA fobs, shared secrets, IP-filtering, SMS-issued pins. Though any one = mechanism is enough, a second mechanism makes things even more difficult = for clever attackers (and careless developers). Given the options = available to us, shared secrets confirmed though the use of signatures = offer the most attractive balance of protection vs. ease of deployment = (many of our partners are in developing countries which offer logistical = and technological challenges to other methods). That said, I don't advocate requiring signatures as a part of the spec = (our needs/preferences are possibly too unique?), but I would like them = included. Thus, if some non-political use cases drive signatures to be = added, we'd certainly like to adopt the common standard. In lack of a = published standard for signatures, we'll add our own layer additional = layers of protection onto the spec as others have done. (OAuth 1.0a = signatures suit us in lack of a simpler new standard for 2.0, especially = given the amount of published works related to doing them correctly.) skylar From mzero@google.com Wed Oct 27 16:42:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562523A6405 for ; Wed, 27 Oct 2010 16:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc7G7pGm1cX1 for ; Wed, 27 Oct 2010 16:42:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2B9113A63D2 for ; Wed, 27 Oct 2010 16:42:49 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o9RNidt6020771 for ; Wed, 27 Oct 2010 16:44:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288223080; bh=SgfrxQlVqBwd53or8RvS3Y3s9B0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type: Content-Transfer-Encoding; b=BznpC3RxQyrH+CsIEe9VFjWypdO6dpvkVOzKtSnXZpGuxLoRN/PwpXijky4OtqsqW Vzw9HxLQnESlQ4y6kLJbA== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by hpaq6.eem.corp.google.com with ESMTP id o9RNi0VJ014120 for ; Wed, 27 Oct 2010 16:44:38 -0700 Received: by yxd5 with SMTP id 5so904303yxd.32 for ; Wed, 27 Oct 2010 16:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=sMafDeFnprQ7hDmDQ1CoMeycD6GRKgBtNQNxT48crRE=; b=XiFw3vLEIJrcVKDW6OWPvDVxV5e6Mo47l//YvUI1BWMg+s3aMBIxREn2BuqLhXcXmg xXo1ZJExH2eAt62BehcA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=RMFnobDrxuyr5RcD4Zo8sRdV8hSitoLs3AqGucF14bENlI4bECUgLoMLXqmtQETS0d GPJLFfg+cxHtpQAtoNrw== Received: by 10.90.62.26 with SMTP id k26mr1726754aga.1.1288223078219; Wed, 27 Oct 2010 16:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.113.6 with HTTP; Wed, 27 Oct 2010 16:44:17 -0700 (PDT) From: Mark Lentczner Date: Wed, 27 Oct 2010 16:44:17 -0700 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [OAUTH-WG] OAuth v2 Authorization Header Credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 23:42:53 -0000 In my work implementing OAuth v2 to draft 10, I have had to review the definition of credentials included in an Authorization header. I believe this current definition has some significant issues for parsers. However, with some small clean up of the definition, proposed below, I believe that the credentials can be made robust and more compatible for existing and future implementations. =3D Background =3D In draft-ietf-oauth-v2-10 =C2=A75.1.1 we find the ABNF for credentials, which is the non-terminal for the value of the Authorization header: credentials =3D "OAuth" RWS access-token [ CS 1#auth-param ] access-token =3D 1*( quoted-char / <"> ) CS =3D OWS "," OWS quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" Section =C2=A71.1 tells us how to interpret this ABNF: This document uses the Augmented Backus-Naur Form (ABNF) notation of [I-D.ietf-httpbis-p1-messaging]. Additionally, the following rules are included from [RFC2617]: realm, auth-param; from [RFC3986]: URI-Reference; and from [I-D.ietf-httpbis-p1-messaging]: OWS, RWS, and quoted-string. In turn, the I-D.ietf-httpbis-p1-messaging draft defines it=E2=80=99s ABNF rules in =C2=A71.2, as an extension of the ABNF defined in RFC5234. In particular, it adds a =E2=80=9C#=E2=80=9D construct.(*) The definition of the Authorization header used in OAuth v2 is based on RFC2617, which in turn is based on RFC2616. There is a potential clash here between the original specification of HTTP, and the new one being worked on by the httpbis WG. In particular, the two sets of standards use different ABNF frameworks. RFC2616 =C2=A714.8 tells us that the Authorization header=E2=80=99s value i= s the non-terminal credentials, which it never defines. RFC2617 takes up the challenge, but defines it multiple times: =C2=A71.2: credentials =3D auth-scheme #auth-param =C2=A72: credentials =3D "Basic" basic-credentials =C2=A73.2.2: credentials =3D "Digest" digest-response But these aren=E2=80=99t at all consistent given that #auth-param is a list= of key/value pairs, whereas basic-credentials is a base64 encoded string, and digest-response is a mixture of key/value pairs and strings. Unfortunately, httpbis WG=E2=80=99s draft draft-ietf-httpbis-p7-auth-11 =C2=A71.2.2 and =C2=A73.2 gums things up by referring back to RFC2617 for t= he definition of credentials, thus mixing two ABNF forms... The OAuth draft, RFC5849 =C2=A73.5.1 defines credentials that start with an auth-scheme of =E2=80=9COAuth=E2=80=9D, and so any reuse of that auth-schem= e would have to be compatible with it. Alas, it doesn=E2=80=99t use an ABNF to spec= ify it=E2=80=99s credentials. The prose reads as a comma separated list of key/value pairs, where all the keys start with =E2=80=9Coauth_=E2=80=9D or = are the key =E2=80=9Crealm=E2=80=9D, and all the values must be quoted. This is yet a f= ourth form! =3D Problems =3D In the current OAuth v2 draft 10, there is a clash between the comma in CS and having comma as part of access-token. Upon encountering a comma, how do you know if it is part of the token, or introducing the optional list of auth-param values? As defined, these v2 credentials may not be parsable by the v1 syntax. The non-key/value access-token would be illegal. This might be considered good, and perhaps it was the intention to make this the way to distinguish the two types of credentials. However, it is flawed because the equal sign and quote characters are both legal as part of the access-token. Hence realm=3D"Example" is both a legal OAuth v2 access-token, and the legal start of an OAuth v1 credential. What=E2=80=99s worse is that comma is allowed in access-token, and so actually, ALL OAuth v1 credentials could be seen as v2 access-tokens, or not, or even parsed as some prefix that is the access-token and remainder that are the auth-params. =3D=3D Minor Problems =3D=3D The non-terminal access-token as defined includes characters that are not allowed in a structured header value without being inside a quoted string. See I-D.ietf-httpbis-p1-messaging =C2=A71.2.2. However, that same draft, for historical reasons, gives headers considerable leeway in violating this, =C2=A73.2. The access-token allows quote characters, but not as delimiters. This is somewhat at odds with the normal header parsing of tokens. It would be clear what "foo" means: Is that three characters (as in a quoted-string) or five characters, including the quotes? =3D Possible Solutions =3D I am going to assume that the intention of RFC2617, and the eventually httpbis auth drafts is that after the scheme, you have a comma separated list of items, where the items are either strings, or key/value pairs. I also assume the intention was to make v1 vs. v2 credentials distinguishable syntactically even though they shared the =E2=80=9COAuth=E2=80=9D scheme. This would imply that quote, equals sign, and comma should be removed from access-token. But that would remove the pad character (=E2=80=9C=3D=E2= =80=9D) used in all Base64 encodings, which seems common for tokens. We can get around this by either: =E2=80=A2=C2=A0quoting the access token =E2=80=A2=C2=A0defining that the first, and only the first, item is not= a key/value pair, but just a value =E2=80=A2=C2=A0putting the access token in a key/value pair =3D Proposal =3D I met with a number of other engineers here at Google that have been involled in our OAuth efforts for some time. We discussed the merits of various approaches I came up with, and so now I propose the following: =3D=3D OAuth2 Credentials =3D=3D This follows the basic form as laid out by RFC2617 =C2=A71.2, but defined in terms of the ABNF used in httpbis: credentials =3D "OAuth2" RWS #auth-param auth-param =3D auth-key "=3D" ( token | quoted-string ) auth-key =3D "realm" / "access_token" / future-key future-key =3D token N.B.: The values are either tokens or quoted strings, which have escaping rules defined in httpbis. Notably, the equals sign and forward slash are not allowed in token, and so base64 encoded values would have to be placed within double quotes. The future-key rule allows for future extension. In the spirit of the rest of the v2 draft, the parameters are named without any prefix. The scheme has been changed, so that a choice of parsers can be made up-front, rather than attempting to validate under OAuth v1 rules, then falling back to some v2 set of rules when that fails. Interoperating with Draft 10 Implementations In order to be able to consistently interpret credentials that have been deployed under draft 10, we recommend the following algorithm: if the string "oauth_signature=3D" is in the credential then parse as an OAuth v1 credential otherwise the credential is an OAuth v2 draft 10 credential, to be parsed as: draft10credentials =3D "OAuth" RWS draft10value draft10value =3D access-token [ WSP VCHAR* ] =3D=3D Alternative =3D=3D If the community deems it infeasible to use a v2 specific auth-scheme, then these rules need to be altered so that they are compliant with OAuth v1, yet rigorous. In particular, OAuth v1 requires the double quotes, but is silent about what is legal inside them, or how quoting works. This alternative proposal tightens that up: credentials =3D "OAuth" RWS #auth-param auth-param =3D auth-key "=3D" quoted-string auth-key =3D "realm" / oauth1-key / oauth2-key / future-key oauth1-key =3D "oauth_" oauth1-param oauth1-param =3D "consumer_key" / "token" / "signature" / and many ot= hers... oauth2-key =3D "oauth2_" oauth2-param oauth2-param =3D "access_token" future-key =3D token Lastly, if there was significant compatability issues with introducing a new prefix to key values in OAuth credentials, then "oauth_" could be used as the prefix for all keys, and OAuth v2 would rely on its parameter names not clashing with OAuth v1's. This all being said, I, and the engineers I talked with, feel that there would be far fewer compatability issues if the existing OAuth v1 credential processing code were left as is, and OAuth v2 went with the new auth-scheme of "OAuth2" for its credentials. =E2=80=94 Mark Lentczner, mzero@google.com (*) It spells out a very clear definition, which I think is slightly different than previous such constructs. Nonetheless, note that consumers must accept lists with missing elements, and possibly leading and/or trailing commas, none of which contribute elements to the semantic list. Producers, on the other hand, must not generate such things. From gffletch@aol.com Wed Oct 27 19:00:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9133A67AF for ; Wed, 27 Oct 2010 19:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwbaA-50Lgh8 for ; Wed, 27 Oct 2010 19:00:29 -0700 (PDT) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by core3.amsl.com (Postfix) with ESMTP id 836EB3A67EC for ; Wed, 27 Oct 2010 19:00:29 -0700 (PDT) Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-ma05.mx.aol.com (8.14.1/8.14.1) with ESMTP id o9S222Tr031195; Wed, 27 Oct 2010 22:02:02 -0400 Received: from palantir.local (unknown [10.172.3.91]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 37976E0000AC; Wed, 27 Oct 2010 22:01:56 -0400 (EDT) Message-ID: <4CC8D993.1050503@aol.com> Date: Wed, 27 Oct 2010 22:01:55 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Freeman, Tim" References: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com> <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> Content-Type: multipart/alternative; boundary="------------070609090909070308020708" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:514195968:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29044cc8d9941a12 X-AOL-IP: 10.172.3.91 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 02:00:31 -0000 This is a multi-part message in MIME format. --------------070609090909070308020708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I'm not sure what you mean by signatures improving privacy? I don't see=20 signature having much effect on privacy. Encryption is needed for that. However, signatures do limit the scope of exposure should a token get=20 exposed in some manner. In that sense a user is protected because a=20 leaked token isn't usable accept by the party to which it was issued. I also believe that signatures are orthogonal to the delegation use=20 case. In other words, signatures don't prevent server A from getting a=20 token and giving it to server B for server B to use with a protected=20 resource. Thanks, George On 10/27/10 2:09 PM, Freeman, Tim wrote: > On the face of it, it seems that discussion of whether and how to split= the document has derailed collection of use cases. If we had consensus = on a list of use cases, that would mean we have identified the problems w= e're trying to solve. This would still allow slimy political manipulatio= n of the process by manipulating the use case list, but that would be pro= gress. It's better to have a protocol that solves a politically-defined = set of problems than to have a politically-defined protocol that solves n= o identified problem. > > It's also possible that such collection is going on via private email a= nd I am not aware of it. > > The questions currently interesting to me about use cases are: > > * The only use cases that made sense to me about signatures used them f= or auditability, where they enabled blame to be properly placed after inf= ormation leaked to the wrong people. People were proposing use cases tha= t claimed that signatures improved privacy, that is, the ability to keep = the information out of the hands of the wrong people. So far as I know a= ll use cases where signatures improved privacy seemed to fall apart after= a few minutes inspection. Do we agree that signatures improve auditabil= ity but not privacy, or does someone still believe in a use case where si= gnatures improve privacy? > > * Use cases that justify a feature seem to require two parts -- an exam= ple where the feature is absent and therefore a particular problem cannot= be solved, and an example where the feature is present and the same prob= lem can then be solved. Last I checked the existing use case list seemed= to only have the second type where problems were successfully solved and= it was unclear to me that the proposed features were really required in = order to do that. Do we agree that justifying a feature requires both a = use case where absence of the feature makes a problem unsolvable and pres= ence of the feature makes the same problem solvable? (Alternatives are t= o believe that there is some other way to justify having a feature, or to= believe we should have features that do not have a clearly described tec= hnical justification. Maybe the features are required by law, are esthet= ically pleasing, make use of the right patents and not the wrong ones, lo= ok impressive on one's resume, etc.) > > * The simplest signature schemes seem have the consequence of preventin= g server A from delegating work to server B, since the work must be done = by making requests signed by server A. Do we want to support use cases w= here one server delegates work to another server? Do we want to do by al= lowing A's right to do certain things to be traded in for something that = gives B the right to do some of those things, by bearer tokens, by some o= ther means, or not at all? > > Tim Freeman > Email:tim.freeman@hp.com > Desk in Palo Alto: (650) 857-2581 > Home: (408) 774-1298 > Cell: (408) 348-7536 > > > -----Original Message----- > From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Wednesday, October 27, 2010 9:57 AM > To: Hannes Tschofenig; Blaine Cook;oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split > > Thanks for your confidence in me. I look forward to completing a speci= fication that meets the industry needs. > > I plan to sync with Eran this week. I also plan to hold a "listening t= our" at IIW to understand stakeholders' perspectives on where we stand wi= th OAuth 2.0 today and what remains to do finish it. Please come talk to= me at IIW if you're there and you're building or deploying OAuth 2.0 and= want me to understand your views. E-mail and phone calls are also welco= me. > > Once I've synced with Eran and gathered input from stakeholders, I'll p= lan on announcing target dates for drafts. > > -- Mike > > -----Original Message----- > From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: Wednesday, October 27, 2010 4:34 AM > To: Blaine Cook;oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split > > Hi all, > > based on the feedback from the group on the list we go forward with the= document split. > > Mike had kindly offered to edit the bearer specification and we are hap= py to hear that. Thank you Mike. I am looking forward to see the first do= cument. > > Ciao > Hannes > > On 10/14/10 3:32 AM, "Blaine Cook" wrote: > >> Over the past few weeks, the working group debated the issues around >> the introduction of signatures and the structure of the specification.= >> The working group seems to endorse the proposal to split the current >> specification into two parts: one including section 5 (bearer token) >> and the other including the rest (how to obtain a token), with an >> additional specification covering signature use cases. >> >> This serves as a call for consensus on the proposed editorial work. >> Before we proceed with the changes, the chairs would like to ask if >> anyone has any concerns or objections against this proposal. >> >> In addition, the chairs are seeking a volunteer to take over the >> bearer token specification (section 5) as editor. >> >> Please submit your comments by Wednesday, October 20th. >> >> - The OAuth Working Group Chairs >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------070609090909070308020708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I'm not sure what you mean by signatures improving privacy? I don't see signature having much effect on privacy. Encryption is needed for that.

However, signatures do limit the scope of exposure should a token get exposed in some manner. In that sense a user is protected because a leaked token isn't usable accept by the party to which it was issued.

I also believe that signatures are orthogonal to the delegation use case. In other words, signatures don't prevent server A from getting a token and giving it to server B for server B to use with a protected resource.

Thanks,
George

On 10/27/10 2:09 PM, Freeman, Tim wrote: 
On the face of it, it seems that discussion of whether and how to split the document has derailed collection of use cases.  If we had consensus on a list of use cases, that would mean we have identified the problems we're trying to solve.  This would still allow slimy political manipulation of the process by manipulating the use case list, but that would be progress.  It's better to have a protocol that solves a politically-defined set of problems than to have a politically-defined protocol that solves no identified problem.

It's also possible that such collection is going on via private email and I am not aware of it.

The questions currently interesting to me about use cases are:

* The only use cases that made sense to me about signatures used them for auditability, where they enabled blame to be properly placed after information leaked to the wrong people.  People were proposing use cases that claimed that signatures improved privacy, that is, the ability to keep the information out of the hands of the wrong people.  So far as I know all use cases where signatures improved privacy seemed to fall apart after a few minutes inspection.  Do we agree that signatures improve auditability but not privacy, or does someone still believe in a use case where signatures improve privacy?

* Use cases that justify a feature seem to require two parts -- an example where the feature is absent and therefore a particular problem cannot be solved, and an example where the feature is present and the same problem can then be solved.  Last I checked the existing use case list seemed to only have the second type where problems were successfully solved and it was unclear to me that the proposed features were really required in order to do that.  Do we agree that justifying a feature requires both a use case where absence of the feature makes a problem unsolvable and presence of the feature makes the same problem solvable?  (Alternatives are to believe that there is some other way to justify having a feature, or to believe we should have features that do not have a clearly described technical justification.  Maybe the features are required by law, are esthetically pleasing, make use of the right patents and not the wrong ones, look impressive on one's resume, etc.)

* The simplest signature schemes seem have the consequence of preventing server A from delegating work to server B, since the work must be done by making requests signed by server A.  Do we want to support use cases where one server delegates work to another server?  Do we want to do by allowing A's right to do certain things to be traded in for something that gives B the right to do some of those things, by bearer tokens, by some other means, or not at all?

Tim Freeman
Email: tim.freeman@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, October 27, 2010 9:57 AM
To: Hannes Tschofenig; Blaine Cook; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

Thanks for your confidence in me.  I look forward to completing a specification that meets the industry needs.

I plan to sync with Eran this week.  I also plan to hold a "listening tour" at IIW to understand stakeholders' perspectives on where we stand with OAuth 2.0 today and what remains to do finish it.  Please come talk to me at IIW if you're there and you're building or deploying OAuth 2.0 and want me to understand your views.  E-mail and phone calls are also welcome.

Once I've synced with Eran and gathered input from stakeholders, I'll plan on announcing target dates for drafts.

                -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 27, 2010 4:34 AM
To: Blaine Cook; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

Hi all, 

based on the feedback from the group on the list we go forward with the document split. 

Mike had kindly offered to edit the bearer specification and we are happy to hear that. Thank you Mike. I am looking forward to see the first document.

Ciao
Hannes

On 10/14/10 3:32 AM, "Blaine Cook" <romeda@gmail.com> wrote:


Over the past few weeks, the working group debated the issues around 
the introduction of signatures and the structure of the specification.
The working group seems to endorse the proposal to split the current 
specification into two parts: one including section 5 (bearer token) 
and the other including the rest (how to obtain a token), with an 
additional specification covering signature use cases.

This serves as a call for consensus on the proposed editorial work.
Before we proceed with the changes, the chairs would like to ask if 
anyone has any concerns or objections against this proposal.

In addition, the chairs are seeking a volunteer to take over the 
bearer token specification (section 5) as editor.

Please submit your comments by Wednesday, October 20th.

- The OAuth Working Group Chairs
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------070609090909070308020708-- From James.H.Manger@team.telstra.com Wed Oct 27 21:12:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4A43A680B for ; Wed, 27 Oct 2010 21:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsbecqHtUmlB for ; Wed, 27 Oct 2010 21:12:29 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 57A513A67AC for ; Wed, 27 Oct 2010 21:12:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,249,1286110800"; d="scan'208";a="18451714" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Oct 2010 15:14:08 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6149"; a="12395752" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 28 Oct 2010 15:14:08 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 28 Oct 2010 15:14:08 +1100 From: "Manger, James H" To: Mark Lentczner , "oauth@ietf.org" Date: Thu, 28 Oct 2010 15:14:07 +1100 Thread-Topic: [OAUTH-WG] OAuth v2 Authorization Header Credentials Thread-Index: Act2MPRZVlUjg/E2RnyJUM5Sj5QJ6gAJZGCQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127396E2FA@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth v2 Authorization Header Credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 04:12:31 -0000 DQoNCi0tDQpKYW1lcyBNYW5nZXINCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBv YXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcmsgTGVudGN6bmVyDQpTZW50OiBUaHVyc2RheSwgMjggT2N0b2JlciAyMDEw IDEwOjQ0IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGgg djIgQXV0aG9yaXphdGlvbiBIZWFkZXIgQ3JlZGVudGlhbHMNCg0KSW4gbXkgd29yayBpbXBsZW1l bnRpbmcgT0F1dGggdjIgdG8gZHJhZnQgMTAsIEkgaGF2ZSBoYWQgdG8gcmV2aWV3IHRoZQ0KZGVm aW5pdGlvbiBvZiBjcmVkZW50aWFscyBpbmNsdWRlZCBpbiBhbiBBdXRob3JpemF0aW9uIGhlYWRl ci4gSQ0KYmVsaWV2ZSB0aGlzIGN1cnJlbnQgZGVmaW5pdGlvbiBoYXMgc29tZSBzaWduaWZpY2Fu dCBpc3N1ZXMgZm9yDQpwYXJzZXJzLiBIb3dldmVyLCB3aXRoIHNvbWUgc21hbGwgY2xlYW4gdXAg b2YgdGhlIGRlZmluaXRpb24sIHByb3Bvc2VkDQpiZWxvdywgSSBiZWxpZXZlIHRoYXQgdGhlIGNy ZWRlbnRpYWxzIGNhbiBiZSBtYWRlIHJvYnVzdCBhbmQgbW9yZQ0KY29tcGF0aWJsZSBmb3IgZXhp c3RpbmcgYW5kIGZ1dHVyZSBpbXBsZW1lbnRhdGlvbnMuDQoNCj0gQmFja2dyb3VuZCA9DQpJbiBk cmFmdC1pZXRmLW9hdXRoLXYyLTEwIMKnNS4xLjEgd2UgZmluZCB0aGUgQUJORiBmb3IgY3JlZGVu dGlhbHMsDQp3aGljaCBpcyB0aGUgbm9uLXRlcm1pbmFsIGZvciB0aGUgdmFsdWUgb2YgdGhlIEF1 dGhvcml6YXRpb24gaGVhZGVyOg0KICAgIGNyZWRlbnRpYWxzICAgID0gIk9BdXRoIiBSV1MgYWNj ZXNzLXRva2VuIFsgQ1MgMSNhdXRoLXBhcmFtIF0NCiAgICBhY2Nlc3MtdG9rZW4gICA9IDEqKCBx dW90ZWQtY2hhciAvIDwiPiApDQoNCiAgICBDUyAgICAgICAgICAgICA9IE9XUyAiLCIgT1dTDQoN CiAgICBxdW90ZWQtY2hhciAgICA9ICAgIiEiIC8gIiMiIC8gIiQiIC8gIiUiIC8gIiYiIC8gIici IC8gIigiDQogICAgICAgICAgICAgICAgICAgICAvICIpIiAvICIqIiAvICIrIiAvICItIiAvICIu IiAvICIvIiAvIERJR0lUDQogICAgICAgICAgICAgICAgICAgICAvICI6IiAvICI8IiAvICI9IiAv ICI+IiAvICI/IiAvICJAIiAvIEFMUEhBDQogICAgICAgICAgICAgICAgICAgICAvICJbIiAvICJd IiAvICJeIiAvICJfIiAvICJgIiAvICJ7IiAvICJ8Ig0KICAgICAgICAgICAgICAgICAgICAgLyAi fSIgLyAifiIgLyAiXCIgLyAiLCIgLyAiOyINCg0KU2VjdGlvbiDCpzEuMSB0ZWxscyB1cyBob3cg dG8gaW50ZXJwcmV0IHRoaXMgQUJORjoNClRoaXMgZG9jdW1lbnQgdXNlcyB0aGUgQXVnbWVudGVk IEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYpIG5vdGF0aW9uIG9mDQpbSS1ELmlldGYtaHR0cGJpcy1w MS1tZXNzYWdpbmddLiAgQWRkaXRpb25hbGx5LCB0aGUgZm9sbG93aW5nIHJ1bGVzDQphcmUgaW5j bHVkZWQgZnJvbSBbUkZDMjYxN106IHJlYWxtLCBhdXRoLXBhcmFtOyBmcm9tIFtSRkMzOTg2XToN ClVSSS1SZWZlcmVuY2U7IGFuZCBmcm9tIFtJLUQuaWV0Zi1odHRwYmlzLXAxLW1lc3NhZ2luZ106 IE9XUywgUldTLCBhbmQNCnF1b3RlZC1zdHJpbmcuDQoNCkluIHR1cm4sIHRoZSBJLUQuaWV0Zi1o dHRwYmlzLXAxLW1lc3NhZ2luZyBkcmFmdCBkZWZpbmVzIGl04oCZcyBBQk5GDQpydWxlcyBpbiDC pzEuMiwgYXMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBBQk5GIGRlZmluZWQgaW4gUkZDNTIzNC4gSW4N CnBhcnRpY3VsYXIsIGl0IGFkZHMgYSDigJwj4oCdIGNvbnN0cnVjdC4oKikNCg0KVGhlIGRlZmlu aXRpb24gb2YgdGhlIEF1dGhvcml6YXRpb24gaGVhZGVyIHVzZWQgaW4gT0F1dGggdjIgaXMgYmFz ZWQNCm9uIFJGQzI2MTcsIHdoaWNoIGluIHR1cm4gaXMgYmFzZWQgb24gUkZDMjYxNi4gVGhlcmUg aXMgYSBwb3RlbnRpYWwNCmNsYXNoIGhlcmUgYmV0d2VlbiB0aGUgb3JpZ2luYWwgc3BlY2lmaWNh dGlvbiBvZiBIVFRQLCBhbmQgdGhlIG5ldyBvbmUNCmJlaW5nIHdvcmtlZCBvbiBieSB0aGUgaHR0 cGJpcyBXRy4gSW4gcGFydGljdWxhciwgdGhlIHR3byBzZXRzIG9mDQpzdGFuZGFyZHMgdXNlIGRp ZmZlcmVudCBBQk5GIGZyYW1ld29ya3MuDQoNClJGQzI2MTYgwqcxNC44IHRlbGxzIHVzIHRoYXQg dGhlIEF1dGhvcml6YXRpb24gaGVhZGVy4oCZcyB2YWx1ZSBpcyB0aGUNCm5vbi10ZXJtaW5hbCBj cmVkZW50aWFscywgd2hpY2ggaXQgbmV2ZXIgZGVmaW5lcy4gUkZDMjYxNyB0YWtlcyB1cCB0aGUN CmNoYWxsZW5nZSwgYnV0IGRlZmluZXMgaXQgbXVsdGlwbGUgdGltZXM6DQogICAgwqcxLjI6ICAg ICAgICAgICAgICAgY3JlZGVudGlhbHMgPSBhdXRoLXNjaGVtZSAjYXV0aC1wYXJhbQ0KICAgIMKn MjogICAgICAgICAgIGNyZWRlbnRpYWxzID0gIkJhc2ljIiBiYXNpYy1jcmVkZW50aWFscw0KICAg IMKnMy4yLjI6ICAgICBjcmVkZW50aWFscyA9ICJEaWdlc3QiIGRpZ2VzdC1yZXNwb25zZQ0KDQpC dXQgdGhlc2UgYXJlbuKAmXQgYXQgYWxsIGNvbnNpc3RlbnQgZ2l2ZW4gdGhhdCAjYXV0aC1wYXJh bSBpcyBhIGxpc3Qgb2YNCmtleS92YWx1ZSBwYWlycywgd2hlcmVhcyBiYXNpYy1jcmVkZW50aWFs cyBpcyBhIGJhc2U2NCBlbmNvZGVkIHN0cmluZywNCmFuZCBkaWdlc3QtcmVzcG9uc2UgaXMgYSBt aXh0dXJlIG9mIGtleS92YWx1ZSBwYWlycyBhbmQgc3RyaW5ncy4NCg0KVW5mb3J0dW5hdGVseSwg aHR0cGJpcyBXR+KAmXMgZHJhZnQgIGRyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRoLTExDQrCpzEu Mi4yIGFuZCDCpzMuMiBndW1zIHRoaW5ncyB1cCBieSByZWZlcnJpbmcgYmFjayB0byBSRkMyNjE3 IGZvciB0aGUNCmRlZmluaXRpb24gb2YgY3JlZGVudGlhbHMsIHRodXMgbWl4aW5nIHR3byBBQk5G IGZvcm1zLi4uDQoNClRoZSBPQXV0aCBkcmFmdCwgUkZDNTg0OSDCpzMuNS4xIGRlZmluZXMgY3Jl ZGVudGlhbHMgdGhhdCBzdGFydCB3aXRoIGFuDQphdXRoLXNjaGVtZSBvZiDigJxPQXV0aOKAnSwg YW5kIHNvIGFueSByZXVzZSBvZiB0aGF0IGF1dGgtc2NoZW1lIHdvdWxkDQpoYXZlIHRvIGJlIGNv bXBhdGlibGUgd2l0aCBpdC4gQWxhcywgaXQgZG9lc27igJl0IHVzZSBhbiBBQk5GIHRvIHNwZWNp ZnkNCml04oCZcyBjcmVkZW50aWFscy4gVGhlIHByb3NlIHJlYWRzIGFzIGEgY29tbWEgc2VwYXJh dGVkIGxpc3Qgb2YNCmtleS92YWx1ZSBwYWlycywgd2hlcmUgYWxsIHRoZSBrZXlzIHN0YXJ0IHdp dGgg4oCcb2F1dGhf4oCdIG9yIGFyZSB0aGUga2V5DQrigJxyZWFsbeKAnSwgYW5kIGFsbCB0aGUg dmFsdWVzIG11c3QgYmUgcXVvdGVkLiBUaGlzIGlzIHlldCBhIGZvdXJ0aCBmb3JtIQ0KDQoNCj0g UHJvYmxlbXMgPQ0KSW4gdGhlIGN1cnJlbnQgT0F1dGggdjIgZHJhZnQgMTAsIHRoZXJlIGlzIGEg Y2xhc2ggYmV0d2VlbiB0aGUgY29tbWENCmluIENTIGFuZCBoYXZpbmcgY29tbWEgYXMgcGFydCBv ZiBhY2Nlc3MtdG9rZW4uIFVwb24gZW5jb3VudGVyaW5nIGENCmNvbW1hLCBob3cgZG8geW91IGtu b3cgaWYgaXQgaXMgcGFydCBvZiB0aGUgdG9rZW4sIG9yIGludHJvZHVjaW5nIHRoZQ0Kb3B0aW9u YWwgbGlzdCBvZiBhdXRoLXBhcmFtIHZhbHVlcz8NCg0KQXMgZGVmaW5lZCwgdGhlc2UgdjIgY3Jl ZGVudGlhbHMgbWF5IG5vdCBiZSBwYXJzYWJsZSBieSB0aGUgdjEgc3ludGF4Lg0KVGhlIG5vbi1r ZXkvdmFsdWUgYWNjZXNzLXRva2VuIHdvdWxkIGJlIGlsbGVnYWwuIFRoaXMgbWlnaHQgYmUNCmNv bnNpZGVyZWQgZ29vZCwgYW5kIHBlcmhhcHMgaXQgd2FzIHRoZSBpbnRlbnRpb24gdG8gbWFrZSB0 aGlzIHRoZSB3YXkNCnRvIGRpc3Rpbmd1aXNoIHRoZSB0d28gdHlwZXMgb2YgY3JlZGVudGlhbHMu IEhvd2V2ZXIsIGl0IGlzIGZsYXdlZA0KYmVjYXVzZSB0aGUgZXF1YWwgc2lnbiBhbmQgcXVvdGUg Y2hhcmFjdGVycyBhcmUgYm90aCBsZWdhbCBhcyBwYXJ0IG9mDQp0aGUgYWNjZXNzLXRva2VuLiBI ZW5jZSByZWFsbT0iRXhhbXBsZSIgaXMgYm90aCBhIGxlZ2FsIE9BdXRoIHYyDQphY2Nlc3MtdG9r ZW4sIGFuZCB0aGUgbGVnYWwgc3RhcnQgb2YgYW4gT0F1dGggdjEgY3JlZGVudGlhbC4gV2hhdOKA mXMNCndvcnNlIGlzIHRoYXQgY29tbWEgaXMgYWxsb3dlZCBpbiBhY2Nlc3MtdG9rZW4sIGFuZCBz byBhY3R1YWxseSwgQUxMDQpPQXV0aCB2MSBjcmVkZW50aWFscyBjb3VsZCBiZSBzZWVuIGFzIHYy IGFjY2Vzcy10b2tlbnMsIG9yIG5vdCwgb3INCmV2ZW4gcGFyc2VkIGFzIHNvbWUgcHJlZml4IHRo YXQgaXMgdGhlIGFjY2Vzcy10b2tlbiBhbmQgcmVtYWluZGVyIHRoYXQNCmFyZSB0aGUgYXV0aC1w YXJhbXMuDQoNCj09IE1pbm9yIFByb2JsZW1zID09DQpUaGUgbm9uLXRlcm1pbmFsIGFjY2Vzcy10 b2tlbiBhcyBkZWZpbmVkIGluY2x1ZGVzIGNoYXJhY3RlcnMgdGhhdCBhcmUNCm5vdCBhbGxvd2Vk IGluIGEgc3RydWN0dXJlZCBoZWFkZXIgdmFsdWUgd2l0aG91dCBiZWluZyBpbnNpZGUgYSBxdW90 ZWQNCnN0cmluZy4gU2VlICBJLUQuaWV0Zi1odHRwYmlzLXAxLW1lc3NhZ2luZyDCpzEuMi4yLiBI b3dldmVyLCB0aGF0IHNhbWUNCmRyYWZ0LCBmb3IgaGlzdG9yaWNhbCByZWFzb25zLCBnaXZlcyBo ZWFkZXJzIGNvbnNpZGVyYWJsZSBsZWV3YXkgaW4NCnZpb2xhdGluZyB0aGlzLCDCpzMuMi4NCg0K VGhlIGFjY2Vzcy10b2tlbiBhbGxvd3MgcXVvdGUgY2hhcmFjdGVycywgYnV0IG5vdCBhcyBkZWxp bWl0ZXJzLiBUaGlzDQppcyBzb21ld2hhdCBhdCBvZGRzIHdpdGggdGhlIG5vcm1hbCBoZWFkZXIg cGFyc2luZyBvZiB0b2tlbnMuIEl0IHdvdWxkDQpiZSBjbGVhciB3aGF0ICJmb28iIG1lYW5zOiBJ cyB0aGF0IHRocmVlIGNoYXJhY3RlcnMgKGFzIGluIGENCnF1b3RlZC1zdHJpbmcpIG9yIGZpdmUg Y2hhcmFjdGVycywgaW5jbHVkaW5nIHRoZSBxdW90ZXM/DQoNCg0KPSBQb3NzaWJsZSBTb2x1dGlv bnMgPQ0KSSBhbSBnb2luZyB0byBhc3N1bWUgdGhhdCB0aGUgaW50ZW50aW9uIG9mIFJGQzI2MTcs IGFuZCB0aGUgZXZlbnR1YWxseQ0KaHR0cGJpcyBhdXRoIGRyYWZ0cyBpcyB0aGF0IGFmdGVyIHRo ZSBzY2hlbWUsIHlvdSBoYXZlIGEgY29tbWENCnNlcGFyYXRlZCBsaXN0IG9mIGl0ZW1zLCB3aGVy ZSB0aGUgaXRlbXMgYXJlIGVpdGhlciBzdHJpbmdzLCBvcg0Ka2V5L3ZhbHVlIHBhaXJzLiBJIGFs c28gYXNzdW1lIHRoZSBpbnRlbnRpb24gd2FzIHRvIG1ha2UgdjEgdnMuIHYyDQpjcmVkZW50aWFs cyBkaXN0aW5ndWlzaGFibGUgc3ludGFjdGljYWxseSBldmVuIHRob3VnaCB0aGV5IHNoYXJlZCB0 aGUNCuKAnE9BdXRo4oCdIHNjaGVtZS4NCg0KVGhpcyB3b3VsZCBpbXBseSB0aGF0IHF1b3RlLCBl cXVhbHMgc2lnbiwgYW5kIGNvbW1hIHNob3VsZCBiZSByZW1vdmVkDQpmcm9tIGFjY2Vzcy10b2tl bi4gQnV0IHRoYXQgd291bGQgcmVtb3ZlIHRoZSBwYWQgY2hhcmFjdGVyICjigJw94oCdKSB1c2Vk DQppbiBhbGwgQmFzZTY0IGVuY29kaW5ncywgd2hpY2ggc2VlbXMgY29tbW9uIGZvciB0b2tlbnMu IFdlIGNhbiBnZXQNCmFyb3VuZCB0aGlzIGJ5IGVpdGhlcjoNCiAgICDigKIgcXVvdGluZyB0aGUg YWNjZXNzIHRva2VuDQogICAg4oCiIGRlZmluaW5nIHRoYXQgdGhlIGZpcnN0LCBhbmQgb25seSB0 aGUgZmlyc3QsIGl0ZW0gaXMgbm90IGENCmtleS92YWx1ZSBwYWlyLCBidXQganVzdCBhIHZhbHVl DQogICAg4oCiIHB1dHRpbmcgdGhlIGFjY2VzcyB0b2tlbiBpbiBhIGtleS92YWx1ZSBwYWlyDQoN Cg0KPSBQcm9wb3NhbCA9DQpJIG1ldCB3aXRoIGEgbnVtYmVyIG9mIG90aGVyIGVuZ2luZWVycyBo ZXJlIGF0IEdvb2dsZSB0aGF0IGhhdmUgYmVlbg0KaW52b2xsZWQgaW4gb3VyIE9BdXRoIGVmZm9y dHMgZm9yIHNvbWUgdGltZS4gV2UgZGlzY3Vzc2VkIHRoZSBtZXJpdHMNCm9mIHZhcmlvdXMgYXBw cm9hY2hlcyBJIGNhbWUgdXAgd2l0aCwgYW5kIHNvIG5vdyBJIHByb3Bvc2UgdGhlDQpmb2xsb3dp bmc6DQoNCj09IE9BdXRoMiBDcmVkZW50aWFscyA9PQ0KVGhpcyBmb2xsb3dzIHRoZSBiYXNpYyBm b3JtIGFzIGxhaWQgb3V0IGJ5IFJGQzI2MTcgwqcxLjIsIGJ1dCBkZWZpbmVkDQppbiB0ZXJtcyBv ZiB0aGUgQUJORiB1c2VkIGluIGh0dHBiaXM6DQogICAgY3JlZGVudGlhbHMgICAgPSAiT0F1dGgy IiBSV1MgI2F1dGgtcGFyYW0NCiAgICBhdXRoLXBhcmFtICAgICA9IGF1dGgta2V5ICI9IiAoIHRv a2VuIHwgcXVvdGVkLXN0cmluZyApDQogICAgYXV0aC1rZXkgICAgICAgPSAicmVhbG0iIC8gImFj Y2Vzc190b2tlbiIgLyBmdXR1cmUta2V5DQogICAgZnV0dXJlLWtleSAgICAgPSB0b2tlbg0KDQpO LkIuOiBUaGUgdmFsdWVzIGFyZSBlaXRoZXIgdG9rZW5zIG9yIHF1b3RlZCBzdHJpbmdzLCB3aGlj aCBoYXZlDQplc2NhcGluZyBydWxlcyBkZWZpbmVkIGluIGh0dHBiaXMuIE5vdGFibHksIHRoZSBl cXVhbHMgc2lnbiBhbmQNCmZvcndhcmQgc2xhc2ggYXJlIG5vdCBhbGxvd2VkIGluIHRva2VuLCBh bmQgc28gYmFzZTY0IGVuY29kZWQgdmFsdWVzDQp3b3VsZCBoYXZlIHRvIGJlIHBsYWNlZCB3aXRo aW4gZG91YmxlIHF1b3Rlcy4NCg0KVGhlIGZ1dHVyZS1rZXkgcnVsZSBhbGxvd3MgZm9yIGZ1dHVy ZSBleHRlbnNpb24uICBJbiB0aGUgc3Bpcml0IG9mIHRoZQ0KcmVzdCBvZiB0aGUgdjIgZHJhZnQs IHRoZSBwYXJhbWV0ZXJzIGFyZSBuYW1lZCB3aXRob3V0IGFueSBwcmVmaXguIFRoZQ0Kc2NoZW1l IGhhcyBiZWVuIGNoYW5nZWQsIHNvIHRoYXQgYSBjaG9pY2Ugb2YgcGFyc2VycyBjYW4gYmUgbWFk ZQ0KdXAtZnJvbnQsIHJhdGhlciB0aGFuIGF0dGVtcHRpbmcgdG8gdmFsaWRhdGUgdW5kZXIgT0F1 dGggdjEgcnVsZXMsDQp0aGVuIGZhbGxpbmcgYmFjayB0byBzb21lIHYyIHNldCBvZiBydWxlcyB3 aGVuIHRoYXQgZmFpbHMuDQoNCkludGVyb3BlcmF0aW5nIHdpdGggRHJhZnQgMTAgSW1wbGVtZW50 YXRpb25zDQpJbiBvcmRlciB0byBiZSBhYmxlIHRvIGNvbnNpc3RlbnRseSBpbnRlcnByZXQgY3Jl ZGVudGlhbHMgdGhhdCBoYXZlDQpiZWVuIGRlcGxveWVkIHVuZGVyIGRyYWZ0IDEwLCB3ZSByZWNv bW1lbmQgdGhlIGZvbGxvd2luZyBhbGdvcml0aG06DQogICAgaWYgdGhlIHN0cmluZyAib2F1dGhf c2lnbmF0dXJlPSIgaXMgaW4gdGhlIGNyZWRlbnRpYWwNCiAgICAgICAgdGhlbiBwYXJzZSBhcyBh biBPQXV0aCB2MSBjcmVkZW50aWFsDQogICAgICAgIG90aGVyd2lzZSB0aGUgY3JlZGVudGlhbCBp cyBhbiBPQXV0aCB2MiBkcmFmdCAxMCBjcmVkZW50aWFsLA0KdG8gYmUgcGFyc2VkIGFzOg0KDQog ICAgICAgIGRyYWZ0MTBjcmVkZW50aWFscyA9ICJPQXV0aCIgUldTIGRyYWZ0MTB2YWx1ZQ0KICAg ICAgICBkcmFmdDEwdmFsdWUgICAgICAgPSBhY2Nlc3MtdG9rZW4gWyBXU1AgVkNIQVIqIF0NCg0K PT0gQWx0ZXJuYXRpdmUgPT0NCklmIHRoZSBjb21tdW5pdHkgZGVlbXMgaXQgaW5mZWFzaWJsZSB0 byB1c2UgYSB2MiBzcGVjaWZpYyBhdXRoLXNjaGVtZSwNCnRoZW4gdGhlc2UgcnVsZXMgbmVlZCB0 byBiZSBhbHRlcmVkIHNvIHRoYXQgdGhleSBhcmUgY29tcGxpYW50IHdpdGgNCk9BdXRoIHYxLCB5 ZXQgcmlnb3JvdXMuIEluIHBhcnRpY3VsYXIsIE9BdXRoIHYxIHJlcXVpcmVzIHRoZSBkb3VibGUN CnF1b3RlcywgYnV0IGlzIHNpbGVudCBhYm91dCB3aGF0IGlzIGxlZ2FsIGluc2lkZSB0aGVtLCBv ciBob3cgcXVvdGluZw0Kd29ya3MuIFRoaXMgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgdGlnaHRlbnMg dGhhdCB1cDoNCg0KICAgIGNyZWRlbnRpYWxzICAgID0gIk9BdXRoIiBSV1MgI2F1dGgtcGFyYW0N CiAgICBhdXRoLXBhcmFtICAgICA9IGF1dGgta2V5ICI9IiBxdW90ZWQtc3RyaW5nDQogICAgYXV0 aC1rZXkgICAgICAgPSAicmVhbG0iIC8gb2F1dGgxLWtleSAvIG9hdXRoMi1rZXkgLyBmdXR1cmUt a2V5DQoNCiAgICBvYXV0aDEta2V5ICAgICA9ICJvYXV0aF8iIG9hdXRoMS1wYXJhbQ0KICAgIG9h dXRoMS1wYXJhbSAgID0gImNvbnN1bWVyX2tleSIgLyAidG9rZW4iIC8gInNpZ25hdHVyZSIgLyBh bmQgbWFueSBvdGhlcnMuLi4NCg0KICAgIG9hdXRoMi1rZXkgICAgID0gIm9hdXRoMl8iIG9hdXRo Mi1wYXJhbQ0KICAgIG9hdXRoMi1wYXJhbSAgID0gImFjY2Vzc190b2tlbiINCg0KICAgIGZ1dHVy ZS1rZXkgICAgID0gdG9rZW4NCg0KTGFzdGx5LCBpZiB0aGVyZSB3YXMgc2lnbmlmaWNhbnQgY29t cGF0YWJpbGl0eSBpc3N1ZXMgd2l0aCBpbnRyb2R1Y2luZw0KYSBuZXcgcHJlZml4IHRvIGtleSB2 YWx1ZXMgaW4gT0F1dGggY3JlZGVudGlhbHMsIHRoZW4gIm9hdXRoXyIgY291bGQNCmJlIHVzZWQg YXMgdGhlIHByZWZpeCBmb3IgYWxsIGtleXMsIGFuZCBPQXV0aCB2MiB3b3VsZCByZWx5IG9uIGl0 cw0KcGFyYW1ldGVyIG5hbWVzIG5vdCBjbGFzaGluZyB3aXRoIE9BdXRoIHYxJ3MuDQoNClRoaXMg YWxsIGJlaW5nIHNhaWQsIEksIGFuZCB0aGUgZW5naW5lZXJzIEkgdGFsa2VkIHdpdGgsIGZlZWwg dGhhdA0KdGhlcmUgd291bGQgYmUgZmFyIGZld2VyIGNvbXBhdGFiaWxpdHkgaXNzdWVzIGlmIHRo ZSBleGlzdGluZyBPQXV0aCB2MQ0KY3JlZGVudGlhbCBwcm9jZXNzaW5nIGNvZGUgd2VyZSBsZWZ0 IGFzIGlzLCBhbmQgT0F1dGggdjIgd2VudCB3aXRoIHRoZQ0KbmV3IGF1dGgtc2NoZW1lIG9mICJP QXV0aDIiIGZvciBpdHMgY3JlZGVudGlhbHMuDQoNCuKAlCBNYXJrIExlbnRjem5lciwgbXplcm9A Z29vZ2xlLmNvbQ0KDQooKikgSXQgc3BlbGxzIG91dCBhIHZlcnkgY2xlYXIgZGVmaW5pdGlvbiwg d2hpY2ggSSB0aGluayBpcyBzbGlnaHRseQ0KZGlmZmVyZW50IHRoYW4gcHJldmlvdXMgc3VjaCBj b25zdHJ1Y3RzLiBOb25ldGhlbGVzcywgbm90ZSB0aGF0DQpjb25zdW1lcnMgbXVzdCBhY2NlcHQg bGlzdHMgd2l0aCBtaXNzaW5nIGVsZW1lbnRzLCBhbmQgcG9zc2libHkNCmxlYWRpbmcgYW5kL29y IHRyYWlsaW5nIGNvbW1hcywgbm9uZSBvZiB3aGljaCBjb250cmlidXRlIGVsZW1lbnRzIHRvDQp0 aGUgc2VtYW50aWMgbGlzdC4gUHJvZHVjZXJzLCBvbiB0aGUgb3RoZXIgaGFuZCwgbXVzdCBub3Qg Z2VuZXJhdGUNCnN1Y2ggdGhpbmdzLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From James.H.Manger@team.telstra.com Wed Oct 27 22:28:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9677D3A67D7 for ; Wed, 27 Oct 2010 22:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFVvxwFxkcY8 for ; Wed, 27 Oct 2010 22:28:37 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 419C73A682C for ; Wed, 27 Oct 2010 22:28:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,249,1286110800"; d="scan'208";a="18464785" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Oct 2010 16:30:26 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6149"; a="12115034" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Oct 2010 16:30:25 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 28 Oct 2010 16:30:25 +1100 From: "Manger, James H" To: Mark Lentczner , "oauth@ietf.org" Date: Thu, 28 Oct 2010 16:30:24 +1100 Thread-Topic: [OAUTH-WG] OAuth v2 Authorization Header Credentials Thread-Index: Act2MPRZVlUjg/E2RnyJUM5Sj5QJ6gAJbJMw Message-ID: <255B9BB34FB7D647A506DC292726F6E11273A607B8@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth v2 Authorization Header Credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 05:28:40 -0000 TWFyaywNCg0Kwqc1LjEuMSAod2hlcmUgdGhlIEFCTkYgZm9yIGNyZWRlbnRpYWxzIGlzIGRlZmlu ZWQpIHdpbGwgbW92ZSBvdXQgb2YgdGhlIE9BdXRoIGNvcmUgc3BlYyBpbiB0aGUgZG9jIHNwbGl0 Lg0KSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgYmVhcmVyIHNwZWMgdXNlIGEgbm9uLU9BdXRoIHNj aGVtZSBuYW1lIHdoZW4gaXQgZGVmaW5lcyBpdHMgQXV0aG9yaXphdGlvbiBoZWFkZXIuDQoNCkkg c3Ryb25nbHkgZmF2b3VyIHJlc3RyaWN0aW5nIHRva2VucyB0byBhIG11Y2ggc21hbGxlciBhbHBo YWJldCwgc3VjaCBhcyB0aGUgNjYgdW5yZXNlcnZlZCBjaGFycyAoQS1aIGEteiAwLTkgLSBfIC4g fikuIEFueXRoaW5nIG1vcmUgbWVhbnMgd2UgbmVlZCBlc2NhcGluZyBtZWNoYW5pc21zIGluIGFs bCB0aGUgcGxhY2VzIGEgdG9rZW4gY2FuIGdvLiBBbnl0aGluZyBtb3JlIHN0aWxsIGRvZXNuJ3Qg c3VwcG9ydCBhcmJpdHJhcnkgYmluYXJ5IGRhdGEgb3IgYXJiaXRyYXJ5IFVuaWNvZGUgdGV4dCBz byB5b3Ugc3RpbGwgbmVlZCBhbiBlbmNvZGluZyBzdWNoIGFzIGJhc2U2NHVybC4NCg0KU3VwcG9y dGluZyAncXVvdGVkLXN0cmluZycgd291bGQgbm90IGJlIHN0cmljdGx5IG5lY2Vzc2FyeSBmb3Ig YW4gYWNjZXNzLXRva2VuIHBhcmFtZXRlciBpZiB2YWx1ZXMgd2VyZSByZXN0cmljdGVkIHRvIHRo b3NlIDY2IGNoYXJzLiBIb3dldmVyLCBJIHdvdWxkIGJlIGhhcHB5IGVub3VnaCB0byByZXF1aXJl IHBhcnNlcnMgdG8gc3VwcG9ydCAodG9rZW4gfCBxdW90ZWQtc3RyaW5nKS4NCg0KSSBkb24ndCB0 aGluayB3ZSBuZWVkICdyZWFsbScgYXMgYW4gYXV0aC1rZXkuIEl0IGlzIGRlZmluZWQgZm9yIFdX Vy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVycywgYnV0IGlzbid0IG5lY2Vzc2FyeSBmb3Ig QXV0aG9yaXphdGlvbiByZXF1ZXN0IGhlYWRlcnMuDQoNCkknbSBpbiBmYXZvdXIgb2Ygb25seSB1 c2luZyBuYW1lPXZhbHVlIHBhaXJzIGFmdGVyIHRoZSBzY2hlbWUgbmFtZSwgZXZlbiBpZiB0aGVy ZSBpcyBvbmx5IDEgcGFyYW1ldGVyICh0aGUgYmVhcmVyIHRva2VuKS4gSXQgZW5hYmxlcyBwYXJh bWV0ZXJzIHRvIGJlIGFkZGVkIGluIHRoZSBmdXR1cmUuDQoNCk15IHZhcmlhbnQgb2YgeW91ciBw cm9wb3NhbDoNCg0KICAgIGNyZWRlbnRpYWxzICAgID0gIkJFQVJFUiIgUldTICNhdXRoLXBhcmFt DQogICAgYXV0aC1wYXJhbSAgICAgPSBhdXRoLWtleSAiPSIgKCB0b2tlbiB8IHF1b3RlZC1zdHJp bmcgKQ0KICAgIGF1dGgta2V5ICAgICAgID0gImEiIHwgZnV0dXJlLWtleQ0KICAgIGZ1dHVyZS1r ZXkgICAgID0gdG9rZW4NCg0KVGhlICJhIiBwYXJhbWV0ZXIgaG9sZHMgYW4gYWNjZXNzIHRva2Vu IHRoYXQgTVVTVCBvbmx5IGNvbnNpc3Qgb2YgY2hhcnMgZnJvbSB0aGUgc2V0IG9mIDY2IHVucmVz ZXJ2ZWQgY2hhcnMgW3Nob3VsZCBwcm9iYWJseSBleHByZXNzIHRoYXQgaW4gdGhlIEFCTkZdLiBF eGFtcGxlczoNCiAgQXV0aG9yaXphdGlvbjogQkVBUkVSIGE9dkY5ZGZ0NHFtVA0KICBBdXRob3Jp emF0aW9uOiBCRUFSRVIgYT0idkY5ZGZ0NHFtVCINCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgTGVudGN6bmVy DQpTZW50OiBUaHVyc2RheSwgMjggT2N0b2JlciAyMDEwIDEwOjQ0IEFNDQpUbzogb2F1dGhAaWV0 Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggdjIgQXV0aG9yaXphdGlvbiBIZWFkZXIg Q3JlZGVudGlhbHMNCg0KSW4gbXkgd29yayBpbXBsZW1lbnRpbmcgT0F1dGggdjIgdG8gZHJhZnQg MTAsIEkgaGF2ZSBoYWQgdG8gcmV2aWV3IHRoZQ0KZGVmaW5pdGlvbiBvZiBjcmVkZW50aWFscyBp bmNsdWRlZCBpbiBhbiBBdXRob3JpemF0aW9uIGhlYWRlci4gSQ0KYmVsaWV2ZSB0aGlzIGN1cnJl bnQgZGVmaW5pdGlvbiBoYXMgc29tZSBzaWduaWZpY2FudCBpc3N1ZXMgZm9yDQpwYXJzZXJzLiBI b3dldmVyLCB3aXRoIHNvbWUgc21hbGwgY2xlYW4gdXAgb2YgdGhlIGRlZmluaXRpb24sIHByb3Bv c2VkDQpiZWxvdywgSSBiZWxpZXZlIHRoYXQgdGhlIGNyZWRlbnRpYWxzIGNhbiBiZSBtYWRlIHJv YnVzdCBhbmQgbW9yZQ0KY29tcGF0aWJsZSBmb3IgZXhpc3RpbmcgYW5kIGZ1dHVyZSBpbXBsZW1l bnRhdGlvbnMuDQouLi4NCg== From hannes.tschofenig@nsn.com Thu Oct 28 04:02:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4693A67E1 for ; Thu, 28 Oct 2010 04:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH1ZlVgswmDb for ; Thu, 28 Oct 2010 04:02:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 776083A683C for ; Thu, 28 Oct 2010 04:02:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9SB4gXU027011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 13:04:42 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9SB4ght017382; Thu, 28 Oct 2010 13:04:42 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 13:04:42 +0200 Received: from 10.144.244.103 ([10.144.244.103]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Oct 2010 11:04:41 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Thu, 28 Oct 2010 14:04:35 +0300 From: Hannes Tschofenig To: "ext Freeman, Tim" , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoIABLvUp In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2010 11:04:42.0144 (UTC) FILETIME=[EBF73A00:01CB768F] Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 11:02:56 -0000 Hey Tim, Earlier this year we had discussions around use cases but they did not lead to more insight. There is a document in the draft repository that talks about use cases, namely http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ But it had never gotten a lot of attention on the list. (I don't know why.) Efforts to reach out to the Kantara UMA group for more sophisticated uses cases that motivate some security mechanisms have not produced anything either. (I believe the reason was that the scenarios focused on the user-experience aspect rather than on security differences.) If you look at the draft that Blaine and I put together recently (see http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/ ) then you will notice that from a security point of view there is very little difference between using message signing on the HTTP layer and using TLS with respect to a certain class of security threats. In our recommendation we actually suggest to recommend to go for the HTTP layer security because we are worried that ***operational*** aspects will go wrong in deployments. While I was convinced initially that looking at the use cases will get us further on the security questions it actually does not. Ciao Hannes PS: Btw, your feedback on the security draft would be of interest to us. On 10/27/10 9:09 PM, "ext Freeman, Tim" wrote: > On the face of it, it seems that discussion of whether and how to split the > document has derailed collection of use cases. If we had consensus on a list > of use cases, that would mean we have identified the problems we're trying to > solve. This would still allow slimy political manipulation of the process by > manipulating the use case list, but that would be progress. It's better to > have a protocol that solves a politically-defined set of problems than to have > a politically-defined protocol that solves no identified problem. From tonynad@microsoft.com Thu Oct 28 08:05:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744E73A6915 for ; Thu, 28 Oct 2010 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.337 X-Spam-Level: X-Spam-Status: No, score=-10.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSMXh-yI-1Zn for ; Thu, 28 Oct 2010 08:05:34 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1FF9E3A67DA for ; Thu, 28 Oct 2010 08:05:34 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Oct 2010 08:07:26 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.222]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Thu, 28 Oct 2010 08:07:26 -0700 From: Anthony Nadalin To: "sampo@zxidp.org" , Mike Jones Thread-Topic: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery Thread-Index: AQHLdmrtt4/el9ZvDEaQ4UyC5JkUSZNWdqdg Date: Thu, 28 Oct 2010 15:07:24 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <20101027013941.E742F21F40@mail.zxidp.org> In-Reply-To: <20101027013941.E742F21F40@mail.zxidp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" , "openid-specs-connect@lists.openid.net" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:05:35 -0000 Sampo, can you give a usecase of how you would use the pairwise -----Original Message----- From: openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-boun= ces@lists.openid.net] On Behalf Of sampo@zxidp.org Sent: Tuesday, October 26, 2010 6:40 PM To: Mike Jones Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org; open= id-specs-connect@lists.openid.net Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery Simple enough spec. I like the notion of service type. However some questio= ns to answer: How would one convey saml2:Assertion as the "principal"? Or how would one c= onvey a saml2:NameID as the "principal"? Or in more generic sense, how would one convey a pairwise pseudonym as prin= cipal? Cheers, --Sampo Mike Jones said: > Having a simple discovery method for services and resources is key to ena= bling many Internet scenarios that require interactions among parties that = do not have pre-established relationships. For instance, if Joe, with e-ma= il address joe@example.com, wants to share his calendar with Mary, then Mar= y's calendar service, in the general case, will need to discover the locati= on of Joe's calendar service. For example, Mary's calendar service might d= iscover that Joe's calendar service is located at http://calendars.prosewar= e.com/calendar/joseph by doing discovery for a service named urn:adatum.com= :calendar at example.com for the account joe. >=20 > Yaron Goland and I are submitting this Simple Web= Discovery (SWD) draft (attached and at http://self-issued.info/docs/draft-jone= s-simple-web-discovery-00.html) for consideration by the community to addre= ss this need. SWD is simple to understand and implement, enables different= permissions to be applied to discovery of different services, and is JSON-= based. I look forward to discussing this with many of you next week at IIW= . >=20 > --=20 > Mike >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 _______________________________________________ Openid-specs-ab mailing list Openid-specs-ab@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-ab From eve@xmlgrrl.com Thu Oct 28 08:08:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EE23A67DA for ; Thu, 28 Oct 2010 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEy-0B7TZ98p for ; Thu, 28 Oct 2010 08:08:37 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id AD7013A68CE for ; Thu, 28 Oct 2010 08:08:37 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o9SFAQBp010522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Oct 2010 08:10:26 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Thu, 28 Oct 2010 08:10:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1081) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:08:39 -0000 Hi Hannes, Regarding UMA's "security use cases", indeed we haven't been producing = formal use cases in a form that readily maps to what this group is = looking for. However, I've reproduced below the comments I sent you = privately on your OAuth signature thoughts doc (too late for your IETF = submission editing round); they contain specific descriptions and = pointers to a major security requirement of UMA that relates to this = discussion. Eve =3D=3D=3D=3D - The Alice/Bob/Carol language is a bit distracting. I kept scribbling = "authz server" etc. on my copy to make sure I had it straight. Given = that you're talking about OAuth specifically, do you think using real = OAuth terminology would be okay? - (Nit:) At the bottom of page 2, I couldn't understand "...and in = managing a resource that is work delegating access to." - I think there's a threat missing, something like "token replay" (but = that doesn't seem quite right). This is where the Alice language is = holding me back! If Alice =3D=3D client, the token might be stolen by a = malicious client Eve (or Alice might maliciously give it to Eve to use), = then used at Bob as if Eve were Alice. Naming all the threats "token = " makes it hard to decide what to call it, but left to my own = devices I'd call it "client correlation". OAuth seems to want to put = this out of scope, but it's a real problem for UMA, given that our = authorization server and resource server might be in different = administrative domains. You can see the problem statement here: = http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread= /cafa098084c7c208/703617741a124124?lnk=3Dgst&q=3Dstep+3#703617741a124124 ...and our current (very constrained and signature-free!) solution in = Step 3 here: http://mrtopf.clprojects.net/uma/draft-uma-core.html One of the reasons we want to be able to point to/build on an OAuth = signing solution is that a short token lifetime isn't very = performant/scalable. But we're inclined to leave our simple solution in = place as mandatory-to-implement. - Another thing that's probably worth observing is that OAuth thinks of = a token as either containing real assertions or being an artifact that = can be referenced to get to assertions. But UMA's treatment is entirely = consistent too: a token stands for an authorization decision, with all = the specifics of assertions/claims pushed exclusively to the Alice/Carol = (client/authz server) communication. On 28 Oct 2010, at 4:04 AM, Hannes Tschofenig wrote: > Hey Tim,=20 >=20 > Earlier this year we had discussions around use cases but they did not = lead > to more insight.=20 >=20 > There is a document in the draft repository that talks about use = cases, > namely=20 > http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ > But it had never gotten a lot of attention on the list. (I don't know = why.) >=20 > Efforts to reach out to the Kantara UMA group for more sophisticated = uses > cases that motivate some security mechanisms have not produced = anything > either. (I believe the reason was that the scenarios focused on the > user-experience aspect rather than on security differences.) >=20 > If you look at the draft that Blaine and I put together recently (see > = http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/= > ) then you will notice that from a security point of view there is = very > little difference between using message signing on the HTTP layer and = using > TLS with respect to a certain class of security threats. >=20 > In our recommendation we actually suggest to recommend to go for the = HTTP > layer security because we are worried that ***operational*** aspects = will go > wrong in deployments. >=20 > While I was convinced initially that looking at the use cases will get = us > further on the security questions it actually does not. >=20 > Ciao > Hannes >=20 > PS: Btw, your feedback on the security draft would be of interest to = us. >=20 >=20 > On 10/27/10 9:09 PM, "ext Freeman, Tim" wrote: >=20 >> On the face of it, it seems that discussion of whether and how to = split the >> document has derailed collection of use cases. If we had consensus = on a list >> of use cases, that would mean we have identified the problems we're = trying to >> solve. This would still allow slimy political manipulation of the = process by >> manipulating the use case list, but that would be progress. It's = better to >> have a protocol that solves a politically-defined set of problems = than to have >> a politically-defined protocol that solves no identified problem. Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From ve7jtb@ve7jtb.com Thu Oct 28 08:39:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40A83A695C for ; Thu, 28 Oct 2010 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4ULvs0JhtCr for ; Thu, 28 Oct 2010 08:39:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B1F233A6904 for ; Thu, 28 Oct 2010 08:39:12 -0700 (PDT) Received: by gya6 with SMTP id 6so1420265gya.31 for ; Thu, 28 Oct 2010 08:41:04 -0700 (PDT) Received: by 10.151.82.11 with SMTP id j11mr2455432ybl.233.1288280464663; Thu, 28 Oct 2010 08:41:04 -0700 (PDT) Received: from [192.168.1.4] ([190.22.77.161]) by mx.google.com with ESMTPS id z16sm902975ybm.4.2010.10.28.08.41.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 08:41:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-373-735613327; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> Date: Thu, 28 Oct 2010 12:40:58 -0300 Message-Id: <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> To: the Connect work group X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 28 Oct 2010 08:42:24 -0700 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:41:01 -0000 --Apple-Mail-373-735613327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the case where the user logs in to a RP with a PPID type identifier. =20= How could the person then allow the RP to discover their service = endpoints. Also conversely would publishing the endpoint provide a way for the RP = to correlate the user without permission. One common practice for openID PPID is that the IdP generates the PPID = via AES128(actual ID + RP or sector identifier). In that case the RP could do an oauth flow to the IdP discovery endpoint = to get permission to see the user endpoints. The IdP could decrypt the opaque identifier to determine the actual = subject. That would protect the non correlation unless the user decides to permit = discovery. The model if not the details seem similar to some work that is being = submitted to the ITU-T as I understand it. John B. On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: > Sampo, can you give a usecase of how you would use the pairwise >=20 > -----Original Message----- > From: openid-specs-ab-bounces@lists.openid.net = [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of = sampo@zxidp.org > Sent: Tuesday, October 26, 2010 6:40 PM > To: Mike Jones > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org; = openid-specs-connect@lists.openid.net > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > Simple enough spec. I like the notion of service type. However some = questions to answer: >=20 > How would one convey saml2:Assertion as the "principal"? Or how would = one convey a saml2:NameID as the "principal"? >=20 > Or in more generic sense, how would one convey a pairwise pseudonym as = principal? >=20 > Cheers, > --Sampo >=20 > Mike Jones said: >> Having a simple discovery method for services and resources is key to = enabling many Internet scenarios that require interactions among parties = that do not have pre-established relationships. For instance, if Joe, = with e-mail address joe@example.com, wants to share his calendar with = Mary, then Mary's calendar service, in the general case, will need to = discover the location of Joe's calendar service. For example, Mary's = calendar service might discover that Joe's calendar service is located = at http://calendars.proseware.com/calendar/joseph by doing discovery for = a service named urn:adatum.com:calendar at example.com for the account = joe. >>=20 >> Yaron Goland and I are submitting this Simple = Web Discovery = (SWD) draft (attached and at = http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) = for consideration by the community to address this need. SWD is simple = to understand and implement, enables different permissions to be applied = to discovery of different services, and is JSON-based. I look forward = to discussing this with many of you next week at = IIW. >>=20 >> --=20 >> Mike >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > _______________________________________________ > openid-specs-connect mailing list > openid-specs-connect@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-connect --Apple-Mail-373-735613327 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEw MjgxNTQwNThaMCMGCSqGSIb3DQEJBDEWBBSCPw8vyRXtjp+Xdw9dBSTg4mgEMjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBOBIlJjDWxZXE9pWeA+jkJPhN4xOAgtsshncAY/djvljB9SpXDjaw409o0YvJERRdgNllzgWS1 dKzGt9si6Ixq/EyGD0Wic+hdMPFkRTZH9uPoMxuttQmhrmlwuQHsgGfZjhhXRm4oF5bQxDBg7JqD VTQPBNfYhUxYRyP0ah+ARERvt8XtKNeftFzfSdaP7ZBIJQEx+ox8YMKw7Al0mUzN96Z3PtEjzzmF ptZWATMrLc55Tta4GODvCzdu31mZpeGAbWCkwzPF6/FervZ1m9i9Z6y+Uyx2UUdI0XPclsViP7NE nCxMg+CYMTzu+OpS+QS9deWqyK+1tb/oo8TBVRqqAAAAAAAA --Apple-Mail-373-735613327-- From zachary.zeltsan@alcatel-lucent.com Thu Oct 28 12:44:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C123A69B6 for ; Thu, 28 Oct 2010 12:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+-wOXFC0aMm for ; Thu, 28 Oct 2010 12:44:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 19F1C3A6774 for ; Thu, 28 Oct 2010 12:44:39 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o9SJkUU1010473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 14:46:30 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9SJkU5o019844 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 14:46:30 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 28 Oct 2010 14:46:30 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Hannes Tschofenig'" , "ext Freeman, Tim" , "oauth@ietf.org" Date: Thu, 28 Oct 2010 14:46:30 -0500 Thread-Topic: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoIABLvUpgACQVCA= Message-ID: <5710F82C0E73B04FA559560098BF95B124FC20CE11@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 19:44:40 -0000 Hanes, >... >There is a document in the draft repository that talks about use cases,=20 >namely http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ >But it had never gotten a lot of attention on the list. (I don't know=20 >why.) Actually, there is a good news here: We've got 13 queries on the list (in a= ddition to some private ones) with constructive suggestions, and we are wor= king with Torsten on incorporating all of them. In particular, the next iss= ue of the draft will include George's use case submitted recently. Furthermore, as WAC community is looking at OAuth, we will soon have a WAC = use case (or a set of use cases). So, I am pretty happy with the attention level: we get positive contributio= n while not getting disruption. As for specific security issues, I think up to now we dealt with a differen= t problem: Our use cases have reflected authentication requirements, but co= ncentrated on the use scenarios (which protocol features should reflect) ra= ther than dealing with specific threats that affecting the features. This s= pecific work will be coming from Torsten. I am not sure whether the use case document should delve in security detail= , except for cases (such as payment) that in themselves dictate the protect= ion level. As Igor wrote, security requirements for accessing health record= s are very different from those for accessing photos on Flickr. =20 This is what I hope we can discuss at the meeting--formal or informal--in 1= 0 days. I am open to all suggestions. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, October 28, 2010 7:05 AM To: ext Freeman, Tim; oauth@ietf.org Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus o= n Document Split) Hey Tim,=20 Earlier this year we had discussions around use cases but they did not lead to more insight.=20 There is a document in the draft repository that talks about use cases, namely=20 http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ But it had never gotten a lot of attention on the list. (I don't know why.) Efforts to reach out to the Kantara UMA group for more sophisticated uses cases that motivate some security mechanisms have not produced anything either. (I believe the reason was that the scenarios focused on the user-experience aspect rather than on security differences.) If you look at the draft that Blaine and I put together recently (see http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/ ) then you will notice that from a security point of view there is very little difference between using message signing on the HTTP layer and using TLS with respect to a certain class of security threats. In our recommendation we actually suggest to recommend to go for the HTTP layer security because we are worried that ***operational*** aspects will g= o wrong in deployments. While I was convinced initially that looking at the use cases will get us further on the security questions it actually does not. Ciao Hannes PS: Btw, your feedback on the security draft would be of interest to us. On 10/27/10 9:09 PM, "ext Freeman, Tim" wrote: > On the face of it, it seems that discussion of whether and how to split t= he > document has derailed collection of use cases. If we had consensus on a = list > of use cases, that would mean we have identified the problems we're tryin= g to > solve. This would still allow slimy political manipulation of the proces= s by > manipulating the use case list, but that would be progress. It's better = to > have a protocol that solves a politically-defined set of problems than to= have > a politically-defined protocol that solves no identified problem. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Thu Oct 28 16:40:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1303A6801 for ; Thu, 28 Oct 2010 16:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwIHFeGz6-QB for ; Thu, 28 Oct 2010 16:40:46 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E326F3A676A for ; Thu, 28 Oct 2010 16:40:45 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Oct 2010 16:42:33 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.222]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Thu, 28 Oct 2010 16:42:33 -0700 From: Anthony Nadalin To: the Connect work group Thread-Topic: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery Thread-Index: AQHLdmrtt4/el9ZvDEaQ4UyC5JkUSZNWdqdggAB+4wCAABB+4A== Date: Thu, 28 Oct 2010 23:42:31 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> In-Reply-To: <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 23:40:47 -0000 So not sure that this would be handled by the SWD itself but as pointed out= in the SWD specification is that the SWD may be accompanied by an authoriz= ation header and this is where I would expect that to happen -----Original Message----- From: openid-specs-connect-bounces@lists.openid.net [mailto:openid-specs-co= nnect-bounces@lists.openid.net] On Behalf Of John Bradley Sent: Thursday, October 28, 2010 8:41 AM To: the Connect work group Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery In the case where the user logs in to a RP with a PPID type identifier. =20 How could the person then allow the RP to discover their service endpoints. Also conversely would publishing the endpoint provide a way for the RP to c= orrelate the user without permission. One common practice for openID PPID is that the IdP generates the PPID via = AES128(actual ID + RP or sector identifier). In that case the RP could do an oauth flow to the IdP discovery endpoint to= get permission to see the user endpoints. The IdP could decrypt the opaque identifier to determine the actual subject= . That would protect the non correlation unless the user decides to permit di= scovery. The model if not the details seem similar to some work that is being submit= ted to the ITU-T as I understand it. John B. On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: > Sampo, can you give a usecase of how you would use the pairwise >=20 > -----Original Message----- > From: openid-specs-ab-bounces@lists.openid.net=20 > [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of=20 > sampo@zxidp.org > Sent: Tuesday, October 26, 2010 6:40 PM > To: Mike Jones > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org;=20 > openid-specs-connect@lists.openid.net > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > Simple enough spec. I like the notion of service type. However some quest= ions to answer: >=20 > How would one convey saml2:Assertion as the "principal"? Or how would one= convey a saml2:NameID as the "principal"? >=20 > Or in more generic sense, how would one convey a pairwise pseudonym as pr= incipal? >=20 > Cheers, > --Sampo >=20 > Mike Jones said: >> Having a simple discovery method for services and resources is key to en= abling many Internet scenarios that require interactions among parties that= do not have pre-established relationships. For instance, if Joe, with e-m= ail address joe@example.com, wants to share his calendar with Mary, then Ma= ry's calendar service, in the general case, will need to discover the locat= ion of Joe's calendar service. For example, Mary's calendar service might = discover that Joe's calendar service is located at http://calendars.prosewa= re.com/calendar/joseph by doing discovery for a service named urn:adatum.co= m:calendar at example.com for the account joe. >>=20 >> Yaron Goland and I are submitting this Simple We= b Discovery (SWD) draft (attached and at http://self-issued.info/docs/draft-jon= es-simple-web-discovery-00.html) for consideration by the community to addr= ess this need. SWD is simple to understand and implement, enables differen= t permissions to be applied to discovery of different services, and is JSON= -based. I look forward to discussing this with many of you next week at II= W. >>=20 >> --=20 >> Mike >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > _______________________________________________ > openid-specs-connect mailing list > openid-specs-connect@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-connect From Michael.Jones@microsoft.com Thu Oct 28 18:40:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C3B3A672F for ; Thu, 28 Oct 2010 18:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7CWEPId3jw3 for ; Thu, 28 Oct 2010 18:40:27 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1EFC73A69DE for ; Thu, 28 Oct 2010 18:40:24 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Oct 2010 18:42:16 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.105]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Thu, 28 Oct 2010 18:42:16 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Microsoft Deployment of OAuth 2.0 Draft 10 Thread-Index: Act3CoH5s1eMz47ZS421fa+35J8WOw== Date: Fri, 29 Oct 2010 01:42:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943245A9B9E@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943245A9B9ETK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Microsoft Deployment of OAuth 2.0 Draft 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 01:40:43 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943245A9B9ETK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wanted to let people know who may not have seen the announcement, that Mi= crosoft's Access Control Service (ACS) deployed OAuth 2.0 Draft 10 last mon= th using the Web Server and Autonomous profiles. You can view the announce= ment at: http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/09/16/windows-az= ure-appfabric-labs-september-release-now-available.aspx -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943245A9B9ETK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wanted to let people know who may not have seen th= e announcement, that Microsoft’s Access Control Service (ACS) deploye= d OAuth 2.0 Draft 10 last month using the Web Server and Autonomous profile= s.  You can view the announcement at:

 

http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/= 09/16/windows-azure-appfabric-labs-september-release-now-available.aspx=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943245A9B9ETK5EX14MBXC207r_-- From lr@lukasrosenstock.net Fri Oct 29 04:02:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0940D3A6962 for ; Fri, 29 Oct 2010 04:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDjLV0fHLayP for ; Fri, 29 Oct 2010 04:02:47 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id CA95D3A6940 for ; Fri, 29 Oct 2010 04:02:46 -0700 (PDT) Received: by qwb7 with SMTP id 7so3116839qwb.31 for ; Fri, 29 Oct 2010 04:04:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.201.194 with SMTP id fb2mr2001443qab.7.1288350280700; Fri, 29 Oct 2010 04:04:40 -0700 (PDT) Received: by 10.229.181.213 with HTTP; Fri, 29 Oct 2010 04:04:40 -0700 (PDT) X-Originating-IP: [134.176.178.24] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Fri, 29 Oct 2010 13:04:40 +0200 Message-ID: From: Lukas Rosenstock To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" , "openid-specs-connect@lists.openid.net" Subject: Re: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 11:02:48 -0000 Hello! This draft is looking nice, the idea and specification is simple and straightforward. I would like to draw the connection to other discovery approaches. The introductory example in the draft was this one: GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&se= rvice=3Durn:adatum.com:calendar HTTP/1.1 This returns the following response: { "locations":["http://calendars.proseware.com/calendars/joseph"] } As per my understanding - please correct me if I'm wrong - this should be semantically equivalent to the following: 1) Perform host-meta discovery for example.com, which returns an XRD with the webfinger endpoint. 2) Do webfinger for joe@example.com. 3) The final XRD contains the following: [...] [...] Both approaches work, but SWD is a shortcut removes parsing requirements and fetching roundtrips from the client. Thoughts, anyone?! Regards, Lukas Rosenstock 2010/10/27 Mike Jones : > Yaron Goland and I are submitting this Simple Web Discovery (SWD) draft > (attached and at > http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) fo= r > consideration by the community to address this need.=A0 SWD is simple to > understand and implement, enables different permissions to be applied to > discovery of different services, and is JSON-based.=A0 I look forward to > discussing this with many of you next week at IIW. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike From jbradley@mac.com Fri Oct 29 03:49:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9873A6A2B for ; Fri, 29 Oct 2010 03:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+wnDa8lLExa for ; Fri, 29 Oct 2010 03:49:16 -0700 (PDT) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by core3.amsl.com (Postfix) with ESMTP id AA7893A689C for ; Fri, 29 Oct 2010 03:49:16 -0700 (PDT) MIME-version: 1.0 Received: from [192.168.1.3] (190-22-62-69.baf.movistar.cl [190.22.62.69]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LB1008Z3ST1BY70@asmtp024.mac.com> for oauth@ietf.org; Fri, 29 Oct 2010 03:51:10 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-29_06:2010-10-29, 2010-10-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010290036 Content-type: multipart/signed; boundary=Apple-Mail-455-766899986; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-reply-to: <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> Date: Thu, 28 Oct 2010 21:22:24 -0300 Message-id: References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 29 Oct 2010 05:09:37 -0700 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , the Connect work group , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 10:53:30 -0000 --Apple-Mail-455-766899986 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If there is no authorization mechanism, then this is just a JSON = version of XRD. =20 Not that you couldn't add authorization to XRD. We were planning on doing that as an option for a proxy resolution flow = that would look quite similar. The way that the existing XRI resolver works is quite similar to what = you describe filtering by service. One of the use cases has been adding authentication, but there was never = enough interest. Too bad MS didn't participate in XRD. John B. On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: > So not sure that this would be handled by the SWD itself but as = pointed out in the SWD specification is that the SWD may be accompanied = by an authorization header and this is where I would expect that to = happen >=20 > -----Original Message----- > From: openid-specs-connect-bounces@lists.openid.net = [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of John = Bradley > Sent: Thursday, October 28, 2010 8:41 AM > To: the Connect work group > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > In the case where the user logs in to a RP with a PPID type = identifier. =20 >=20 > How could the person then allow the RP to discover their service = endpoints. > Also conversely would publishing the endpoint provide a way for the RP = to correlate the user without permission. >=20 > One common practice for openID PPID is that the IdP generates the PPID = via AES128(actual ID + RP or sector identifier). >=20 > In that case the RP could do an oauth flow to the IdP discovery = endpoint to get permission to see the user endpoints. > The IdP could decrypt the opaque identifier to determine the actual = subject. >=20 > That would protect the non correlation unless the user decides to = permit discovery. >=20 > The model if not the details seem similar to some work that is being = submitted to the ITU-T as I understand it. >=20 > John B. >=20 >=20 > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: >=20 >> Sampo, can you give a usecase of how you would use the pairwise >>=20 >> -----Original Message----- >> From: openid-specs-ab-bounces@lists.openid.net=20 >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of=20 >> sampo@zxidp.org >> Sent: Tuesday, October 26, 2010 6:40 PM >> To: Mike Jones >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; = oauth@ietf.org;=20 >> openid-specs-connect@lists.openid.net >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >>=20 >> Simple enough spec. I like the notion of service type. However some = questions to answer: >>=20 >> How would one convey saml2:Assertion as the "principal"? Or how would = one convey a saml2:NameID as the "principal"? >>=20 >> Or in more generic sense, how would one convey a pairwise pseudonym = as principal? >>=20 >> Cheers, >> --Sampo >>=20 >> Mike Jones said: >>> Having a simple discovery method for services and resources is key = to enabling many Internet scenarios that require interactions among = parties that do not have pre-established relationships. For instance, = if Joe, with e-mail address joe@example.com, wants to share his calendar = with Mary, then Mary's calendar service, in the general case, will need = to discover the location of Joe's calendar service. For example, Mary's = calendar service might discover that Joe's calendar service is located = at http://calendars.proseware.com/calendar/joseph by doing discovery for = a service named urn:adatum.com:calendar at example.com for the account = joe. >>>=20 >>> Yaron Goland and I are submitting this = Simple Web Discovery = (SWD) draft (attached and at = http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) = for consideration by the community to address this need. SWD is simple = to understand and implement, enables different permissions to be applied = to discovery of different services, and is JSON-based. I look forward = to discussing this with many of you next week at = IIW. >>>=20 >>> --=20 >>> Mike >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> Openid-specs-ab mailing list >> Openid-specs-ab@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>=20 >> _______________________________________________ >> openid-specs-connect mailing list >> openid-specs-connect@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs-connect >=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --Apple-Mail-455-766899986 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEw MjkwMDIyMjVaMCMGCSqGSIb3DQEJBDEWBBTSUOadoiI+5pJtyn1+4EOyIxc/mDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQA3dQ4p3HOJHvZ6Cezv8rICReB2fBcQxudBzQRnK4GKdGAN2evQKEL3HkLwcv4BHBFpo0RF4ApB 4JocdcKjHqAb2UFibWPv7H5NojUP7kqwTxBnQYY5R4Z3Gr9KZBdETSij4WE4NxfpVicpbFpWNOtg qVyNdrzq2bJ215DSLnAFMC+XBiTABB5nsk3F2pJDODnJAxRJlgKfScvZanU6bK5VkuH78t6E8VNp 4cGb3j/T9lO/Z2MTU5ddfu+OI5gUAbHIq2E2Zyo6C/1kRIGJUoDR1ZAuNcPHGmMchB4fqY7AMb8Q jn3NtgLW6TPNawa7ByMbplwSBqW0Bs3ToWhHZivYAAAAAAAA --Apple-Mail-455-766899986-- From hank777@gmail.com Fri Oct 29 05:24:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0C53A6A62 for ; Fri, 29 Oct 2010 05:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4jZXKNeGkV3 for ; Fri, 29 Oct 2010 05:24:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4FB553A6869 for ; Fri, 29 Oct 2010 05:24:05 -0700 (PDT) Received: by wyb28 with SMTP id 28so3046824wyb.31 for ; Fri, 29 Oct 2010 05:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=icf3+ryLEJa1JNfIdLUgPcuo2MRUOfFZ7RnNxdyleaM=; b=x2hztnxQn17I0y2IWt4coOyz2KhtLaLLLlCIKQ7kYdRtXGGvW3vDofWErm1oJzZUOK cb8sURBYDpPGG+esMkRO0fyZrIKPp+4fYL/QrPPVY+txNXKnNvKyhwLYg0/w/6mY4T0K sc0GVo335loomZcwfDpDYgRJhMj5vEH2SB348= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Dblvbep8xzu2iAN4ERH2xviGdYE7aanViYN/2HViJoFrrXq41nKTn/kyI3nk7TLftt Th2UGgxVOGgxPoVE01bpvrXVVQi1bXHQLFqmsdCos0ftRYnVn/TOsSp5AVVmpnwASlni cHx5iSrqvYzM7bbwGpvbx9mj5jotc7voRQfe0= MIME-Version: 1.0 Received: by 10.216.17.135 with SMTP id j7mr3606317wej.97.1288355158868; Fri, 29 Oct 2010 05:25:58 -0700 (PDT) Received: by 10.216.156.136 with HTTP; Fri, 29 Oct 2010 05:25:58 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943245A9B9E@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943245A9B9E@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Fri, 29 Oct 2010 08:25:58 -0400 Message-ID: From: hank williams To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Microsoft Deployment of OAuth 2.0 Draft 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:24:06 -0000 Mike, Does this mean we can expect (or that it is already the case) that microsoft will support oauth 2 in its mainstream products like hotmail, mesh, etc? Hank On Thu, Oct 28, 2010 at 9:42 PM, Mike Jones w= rote: > I wanted to let people know who may not have seen the announcement, that > Microsoft=92s Access Control Service (ACS) deployed OAuth 2.0 Draft 10 la= st > month using the Web Server and Autonomous profiles.=A0 You can view the > announcement at: > > > > http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/09/16/windows-= azure-appfabric-labs-september-release-now-available.aspx > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 blog: whydoeseverythingsuck.com From tonynad@microsoft.com Fri Oct 29 08:21:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71483A6949 for ; Fri, 29 Oct 2010 08:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR4dOewwPLVI for ; Fri, 29 Oct 2010 08:21:41 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id F2AAC3A67AC for ; Fri, 29 Oct 2010 08:21:40 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Oct 2010 08:23:28 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.165]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0255.003; Fri, 29 Oct 2010 08:23:28 -0700 From: Anthony Nadalin To: hank williams , Mike Jones Thread-Topic: [OAUTH-WG] Microsoft Deployment of OAuth 2.0 Draft 10 Thread-Index: Act3CoH5s1eMz47ZS421fa+35J8WOwAlJsAAAAiMzYA= Date: Fri, 29 Oct 2010 15:23:28 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE61A08@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943245A9B9E@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Microsoft Deployment of OAuth 2.0 Draft 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:21:45 -0000 Can't really comment on product futures but Messenger Connect already has W= RAP support and ACS has Oauth 2.0 v10 support but there seems to be a trend= here=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of h= ank williams Sent: Friday, October 29, 2010 5:26 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Microsoft Deployment of OAuth 2.0 Draft 10 Mike, Does this mean we can expect (or that it is already the case) that microsof= t will support oauth 2 in its mainstream products like hotmail, mesh, etc? Hank On Thu, Oct 28, 2010 at 9:42 PM, Mike Jones w= rote: > I wanted to let people know who may not have seen the announcement,=20 > that Microsoft's Access Control Service (ACS) deployed OAuth 2.0 Draft=20 > 10 last month using the Web Server and Autonomous profiles.=A0 You can=20 > view the announcement at: > > > > http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/09/16/windo > ws-azure-appfabric-labs-september-release-now-available.aspx > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --=20 > Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- blog: whydoeseverythingsuck.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Fri Oct 29 08:55:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3815B3A6407 for ; Fri, 29 Oct 2010 08:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTPwDM3bgL-b for ; Fri, 29 Oct 2010 08:55:27 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 77CB23A63EC for ; Fri, 29 Oct 2010 08:55:27 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Oct 2010 08:57:22 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.165]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Fri, 29 Oct 2010 08:57:21 -0700 From: Anthony Nadalin To: John Bradley Thread-Topic: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery Thread-Index: AQHLdmrtt4/el9ZvDEaQ4UyC5JkUSZNWdqdggAB+4wCAABB+4IAAgTIAgACO6eA= Date: Fri, 29 Oct 2010 15:57:21 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , the Connect work group , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:55:29 -0000 I would not say that this is just a JSON version of XRD, as XRD has quite a= few more complex feature. What is being suggested here is being able to us= e OAuth for the authorization/delegation to discovery information in a very= simple chunkable forward means. -----Original Message----- From: John Bradley [mailto:jbradley@mac.com]=20 Sent: Thursday, October 28, 2010 5:22 PM To: Anthony Nadalin Cc: the Connect work group; sampo@zxidp.org; openid-specs-ab@lists.openid.n= et; oauth@ietf.org Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery If there is no authorization mechanism, then this is just a JSON version o= f XRD. =20 Not that you couldn't add authorization to XRD. We were planning on doing that as an option for a proxy resolution flow tha= t would look quite similar. The way that the existing XRI resolver works is quite similar to what you d= escribe filtering by service. One of the use cases has been adding authentication, but there was never en= ough interest. Too bad MS didn't participate in XRD. John B. On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: > So not sure that this would be handled by the SWD itself but as pointed o= ut in the SWD specification is that the SWD may be accompanied by an author= ization header and this is where I would expect that to happen >=20 > -----Original Message----- > From: openid-specs-connect-bounces@lists.openid.net [mailto:openid-specs-= connect-bounces@lists.openid.net] On Behalf Of John Bradley > Sent: Thursday, October 28, 2010 8:41 AM > To: the Connect work group > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > In the case where the user logs in to a RP with a PPID type identifier. = =20 >=20 > How could the person then allow the RP to discover their service endpoint= s. > Also conversely would publishing the endpoint provide a way for the RP to= correlate the user without permission. >=20 > One common practice for openID PPID is that the IdP generates the PPID vi= a AES128(actual ID + RP or sector identifier). >=20 > In that case the RP could do an oauth flow to the IdP discovery endpoint = to get permission to see the user endpoints. > The IdP could decrypt the opaque identifier to determine the actual subje= ct. >=20 > That would protect the non correlation unless the user decides to permit = discovery. >=20 > The model if not the details seem similar to some work that is being subm= itted to the ITU-T as I understand it. >=20 > John B. >=20 >=20 > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: >=20 >> Sampo, can you give a usecase of how you would use the pairwise >>=20 >> -----Original Message----- >> From: openid-specs-ab-bounces@lists.openid.net=20 >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of=20 >> sampo@zxidp.org >> Sent: Tuesday, October 26, 2010 6:40 PM >> To: Mike Jones >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org;=20 >> openid-specs-connect@lists.openid.net >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >>=20 >> Simple enough spec. I like the notion of service type. However some ques= tions to answer: >>=20 >> How would one convey saml2:Assertion as the "principal"? Or how would on= e convey a saml2:NameID as the "principal"? >>=20 >> Or in more generic sense, how would one convey a pairwise pseudonym as p= rincipal? >>=20 >> Cheers, >> --Sampo >>=20 >> Mike Jones said: >>> Having a simple discovery method for services and resources is key to e= nabling many Internet scenarios that require interactions among parties tha= t do not have pre-established relationships. For instance, if Joe, with e-= mail address joe@example.com, wants to share his calendar with Mary, then M= ary's calendar service, in the general case, will need to discover the loca= tion of Joe's calendar service. For example, Mary's calendar service might= discover that Joe's calendar service is located at http://calendars.prosew= are.com/calendar/joseph by doing discovery for a service named urn:adatum.c= om:calendar at example.com for the account joe. >>>=20 >>> Yaron Goland and I are submitting this Simple W= eb Discovery (SWD) draft (attached and at http://self-issued.info/docs/draft-jo= nes-simple-web-discovery-00.html) for consideration by the community to add= ress this need. SWD is simple to understand and implement, enables differe= nt permissions to be applied to discovery of different services, and is JSO= N-based. I look forward to discussing this with many of you next week at I= IW. >>>=20 >>> --=20 >>> Mike >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> Openid-specs-ab mailing list >> Openid-specs-ab@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>=20 >> _______________________________________________ >> openid-specs-connect mailing list >> openid-specs-connect@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs-connect >=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab From ve7jtb@ve7jtb.com Fri Oct 29 09:11:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A983E3A6405 for ; Fri, 29 Oct 2010 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9tE-rMEQR+k for ; Fri, 29 Oct 2010 09:11:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EFC203A67A7 for ; Fri, 29 Oct 2010 09:11:32 -0700 (PDT) Received: by gya6 with SMTP id 6so2233077gya.31 for ; Fri, 29 Oct 2010 09:13:26 -0700 (PDT) Received: by 10.151.147.19 with SMTP id z19mr22436860ybn.150.1288368806521; Fri, 29 Oct 2010 09:13:26 -0700 (PDT) Received: from [192.168.1.3] ([190.22.62.69]) by mx.google.com with ESMTPS id q14sm1836500ybk.7.2010.10.29.09.13.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 09:13:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-521-823955578; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> Date: Fri, 29 Oct 2010 13:13:20 -0300 Message-Id: <7FE3A664-3BC4-44E6-ACF6-AF9E4754A4D1@ve7jtb.com> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1081) Cc: sampo@zxidp.org, openid-specs-ab@lists.openid.net, oauth@ietf.org, the Connect work group Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:11:49 -0000 --Apple-Mail-521-823955578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am agreeing using oAuth in that way is a good idea. It has been = discussed various places. I think Eve's UMA group is looking at some = options for that. You could however do the same thing with WebFinger/XRD. It would have been better to have worked on this together over the last = year and a half. However we are where we are and we need to look at it as a legitimate = proposal. However it will be up against other similar work in the community. John B. On 2010-10-29, at 12:57 PM, Anthony Nadalin wrote: > I would not say that this is just a JSON version of XRD, as XRD has = quite a few more complex feature. What is being suggested here is being = able to use OAuth for the authorization/delegation to discovery = information in a very simple chunkable forward means. >=20 > -----Original Message----- > From: John Bradley [mailto:jbradley@mac.com]=20 > Sent: Thursday, October 28, 2010 5:22 PM > To: Anthony Nadalin > Cc: the Connect work group; sampo@zxidp.org; = openid-specs-ab@lists.openid.net; oauth@ietf.org > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > If there is no authorization mechanism, then this is just a JSON = version of XRD. =20 >=20 > Not that you couldn't add authorization to XRD. >=20 > We were planning on doing that as an option for a proxy resolution = flow that would look quite similar. >=20 > The way that the existing XRI resolver works is quite similar to what = you describe filtering by service. > One of the use cases has been adding authentication, but there was = never enough interest. >=20 > Too bad MS didn't participate in XRD. >=20 > John B. > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: >=20 >> So not sure that this would be handled by the SWD itself but as = pointed out in the SWD specification is that the SWD may be accompanied = by an authorization header and this is where I would expect that to = happen >>=20 >> -----Original Message----- >> From: openid-specs-connect-bounces@lists.openid.net = [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of John = Bradley >> Sent: Thursday, October 28, 2010 8:41 AM >> To: the Connect work group >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >>=20 >> In the case where the user logs in to a RP with a PPID type = identifier. =20 >>=20 >> How could the person then allow the RP to discover their service = endpoints. >> Also conversely would publishing the endpoint provide a way for the = RP to correlate the user without permission. >>=20 >> One common practice for openID PPID is that the IdP generates the = PPID via AES128(actual ID + RP or sector identifier). >>=20 >> In that case the RP could do an oauth flow to the IdP discovery = endpoint to get permission to see the user endpoints. >> The IdP could decrypt the opaque identifier to determine the actual = subject. >>=20 >> That would protect the non correlation unless the user decides to = permit discovery. >>=20 >> The model if not the details seem similar to some work that is being = submitted to the ITU-T as I understand it. >>=20 >> John B. >>=20 >>=20 >> On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: >>=20 >>> Sampo, can you give a usecase of how you would use the pairwise >>>=20 >>> -----Original Message----- >>> From: openid-specs-ab-bounces@lists.openid.net=20 >>> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of=20 >>> sampo@zxidp.org >>> Sent: Tuesday, October 26, 2010 6:40 PM >>> To: Mike Jones >>> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; = oauth@ietf.org;=20 >>> openid-specs-connect@lists.openid.net >>> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >>>=20 >>> Simple enough spec. I like the notion of service type. However some = questions to answer: >>>=20 >>> How would one convey saml2:Assertion as the "principal"? Or how = would one convey a saml2:NameID as the "principal"? >>>=20 >>> Or in more generic sense, how would one convey a pairwise pseudonym = as principal? >>>=20 >>> Cheers, >>> --Sampo >>>=20 >>> Mike Jones said: >>>> Having a simple discovery method for services and resources is key = to enabling many Internet scenarios that require interactions among = parties that do not have pre-established relationships. For instance, = if Joe, with e-mail address joe@example.com, wants to share his calendar = with Mary, then Mary's calendar service, in the general case, will need = to discover the location of Joe's calendar service. For example, Mary's = calendar service might discover that Joe's calendar service is located = at http://calendars.proseware.com/calendar/joseph by doing discovery for = a service named urn:adatum.com:calendar at example.com for the account = joe. >>>>=20 >>>> Yaron Goland and I are submitting this = Simple Web Discovery = (SWD) draft (attached and at = http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) = for consideration by the community to address this need. SWD is simple = to understand and implement, enables different permissions to be applied = to discovery of different services, and is JSON-based. I look forward = to discussing this with many of you next week at = IIW. >>>>=20 >>>> --=20 >>>> Mike >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>> _______________________________________________ >>> Openid-specs-ab mailing list >>> Openid-specs-ab@lists.openid.net >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>>=20 >>> _______________________________________________ >>> openid-specs-connect mailing list >>> openid-specs-connect@lists.openid.net >>> http://lists.openid.net/mailman/listinfo/openid-specs-connect >>=20 >> _______________________________________________ >> Openid-specs-ab mailing list >> Openid-specs-ab@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > _______________________________________________ > openid-specs-connect mailing list > openid-specs-connect@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-connect --Apple-Mail-521-823955578 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEw MjkxNjEzMjFaMCMGCSqGSIb3DQEJBDEWBBQqOF59x5R+cRfxZgJ/oON48wNJ6jCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAF0ForSMK7XdySfu89qQGWRXMpoLNZFc3gfg8ef13buaXcN5lA81TZC9yoNhwue3ga2VWpxQuf EioREcGfEz4OEJxcy+jKQJAA5JpztDkytS7HEg1hRkZnGK9nFlG4riKg3ZI+jezPYWx+nJ6Pomkk 9i/Qg087owO+Ubm9m4hCli8dwCbGZknyFhHaIytGKMdNeIDvNDHhmIzPMD7VU8W8sZufxVGoSDcE IzUjt74eM1yKyBrUckBB2Udddo2ojdXXyoSyjsvjutFAVDAyQh95dhIaEYkCk416V+WITEyEgiSm PRY58MCvMcGEzrvEzdGHtIsGVwyPFgALMx8HDeKnAAAAAAAA --Apple-Mail-521-823955578-- From eran@hueniverse.com Fri Oct 29 09:23:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35923A67AF for ; Fri, 29 Oct 2010 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9skzgcHUIob for ; Fri, 29 Oct 2010 09:23:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 370D33A67CF for ; Fri, 29 Oct 2010 09:23:24 -0700 (PDT) Received: (qmail 17739 invoked from network); 29 Oct 2010 16:25:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Oct 2010 16:25:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 29 Oct 2010 09:24:38 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , John Bradley Date: Fri, 29 Oct 2010 09:24:23 -0700 Thread-Topic: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery Thread-Index: AQHLdmrtt4/el9ZvDEaQ4UyC5JkUSZNWdqdggAB+4wCAABB+4IAAgTIAgACO6eCAAAeMoA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D46D80E92@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , the Connect work group , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:23:28 -0000 Can you list those "quite a few more complex feature"? XRD (and JRD) were carefully balanced over 3 years to produce a simple spec= ification that covers basic discovery needs without any unnecessary complex= ity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts, and succ= essfully adopted by new lightweight protocols. To invent yet another format= that is clearly overlapping without even trying to engage in the XRD/JRD w= ork is poor community participation. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Friday, October 29, 2010 8:57 AM > To: John Bradley > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work > group; oauth@ietf.org > Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery >=20 > I would not say that this is just a JSON version of XRD, as XRD has quite= a few > more complex feature. What is being suggested here is being able to use > OAuth for the authorization/delegation to discovery information in a very > simple chunkable forward means. >=20 > -----Original Message----- > From: John Bradley [mailto:jbradley@mac.com] > Sent: Thursday, October 28, 2010 5:22 PM > To: Anthony Nadalin > Cc: the Connect work group; sampo@zxidp.org; openid-specs- > ab@lists.openid.net; oauth@ietf.org > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > If there is no authorization mechanism, then this is just a JSON version= of > XRD. >=20 > Not that you couldn't add authorization to XRD. >=20 > We were planning on doing that as an option for a proxy resolution flow t= hat > would look quite similar. >=20 > The way that the existing XRI resolver works is quite similar to what you > describe filtering by service. > One of the use cases has been adding authentication, but there was never > enough interest. >=20 > Too bad MS didn't participate in XRD. >=20 > John B. > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: >=20 > > So not sure that this would be handled by the SWD itself but as > > pointed out in the SWD specification is that the SWD may be > > accompanied by an authorization header and this is where I would > > expect that to happen > > > > -----Original Message----- > > From: openid-specs-connect-bounces@lists.openid.net > > [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of > > John Bradley > > Sent: Thursday, October 28, 2010 8:41 AM > > To: the Connect work group > > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; oauth@ietf.org > > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > > > In the case where the user logs in to a RP with a PPID type identifier. > > > > How could the person then allow the RP to discover their service > endpoints. > > Also conversely would publishing the endpoint provide a way for the RP = to > correlate the user without permission. > > > > One common practice for openID PPID is that the IdP generates the PPID > via AES128(actual ID + RP or sector identifier). > > > > In that case the RP could do an oauth flow to the IdP discovery endpoin= t to > get permission to see the user endpoints. > > The IdP could decrypt the opaque identifier to determine the actual > subject. > > > > That would protect the non correlation unless the user decides to permi= t > discovery. > > > > The model if not the details seem similar to some work that is being > submitted to the ITU-T as I understand it. > > > > John B. > > > > > > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: > > > >> Sampo, can you give a usecase of how you would use the pairwise > >> > >> -----Original Message----- > >> From: openid-specs-ab-bounces@lists.openid.net > >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of > >> sampo@zxidp.org > >> Sent: Tuesday, October 26, 2010 6:40 PM > >> To: Mike Jones > >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; > >> oauth@ietf.org; openid-specs-connect@lists.openid.net > >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > >> > >> Simple enough spec. I like the notion of service type. However some > questions to answer: > >> > >> How would one convey saml2:Assertion as the "principal"? Or how would > one convey a saml2:NameID as the "principal"? > >> > >> Or in more generic sense, how would one convey a pairwise pseudonym > as principal? > >> > >> Cheers, > >> --Sampo > >> > >> Mike Jones said: > >>> Having a simple discovery method for services and resources is key to > enabling many Internet scenarios that require interactions among parties > that do not have pre-established relationships. For instance, if Joe, wi= th e- > mail address joe@example.com, wants to share his calendar with Mary, then > Mary's calendar service, in the general case, will need to discover the l= ocation > of Joe's calendar service. For example, Mary's calendar service might > discover that Joe's calendar service is located at > http://calendars.proseware.com/calendar/joseph by doing discovery for a > service named urn:adatum.com:calendar at example.com for the account > joe. > >>> > >>> Yaron Goland and I are submitting this Simple > Web Discovery (SWD) discovery-00.html> draft (attached and at http://self-issued.info/docs/dr= aft- > jones-simple-web-discovery-00.html) for consideration by the community to > address this need. SWD is simple to understand and implement, enables > different permissions to be applied to discovery of different services, a= nd is > JSON-based. I look forward to discussing this with many of you next week= at > IIW view/>. > >>> > >>> -- > >>> Mike > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> _______________________________________________ > >> Openid-specs-ab mailing list > >> Openid-specs-ab@lists.openid.net > >> http://lists.openid.net/mailman/listinfo/openid-specs-ab > >> > >> _______________________________________________ > >> openid-specs-connect mailing list > >> openid-specs-connect@lists.openid.net > >> http://lists.openid.net/mailman/listinfo/openid-specs-connect > > > > _______________________________________________ > > Openid-specs-ab mailing list > > Openid-specs-ab@lists.openid.net > > http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Fri Oct 29 09:35:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF953A67DB for ; Fri, 29 Oct 2010 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkpGnYngJ8MK for ; Fri, 29 Oct 2010 09:35:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9892A3A67AD for ; Fri, 29 Oct 2010 09:35:19 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Oct 2010 09:37:05 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.165]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0255.003; Fri, 29 Oct 2010 09:37:05 -0700 From: Anthony Nadalin To: Eran Hammer-Lahav , John Bradley Thread-Topic: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery Thread-Index: AQHLd4bhFCHF/EU1cEGyKlQi5dXrcJNYH+iw Date: Fri, 29 Oct 2010 16:37:03 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FE63CA7@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D46D80E92@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D46D80E92@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , the Connect work group , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:35:24 -0000 Like an XML parser -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Friday, October 29, 2010 9:24 AM To: Anthony Nadalin; John Bradley Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work gro= up; oauth@ietf.org Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery Can you list those "quite a few more complex feature"? XRD (and JRD) were carefully balanced over 3 years to produce a simple spec= ification that covers basic discovery needs without any unnecessary complex= ity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts, and succ= essfully adopted by new lightweight protocols. To invent yet another format= that is clearly overlapping without even trying to engage in the XRD/JRD w= ork is poor community participation. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Anthony Nadalin > Sent: Friday, October 29, 2010 8:57 AM > To: John Bradley > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect=20 > work group; oauth@ietf.org > Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery >=20 > I would not say that this is just a JSON version of XRD, as XRD has=20 > quite a few more complex feature. What is being suggested here is=20 > being able to use OAuth for the authorization/delegation to discovery=20 > information in a very simple chunkable forward means. >=20 > -----Original Message----- > From: John Bradley [mailto:jbradley@mac.com] > Sent: Thursday, October 28, 2010 5:22 PM > To: Anthony Nadalin > Cc: the Connect work group; sampo@zxidp.org; openid-specs-=20 > ab@lists.openid.net; oauth@ietf.org > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery >=20 > If there is no authorization mechanism, then this is just a JSON=20 > version of XRD. >=20 > Not that you couldn't add authorization to XRD. >=20 > We were planning on doing that as an option for a proxy resolution=20 > flow that would look quite similar. >=20 > The way that the existing XRI resolver works is quite similar to what=20 > you describe filtering by service. > One of the use cases has been adding authentication, but there was=20 > never enough interest. >=20 > Too bad MS didn't participate in XRD. >=20 > John B. > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: >=20 > > So not sure that this would be handled by the SWD itself but as=20 > > pointed out in the SWD specification is that the SWD may be=20 > > accompanied by an authorization header and this is where I would=20 > > expect that to happen > > > > -----Original Message----- > > From: openid-specs-connect-bounces@lists.openid.net > > [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of=20 > > John Bradley > > Sent: Thursday, October 28, 2010 8:41 AM > > To: the Connect work group > > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net;=20 > > oauth@ietf.org > > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > > > In the case where the user logs in to a RP with a PPID type identifier. > > > > How could the person then allow the RP to discover their service > endpoints. > > Also conversely would publishing the endpoint provide a way for the=20 > > RP to > correlate the user without permission. > > > > One common practice for openID PPID is that the IdP generates the=20 > > PPID > via AES128(actual ID + RP or sector identifier). > > > > In that case the RP could do an oauth flow to the IdP discovery=20 > > endpoint to > get permission to see the user endpoints. > > The IdP could decrypt the opaque identifier to determine the actual > subject. > > > > That would protect the non correlation unless the user decides to=20 > > permit > discovery. > > > > The model if not the details seem similar to some work that is being > submitted to the ITU-T as I understand it. > > > > John B. > > > > > > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: > > > >> Sampo, can you give a usecase of how you would use the pairwise > >> > >> -----Original Message----- > >> From: openid-specs-ab-bounces@lists.openid.net > >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of=20 > >> sampo@zxidp.org > >> Sent: Tuesday, October 26, 2010 6:40 PM > >> To: Mike Jones > >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net;=20 > >> oauth@ietf.org; openid-specs-connect@lists.openid.net > >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > >> > >> Simple enough spec. I like the notion of service type. However some > questions to answer: > >> > >> How would one convey saml2:Assertion as the "principal"? Or how=20 > >> would > one convey a saml2:NameID as the "principal"? > >> > >> Or in more generic sense, how would one convey a pairwise pseudonym > as principal? > >> > >> Cheers, > >> --Sampo > >> > >> Mike Jones said: > >>> Having a simple discovery method for services and resources is key=20 > >>> to > enabling many Internet scenarios that require interactions among=20 > parties that do not have pre-established relationships. For instance,=20 > if Joe, with e- mail address joe@example.com, wants to share his=20 > calendar with Mary, then Mary's calendar service, in the general case,=20 > will need to discover the location of Joe's calendar service. For=20 > example, Mary's calendar service might discover that Joe's calendar=20 > service is located at http://calendars.proseware.com/calendar/joseph=20 > by doing discovery for a service named urn:adatum.com:calendar at=20 > example.com for the account joe. > >>> > >>> Yaron Goland and I are submitting this=20 > >>> Simple > Web Discovery=20 > (SWD) discovery-00.html> draft (attached and at=20 > http://self-issued.info/docs/draft- > jones-simple-web-discovery-00.html) for consideration by the community=20 > to address this need. SWD is simple to understand and implement,=20 > enables different permissions to be applied to discovery of different=20 > services, and is JSON-based. I look forward to discussing this with=20 > many of you next week at > IIW view/>. > >>> > >>> --=20 > >>> Mike > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> _______________________________________________ > >> Openid-specs-ab mailing list > >> Openid-specs-ab@lists.openid.net > >> http://lists.openid.net/mailman/listinfo/openid-specs-ab > >> > >> _______________________________________________ > >> openid-specs-connect mailing list > >> openid-specs-connect@lists.openid.net > >> http://lists.openid.net/mailman/listinfo/openid-specs-connect > > > > _______________________________________________ > > Openid-specs-ab mailing list > > Openid-specs-ab@lists.openid.net > > http://lists.openid.net/mailman/listinfo/openid-specs-ab >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Oct 29 09:40:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97F13A67F3 for ; Fri, 29 Oct 2010 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq6EwZ+0zZwC for ; Fri, 29 Oct 2010 09:40:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 854783A65A5 for ; Fri, 29 Oct 2010 09:39:42 -0700 (PDT) Received: (qmail 31330 invoked from network); 29 Oct 2010 16:41:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Oct 2010 16:41:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 29 Oct 2010 09:40:50 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , John Bradley Date: Fri, 29 Oct 2010 09:40:35 -0700 Thread-Topic: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery Thread-Index: AQHLd4bhFCHF/EU1cEGyKlQi5dXrcJNYH+iwgAAAhwA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D46D80E9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D46D80E92@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18FE63CA7@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18FE63CA7@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sampo@zxidp.org" , "openid-specs-ab@lists.openid.net" , the Connect work group , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:40:55 -0000 JRD does not require an XML parser. If you want to talk about simplicity, "= engage" is simpler than "reinvent". EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Friday, October 29, 2010 9:37 AM > To: Eran Hammer-Lahav; John Bradley > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work > group; oauth@ietf.org > Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery >=20 > Like an XML parser >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Friday, October 29, 2010 9:24 AM > To: Anthony Nadalin; John Bradley > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work > group; oauth@ietf.org > Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery >=20 > Can you list those "quite a few more complex feature"? >=20 > XRD (and JRD) were carefully balanced over 3 years to produce a simple > specification that covers basic discovery needs without any unnecessary > complexity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts, > and successfully adopted by new lightweight protocols. To invent yet > another format that is clearly overlapping without even trying to engage = in > the XRD/JRD work is poor community participation. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Anthony Nadalin > > Sent: Friday, October 29, 2010 8:57 AM > > To: John Bradley > > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect > > work group; oauth@ietf.org > > Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery > > > > I would not say that this is just a JSON version of XRD, as XRD has > > quite a few more complex feature. What is being suggested here is > > being able to use OAuth for the authorization/delegation to discovery > > information in a very simple chunkable forward means. > > > > -----Original Message----- > > From: John Bradley [mailto:jbradley@mac.com] > > Sent: Thursday, October 28, 2010 5:22 PM > > To: Anthony Nadalin > > Cc: the Connect work group; sampo@zxidp.org; openid-specs- > > ab@lists.openid.net; oauth@ietf.org > > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > > > If there is no authorization mechanism, then this is just a JSON > > version of XRD. > > > > Not that you couldn't add authorization to XRD. > > > > We were planning on doing that as an option for a proxy resolution > > flow that would look quite similar. > > > > The way that the existing XRI resolver works is quite similar to what > > you describe filtering by service. > > One of the use cases has been adding authentication, but there was > > never enough interest. > > > > Too bad MS didn't participate in XRD. > > > > John B. > > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote: > > > > > So not sure that this would be handled by the SWD itself but as > > > pointed out in the SWD specification is that the SWD may be > > > accompanied by an authorization header and this is where I would > > > expect that to happen > > > > > > -----Original Message----- > > > From: openid-specs-connect-bounces@lists.openid.net > > > [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of > > > John Bradley > > > Sent: Thursday, October 28, 2010 8:41 AM > > > To: the Connect work group > > > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; > > > oauth@ietf.org > > > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > > > > > In the case where the user logs in to a RP with a PPID type identifie= r. > > > > > > How could the person then allow the RP to discover their service > > endpoints. > > > Also conversely would publishing the endpoint provide a way for the > > > RP to > > correlate the user without permission. > > > > > > One common practice for openID PPID is that the IdP generates the > > > PPID > > via AES128(actual ID + RP or sector identifier). > > > > > > In that case the RP could do an oauth flow to the IdP discovery > > > endpoint to > > get permission to see the user endpoints. > > > The IdP could decrypt the opaque identifier to determine the actual > > subject. > > > > > > That would protect the non correlation unless the user decides to > > > permit > > discovery. > > > > > > The model if not the details seem similar to some work that is being > > submitted to the ITU-T as I understand it. > > > > > > John B. > > > > > > > > > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote: > > > > > >> Sampo, can you give a usecase of how you would use the pairwise > > >> > > >> -----Original Message----- > > >> From: openid-specs-ab-bounces@lists.openid.net > > >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of > > >> sampo@zxidp.org > > >> Sent: Tuesday, October 26, 2010 6:40 PM > > >> To: Mike Jones > > >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; > > >> oauth@ietf.org; openid-specs-connect@lists.openid.net > > >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery > > >> > > >> Simple enough spec. I like the notion of service type. However some > > questions to answer: > > >> > > >> How would one convey saml2:Assertion as the "principal"? Or how > > >> would > > one convey a saml2:NameID as the "principal"? > > >> > > >> Or in more generic sense, how would one convey a pairwise > pseudonym > > as principal? > > >> > > >> Cheers, > > >> --Sampo > > >> > > >> Mike Jones said: > > >>> Having a simple discovery method for services and resources is key > > >>> to > > enabling many Internet scenarios that require interactions among > > parties that do not have pre-established relationships. For instance, > > if Joe, with e- mail address joe@example.com, wants to share his > > calendar with Mary, then Mary's calendar service, in the general case, > > will need to discover the location of Joe's calendar service. For > > example, Mary's calendar service might discover that Joe's calendar > > service is located at http://calendars.proseware.com/calendar/joseph > > by doing discovery for a service named urn:adatum.com:calendar at > > example.com for the account joe. > > >>> > > >>> Yaron Goland and I are submitting this > > >>> Simple > > Web Discovery > > (SWD) > discovery-00.html> draft (attached and at > > http://self-issued.info/docs/draft- > > jones-simple-web-discovery-00.html) for consideration by the community > > to address this need. SWD is simple to understand and implement, > > enables different permissions to be applied to discovery of different > > services, and is JSON-based. I look forward to discussing this with > > many of you next week at > > IIW > view/>. > > >>> > > >>> -- > > >>> Mike > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >> _______________________________________________ > > >> Openid-specs-ab mailing list > > >> Openid-specs-ab@lists.openid.net > > >> http://lists.openid.net/mailman/listinfo/openid-specs-ab > > >> > > >> _______________________________________________ > > >> openid-specs-connect mailing list > > >> openid-specs-connect@lists.openid.net > > >> http://lists.openid.net/mailman/listinfo/openid-specs-connect > > > > > > _______________________________________________ > > > Openid-specs-ab mailing list > > > Openid-specs-ab@lists.openid.net > > > http://lists.openid.net/mailman/listinfo/openid-specs-ab > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Fri Oct 29 11:33:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B8E3A6A51 for ; Fri, 29 Oct 2010 11:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQHipBYO53TS for ; Fri, 29 Oct 2010 11:33:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B57313A6A43 for ; Fri, 29 Oct 2010 11:33:37 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o9TIZV55001453 for ; Fri, 29 Oct 2010 11:35:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288377331; bh=VNGuYyfAAUU+H1F3mUvuBsDAmWM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZQJEzkeas8nAj65zB+bisFar5yIrf/xIAtc8Sky9qPxVlKWez8EmAQIa/9T2yG5dL jBfSo9Ydw0WpxAakKiSJQ== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by wpaz5.hot.corp.google.com with ESMTP id o9TIZTc6008192 for ; Fri, 29 Oct 2010 11:35:30 -0700 Received: by pzk30 with SMTP id 30so158737pzk.28 for ; Fri, 29 Oct 2010 11:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=rNCIlHbD6EgPz1b9eDhbOqfjbSRA9aswFRr302sN9Ss=; b=p0+ohQpK27naZIvTrWcj8Xaq9JDsNMNXur1CCmZvijZn1L3E+ngJR/DwLm6srZ7F5A +GfiAdYG+rJHWjE9vEMg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=wjfE9wlz3X8fREa+tMVpT+xwxA7hTrt/qLDnDWLn6u8l81JuGzQhOmhZYHqB6Xk2KB 5aCwdElov51vHiYbkj3Q== Received: by 10.142.154.5 with SMTP id b5mr1765752wfe.439.1288377328943; Fri, 29 Oct 2010 11:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.185.6 with HTTP; Fri, 29 Oct 2010 11:35:08 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> From: John Panzer Date: Fri, 29 Oct 2010 11:35:08 -0700 Message-ID: To: Lukas Rosenstock , "webfinger@googlegroups.com" Content-Type: multipart/alternative; boundary=000e0cd2e4380744290493c5b95b X-System-Of-Record: true Cc: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" , "openid-specs-connect@lists.openid.net" Subject: Re: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:33:41 -0000 --000e0cd2e4380744290493c5b95b Content-Type: text/plain; charset=ISO-8859-1 I think that it would be good to have a writeup like this that describes the differences and pros and cons of each approach. Perhaps on a Wiki page? Some random thoughts: One thing: host-meta is highly cacheable, so the # of round trips will hopefully be comparable for large services with significant traffic. In fact the user XRD is also cacheable as well so there can be zero round trips. This proposal defines a mechanism separate from HTTP caching in order to cache responses, it'd be good to have a rationale for doing that (and to have an explanation of how this should interact with additional HTTP level caching.) This mechanism appears to require multiple round trips to a server if you want to discover multiple services. This proposal seems to require that the /well-known provider run a significant service on their endpoint, as opposed to just dropping a file in place. I think that the forwarding mechanism may be a way around that? How would I hook into this mechanism if I really only can drop static files on my web server, but I can perhaps use cloud services that I've registered with to actually power the discovery? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock wrote: > Hello! > This draft is looking nice, the idea and specification is simple and > straightforward. I would like to draw the connection to other > discovery approaches. > > The introductory example in the draft was this one: > GET /.well-known/simple-web-discovery?principal=mailto:joe@example.com > &service=urn:adatum.com:calendar > HTTP/1.1 > > This returns the following response: > { > "locations":["http://calendars.proseware.com/calendars/joseph"] > } > > As per my understanding - please correct me if I'm wrong - this should > be semantically equivalent to the following: > 1) Perform host-meta discovery for example.com, which returns an XRD > with the webfinger endpoint. > 2) Do webfinger for joe@example.com. > 3) The final XRD contains the following: > > [...] > href="http://calendars.proseware.com/calendars/joseph" /> > [...] > > > Both approaches work, but SWD is a shortcut removes parsing > requirements and fetching roundtrips from the client. > > Thoughts, anyone?! > > Regards, > Lukas Rosenstock > > 2010/10/27 Mike Jones : > > Yaron Goland and I are submitting this Simple Web Discovery (SWD) draft > > (attached and at > > http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) > for > > consideration by the community to address this need. SWD is simple to > > understand and implement, enables different permissions to be applied to > > discovery of different services, and is JSON-based. I look forward to > > discussing this with many of you next week at IIW. > > > > > > > > -- Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd2e4380744290493c5b95b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that it would be good to have a writeup like this that describes th= e differences and pros and cons of each approach. Perhaps on a Wiki page?
Some random thoughts:

One thing:= =A0host-meta is highly cacheable, so the # of round trips will hopefully b= e comparable for large services with significant traffic. =A0In fact the us= er XRD is also cacheable as well so there can be zero round trips. =A0This = proposal defines a mechanism separate from HTTP caching in order to cache r= esponses, it'd be good to have a rationale for doing that (and to have = an explanation of how this should interact with additional HTTP level cachi= ng.)

This mechanism appears to require multiple round trips = to a server if you want to discover multiple services. =A0

This proposal seems to require that the /well-known provider run a= significant service on their endpoint, as opposed to just dropping a file = in place. =A0I think that the forwarding mechanism may be a way around that= ? =A0How would I hook into this mechanism if I really only can drop static = files on my web server, but I can perhaps use cloud services that I've = registered with to actually power the discovery?

--
John Panzer / Googlejpanzer@google.co= m / abstra= ctioneer.org / @jpanzer



On Fri, Oct 29, 2010 at 4:04 AM, Lukas R= osenstock <lr@lukasrosenstock.net> wrote:
Hello!
This draft is looking nice, the idea and specification is simple and
straightforward. I would like to draw the connection to other
discovery approaches.

The introductory example in the draft was this one:
GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&service=3Durn:ad= atum.com:calendar
HTTP/1.1

This returns the following response:
{
=A0"locations":["http://calendars.proseware.com/calendars= /joseph"]
}

As per my understanding - please correct me if I'm wrong - this should<= br> be semantically equivalent to the following:
1) Perform host-meta discovery for example.com, which returns an XRD
with the webfinger endpoint.
2) Do webfinger for jo= e@example.com.
3) The final XRD contains the following:
<XRD>
[...]
<Link rel=3D"urn:adatum.com:calendar"
href=3D"http://calendars.proseware.com/calendars/joseph" /= >
[...]
</XRD>

Both approaches work, but SWD is a shortcut removes parsing
requirements and fetching roundtrips from the client.

Thoughts, anyone?!

Regards,
=A0Lukas Rosenstock

2010/10/27 Mike Jones <Michael.Jones@microsoft.com>:
> Yaron Goland and I are submitting this Simple Web Discovery (SWD)= draft
> (attached and at
> http://self-issued.info/docs/draft-jones-simp= le-web-discovery-00.html) for
> consideration by the community to address this need.=A0 SWD is simple = to
> understand and implement, enables different permissions to be applied = to
> discovery of different services, and is JSON-based.=A0 I look forward = to
> discussing this with many of you next week at IIW.
>
>
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
_______________________________________________<= br> OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd2e4380744290493c5b95b-- From jricher@mitre.org Fri Oct 29 14:53:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8063A68F0 for ; Fri, 29 Oct 2010 14:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVxnIVFjfx8A for ; Fri, 29 Oct 2010 14:52:54 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 19D003A6853 for ; Fri, 29 Oct 2010 14:52:54 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9TLsm1a026768 for ; Fri, 29 Oct 2010 17:54:48 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9TLsmh7026762 for ; Fri, 29 Oct 2010 17:54:48 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 29 Oct 2010 17:54:47 -0400 From: Justin Richer To: "oauth@ietf.org" Content-Type: multipart/mixed; boundary="=-2QXRbFk+qbREQG9DBlzt" Date: Fri, 29 Oct 2010 17:54:47 -0400 Message-ID: <1288389287.13322.18.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Subject: [OAUTH-WG] Draft Extension: XML Encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:53:00 -0000 --=-2QXRbFk+qbREQG9DBlzt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit The IETF I-D submission is closed at the moment, so I'm attaching a draft extension to this email for now. It is my intention for this to become a working group item, and am looking forward to discussing this at IIW. -- Justin PS: This and the instance draft are my first time using the RFC formats, so I'll gladly take advice and help in getting these correct. --=-2QXRbFk+qbREQG9DBlzt Content-Disposition: attachment; filename="draft-richer-oauth-xml-01.html" Content-Type: text/html; name="draft-richer-oauth-xml-01.html"; charset="UTF-8" Content-Transfer-Encoding: 8bit XML Encoding for OAuth 2
 TOC 
Network Working GroupJ. Richer, Ed.
Internet-DraftThe MITRE Corporation
Intended status: ExperimentalOctober 7, 2010
Expires: April 10, 2011 


XML Encoding for OAuth 2
draft-richer-oauth-xml-00

Abstract

This document describes a method of translating JSON structured values to XML structured values in the context of the OAuth 2 protocol.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 10, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1.  Introduction
2.  Transport
3.  Encoding
    3.1.  Objects and Members
    3.2.  Root Element
    3.3.  Type Identifiers
    3.4.  Strings and Numbers
    3.5.  Arrays
    3.6.  Namespace
4.  Examples
    4.1.  Standard OAuth Token
    4.2.  Extensions
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  Normative References
§  Author's Address



 TOC 

1.  Introduction

The OAuth 2 Protocol (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” July 2010.) [I‑D.ietf‑oauth‑v2] makes use of JSON (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627] encoding for its structured return values, as defined by section 4.2 of the OAuth specification. JSON encoding is not always desirable, particularly when OAuth is being used as part of an XML (Cowan, J., “Extensible Markup Language (XML) 1.1,” October 2002.) [W3C.CR‑xml11‑20021015] stream. This extension describes a method for the token endpoint to encode its return values as XML documents as opposed to JSON objects.


 TOC 

2.  Transport

To select XML encoding, the client sends the following OPTIONAL parameter

format
OPTIONAL. The format parameter specifies the client's desired format for responses from the token endpoint. Valid values are "json" and "xml". If omitted, the parameter value defaults to "json".

The server SHALL respond to a valid access grant containing an XML format request with an HTTP 200 response and content type of application/xml.


 TOC 

3.  Encoding

This section defines encodings for different parts of the JSON data model in XML equivalents.


 TOC 

3.1.  Objects and Members

JSON objects SHALL be encoded by using XML Elements. The object itself SHALL be represented by the root elment of an XML subtree. All members of the object SHALL be represented by sub-elements of the root element. The key of the member pair SHALL be the node name of the XML Element, and the value of the member pair SHALL be encoded as the content of the XML Element. The root element of the overall JSON object


 TOC 

3.2.  Root Element

The token endpoint SHALL use the root element with a node name oauth to represent the anonymous root JSON object specified in the OAuth specification.


 TOC 

3.3.  Type Identifiers

All elements MAY have an OPTIONAL "type" attribute, which has a valid value of "object", "string", "number", or "array".


 TOC 

3.4.  Strings and Numbers

Strings and numbers SHALL be encoded as CDATA within their enclosing element. These values MUST be properly escaped XML CDATA, and MAY be represented using the <[CDATA[ ... ]]> encoding.


 TOC 

3.5.  Arrays

Arrays SHALL be represented using repeated, sibling XML Element nodes (nodes with the same node name). The order of the array is encoded using document order of the array elements. Note that there is no viable distinction between a single-element list and a raw value using this encoding.


 TOC 

3.6.  Namespace

This extension does not define a required namespace for the OAuth XML encoding.


 TOC 

4.  Examples

Below are examples of encoding different OAuth JSON objects with XML.


 TOC 

4.1.  Standard OAuth Token

A standard OAuth JSON-encoded token response: 

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
    "access_token":"SlAV32hkKG",
    "expires_in":3600,
    "refresh_token":"8xLOxBtZp8"
  }

Can be encoded in as the following XML response document: 

  HTTP/1.1 200 OK
  Content-Type: application/xml
  Cache-Control: no-store

  <oauth>
    <access_token>SlAV32hkKG</access_token>
    <expires_in>3600</expires_in>
    <refresh_token>8xLOxBtZp8</refresh_token>
  </oauth>

Or, with optional type attributes (Type Identifiers) in place: 

  HTTP/1.1 200 OK
  Content-Type: application/xml
  Cache-Control: no-store

  <oauth type="object">
    <access_token type="string">SlAV32hkKG</access_token>
    <expires_in type="number">3600</expires_in>
    <refresh_token type="string">8xLOxBtZp8</refresh_token>
  </oauth>

 TOC 

4.2.  Extensions

Extensions to the OAuth protocol could make use of JSON's extensible data representation capabilities, including both objects and arrays. Using the encoding rules (Encoding) recursively, one can represent the same structures in XML.

This example uses both objects and arrays to support a complicated, fictional example extension to the OAuth protocol: 

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
    "access_token":"SlAV32hkKG",
    "expires_in":3600,
    "refresh_token":"8xLOxBtZp8",
    "ext_value": "extension",
    "ext_list": [ 1, 2, "three" ],
    "ext_object": {
          "member1": "value1",
          "memberlist": [ "A", "B", "C"],
          "member3": 3,
          "memberobj": {
              "a": "first",
              "b": "second",
              "c": "third"
          }
    }
  }

The above is encoded into XML as follows (without using type attributes): 

  HTTP/1.1 200 OK
  Content-Type: application/xml
  Cache-Control: no-store

  <oauth>
    <access_token>SlAV32hkKG</access_token>
    <expires_in>3600</expires_in>
    <refresh_token>8xLOxBtZp8"</refresh_token>
    <ext_value>extension</ext_value>
    <ext_list>1</ext_list>
    <ext_list>2</ext_list>
    <ext_list>three</ext_list>
    <ext_object>
          <member1>value1</member>
          <memberlist>A</memberlist>
          <memberlist>B</memberlist>
          <memberlist>C</memberlist>
          <member3>3</member3>
          <memberobj>
              <a>first</a>
              <b>second</b>
              <c>third</c>
          </memberobj>
    </ext_object>
  </oauth>

 TOC 

5.  IANA Considerations

This document makes no request of IANA.


 TOC 

6.  Security Considerations

There are no additional security considerations.


 TOC 

7.  Acknowledgements


 TOC 

8. Normative References

[I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” draft-ietf-oauth-v2-10 (work in progress), July 2010 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[W3C.CR-xml11-20021015] Cowan, J., “Extensible Markup Language (XML) 1.1,” W3C CR CR-xml11-20021015, October 2002.

 TOC 

Author's Address

  Justin Richer (editor)
  The MITRE Corporation
Email:  jricher@mitre.org
--=-2QXRbFk+qbREQG9DBlzt Content-Disposition: attachment; filename="draft-richer-oauth-xml-01.txt" Content-Type: text/plain; name="draft-richer-oauth-xml-01.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Network Working Group J. Richer, Ed. Internet-Draft The MITRE Corporation Intended status: Experimental October 7, 2010 Expires: April 10, 2011 XML Encoding for OAuth 2 draft-richer-oauth-xml-00 Abstract This document describes a method of translating JSON structured values to XML structured values in the context of the OAuth 2 protocol. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 10, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Richer Expires April 10, 2011 [Page 1] Internet-Draft oauth-xml October 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Objects and Members . . . . . . . . . . . . . . . . . . . . 3 3.2. Root Element . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Type Identifiers . . . . . . . . . . . . . . . . . . . . . 4 3.4. Strings and Numbers . . . . . . . . . . . . . . . . . . . . 4 3.5. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Standard OAuth Token . . . . . . . . . . . . . . . . . . . 4 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Richer Expires April 10, 2011 [Page 2] Internet-Draft oauth-xml October 2010 1. Introduction The OAuth 2 Protocol [I-D.ietf-oauth-v2] makes use of JSON [RFC4627] encoding for its structured return values, as defined by section 4.2 of the OAuth specification. JSON encoding is not always desirable, particularly when OAuth is being used as part of an XML [W3C.CR-xml11-20021015] stream. This extension describes a method for the token endpoint to encode its return values as XML documents as opposed to JSON objects. 2. Transport To select XML encoding, the client sends the following OPTIONAL parameter format OPTIONAL. The format parameter specifies the client's desired format for responses from the token endpoint. Valid values are "json" and "xml". If omitted, the parameter value defaults to "json". The server SHALL respond to a valid access grant containing an XML format request with an HTTP 200 response and content type of "application/xml". 3. Encoding This section defines encodings for different parts of the JSON data model in XML equivalents. 3.1. Objects and Members JSON objects SHALL be encoded by using XML Elements. The object itself SHALL be represented by the root elment of an XML subtree. All members of the object SHALL be represented by sub-elements of the root element. The key of the member pair SHALL be the node name of the XML Element, and the value of the member pair SHALL be encoded as the content of the XML Element. The root element of the overall JSON object 3.2. Root Element The token endpoint SHALL use the root element with a node name "oauth" to represent the anonymous root JSON object specified in the OAuth specification. Richer Expires April 10, 2011 [Page 3] Internet-Draft oauth-xml October 2010 3.3. Type Identifiers All elements MAY have an OPTIONAL "type" attribute, which has a valid value of "object", "string", "number", or "array". 3.4. Strings and Numbers Strings and numbers SHALL be encoded as CDATA within their enclosing element. These values MUST be properly escaped XML CDATA, and MAY be represented using the <[CDATA[ ... ]]> encoding. 3.5. Arrays Arrays SHALL be represented using repeated, sibling XML Element nodes (nodes with the same node name). The order of the array is encoded using document order of the array elements. Note that there is no viable distinction between a single-element list and a raw value using this encoding. 3.6. Namespace This extension does not define a required namespace for the OAuth XML encoding. 4. Examples Below are examples of encoding different OAuth JSON objects with XML. 4.1. Standard OAuth Token A standard OAuth JSON-encoded token response: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600, "refresh_token":"8xLOxBtZp8" } Richer Expires April 10, 2011 [Page 4] Internet-Draft oauth-xml October 2010 Can be encoded in as the following XML response document: HTTP/1.1 200 OK Content-Type: application/xml Cache-Control: no-store SlAV32hkKG 3600 8xLOxBtZp8 Or, with optional type attributes (Section 3.3) in place: HTTP/1.1 200 OK Content-Type: application/xml Cache-Control: no-store SlAV32hkKG 3600 8xLOxBtZp8 4.2. Extensions Extensions to the OAuth protocol could make use of JSON's extensible data representation capabilities, including both objects and arrays. Using the encoding rules (Section 3) recursively, one can represent the same structures in XML. Richer Expires April 10, 2011 [Page 5] Internet-Draft oauth-xml October 2010 This example uses both objects and arrays to support a complicated, fictional example extension to the OAuth protocol: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600, "refresh_token":"8xLOxBtZp8", "ext_value": "extension", "ext_list": [ 1, 2, "three" ], "ext_object": { "member1": "value1", "memberlist": [ "A", "B", "C"], "member3": 3, "memberobj": { "a": "first", "b": "second", "c": "third" } } } Richer Expires April 10, 2011 [Page 6] Internet-Draft oauth-xml October 2010 The above is encoded into XML as follows (without using type attributes): HTTP/1.1 200 OK Content-Type: application/xml Cache-Control: no-store SlAV32hkKG 3600 8xLOxBtZp8" extension 1 2 three value1 A B C 3 first second third 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations There are no additional security considerations. 7. Acknowledgements Richer Expires April 10, 2011 [Page 7] Internet-Draft oauth-xml October 2010 8. Normative References [I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [W3C.CR-xml11-20021015] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR CR-xml11-20021015, October 2002. Author's Address Justin Richer (editor) The MITRE Corporation Email: jricher@mitre.org Richer Expires April 10, 2011 [Page 8] --=-2QXRbFk+qbREQG9DBlzt Content-Type: application/xml; name="draft-richer-oauth-xml-01.xml" Content-Disposition: attachment; filename="draft-richer-oauth-xml-01.xml" Content-Transfer-Encoding: 7bit XML Encoding for OAuth 2 The MITRE Corporation
jricher@mitre.org
This document describes a method of translating JSON structured values to XML structured values in the context of the OAuth 2 protocol. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The OAuth 2 Protocol makes use of JSON encoding for its structured return values, as defined by section 4.2 of the OAuth specification. JSON encoding is not always desirable, particularly when OAuth is being used as part of an XML stream. This extension describes a method for the token endpoint to encode its return values as XML documents as opposed to JSON objects.
To select XML encoding, the client sends the following OPTIONAL parameter OPTIONAL. The format parameter specifies the client's desired format for responses from the token endpoint. Valid values are "json" and "xml". If omitted, the parameter value defaults to "json". The server SHALL respond to a valid access grant containing an XML format request with an HTTP 200 response and content type of application/xml.
This section defines encodings for different parts of the JSON data model in XML equivalents.
JSON objects SHALL be encoded by using XML Elements. The object itself SHALL be represented by the root elment of an XML subtree. All members of the object SHALL be represented by sub-elements of the root element. The key of the member pair SHALL be the node name of the XML Element, and the value of the member pair SHALL be encoded as the content of the XML Element. The root element of the overall JSON object
The token endpoint SHALL use the root element with a node name oauth to represent the anonymous root JSON object specified in the OAuth specification.
All elements MAY have an OPTIONAL "type" attribute, which has a valid value of "object", "string", "number", or "array".
Strings and numbers SHALL be encoded as CDATA within their enclosing element. These values MUST be properly escaped XML CDATA, and MAY be represented using the <[CDATA[ ... ]]> encoding.
Arrays SHALL be represented using repeated, sibling XML Element nodes (nodes with the same node name). The order of the array is encoded using document order of the array elements. Note that there is no viable distinction between a single-element list and a raw value using this encoding.
This extension does not define a required namespace for the OAuth XML encoding.
Below are examples of encoding different OAuth JSON objects with XML.
A standard OAuth JSON-encoded token response:
Can be encoded in as the following XML response document: SlAV32hkKG 3600 8xLOxBtZp8 ]]>
Or, with optional type attributes in place: SlAV32hkKG 3600 8xLOxBtZp8 ]]>
Extensions to the OAuth protocol could make use of JSON's extensible data representation capabilities, including both objects and arrays. Using the encoding rules recursively, one can represent the same structures in XML.
This example uses both objects and arrays to support a complicated, fictional example extension to the OAuth protocol:
The above is encoded into XML as follows (without using type attributes): SlAV32hkKG 3600 8xLOxBtZp8" extension 1 2 three value1 A B C 3 first second third ]]>
This document makes no request of IANA.
There are no additional security considerations.
--=-2QXRbFk+qbREQG9DBlzt-- From jricher@mitre.org Fri Oct 29 14:53:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67EA3A6853 for ; Fri, 29 Oct 2010 14:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2kRTF0QmIIO for ; Fri, 29 Oct 2010 14:52:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A6FE23A6870 for ; Fri, 29 Oct 2010 14:52:54 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9TLsn5K026781 for ; Fri, 29 Oct 2010 17:54:49 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9TLsn0b026778 for ; Fri, 29 Oct 2010 17:54:49 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 29 Oct 2010 17:54:49 -0400 From: Justin Richer To: "oauth@ietf.org" Content-Type: multipart/mixed; boundary="=-//qBBygUU+1mOwVYYd2e" Date: Fri, 29 Oct 2010 17:54:48 -0400 Message-ID: <1288389288.13322.19.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Subject: [OAUTH-WG] Draft Extension: Instance Information X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:53:01 -0000 --=-//qBBygUU+1mOwVYYd2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit The IETF I-D submission is closed at the moment, so I'm attaching a draft extension to this email for now. It is my intention for this to become a working group item, and am looking forward to discussing this at IIW. -- Justin PS: This and the XML draft are my first time using the RFC formats, so I'll gladly take advice and help in getting these correct. --=-//qBBygUU+1mOwVYYd2e Content-Disposition: attachment; filename="draft-richer-oauth-instance-01.html" Content-Type: text/html; name="draft-richer-oauth-instance-01.html"; charset="UTF-8" Content-Transfer-Encoding: 8bit OAuth Client Instance Extension
 TOC 
Network Working GroupJ. Richer, Ed.
Internet-DraftThe MITRE Corporation
Intended status: ExperimentalOctober 7, 2010
Expires: April 10, 2011 


OAuth Client Instance Extension
draft-richer-oauth-instance-00

Abstract

This specification defines two client instance extension parameters for OAuth 2.0 user authorization requests.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 10, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1.  Introduction
    1.1.  Multiple Copies of One Client
    1.2.  Proxied Client Access
    1.3.  Dynamic, Anonymous, or Unregistered Clients
2.  Parameters
3.  IANA Considerations
4.  Security Considerations
5.  History
6.  References
    6.1.  Normative References
    6.2.  Other References
§  Author's Address



 TOC 

1.  Introduction

This extension to the OAuth 2 (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” July 2010.) [I‑D.ietf‑oauth‑v2] protocol defines two additional parameters that a client can include in requests to the user authorization endpoint which can be used to identify an instance of a given client and distinguish it from other instances of the same client that a user may authorize. These are intended to aid in the user experience and to be used in addition to the client identifier as defined in OAuth 2 (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” July 2010.) [I‑D.ietf‑oauth‑v2].


 TOC 

1.1.  Multiple Copies of One Client

A given client identifier may represent more than one access grant for a given user within a system protected by OAuth. For example, a user may authorize the same installed client on both a laptop and a desktop computer. Each of these would have the same client identifier but be issued different tokens and will have been granted access separately. This extension is intended to allow the two client instances to identify themselves to the authorization server in a way that the user could later differentiate which tokens belonged to which copy of the client.


 TOC 

1.2.  Proxied Client Access

An OAuth client capable of using the web-server flow could allow the user to interact with it through another means such as email or SMS. In this case, the OAuth client is a single entity with a single client ID which in turn could have multiple distinct grants per user. For example, in an email-proxied system, a user could grant access to the email proxy using multiple separate email addresses. In each of these, the client is the proxy itself, but the grant is being made on behalf of a particular email account. This extension is intended to allow the proxy client to identify to the authorization server which address is being requested.


 TOC 

1.3.  Dynamic, Anonymous, or Unregistered Clients

An authorization server can allow unregistered or anonymous clients to access its protected resources. In these cases, the client credentials generally act as a user-agent string, providing a machine-identifiable string claimed by the client itself. This extension is intended to allow such clients to present identifying information to the end-user through the authorization endpoint. See the security considerations section for more information.


 TOC 

2.  Parameters

instance_name
OPTIONAL A short, human-readable name that the server SHOULD display to the end-user along with the client name.
instance_description
OPTIONAL A longer, human-readable description that the server MAY display to the end-user along with the client name. If a client presents the instance_description, it MUST also present an instance_name.

The server MUST NOT assume any format or structure to either of the parameters.

If present, the authorization server SHOULD [MAY?] store this information along with its associated access grant in order to present it to the user at a future time. The authorization server MAY allow the end-user to edit or augment the client-presented information prior to storage. The authorization server MAY impose size limitations on either or both parameters, and such limitations SHOULD be documented as part of the the authorization server's API.


 TOC 

3.  IANA Considerations

This document makes no request of IANA.


 TOC 

4.  Security Considerations

The instance_name and instance_description parameters MUST be treated as self-asserted information and MUST NOT be treated as a replacement for a client credential as defined in OAuth 2 (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” July 2010.) [I‑D.ietf‑oauth‑v2]. Instead, the instance parameters MUST be treated with a level of trust appropriate to the end client.

When this information is displayed to the user, the authorization server MUST present it in such a way as to make clear to the end user that the instance information is self-asserted by the client and has not been validated. The authorization server MUST NOT display the instance information in lieu of a pre-registered display name, if available, but SHOULD display the instance information in addition to a pre-registered display name, if available.


 TOC 

5.  History

This extension is a continuation of the concepts proposed by the x_oauth_display_name (, “Google OAuth API Documentation,” .) [google_oauth] parameter as deployed by Google. Google has used this extension parameter to allow for unregistered clients using the consumer key and secret of anonymous/anonymous to identify themselves to the system. In this deployment, as far as the Authorization Server is concerned, all unregistered apps are different instances of the anonymous/anonymous client. As dicussed above (Introduction), this extension seeks to standardize use for unregistered, proxied, and multi-instance clients alike.


 TOC 

6.  References


 TOC 

6.1. Normative References

[I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol,” draft-ietf-oauth-v2-10 (work in progress), July 2010 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).

 TOC 

6.2. Other References

[google_oauth] “Google OAuth API Documentation.”

 TOC 

Author's Address

  Justin Richer (editor)
  The MITRE Corporation
--=-//qBBygUU+1mOwVYYd2e Content-Disposition: attachment; filename="draft-richer-oauth-instance-01.txt" Content-Type: text/plain; name="draft-richer-oauth-instance-01.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Network Working Group J. Richer, Ed. Internet-Draft The MITRE Corporation Intended status: Experimental October 7, 2010 Expires: April 10, 2011 OAuth Client Instance Extension draft-richer-oauth-instance-00 Abstract This specification defines two client instance extension parameters for OAuth 2.0 user authorization requests. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 10, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Richer Expires April 10, 2011 [Page 1] Internet-Draft oauth-instance October 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Multiple Copies of One Client . . . . . . . . . . . . . . . 3 1.2. Proxied Client Access . . . . . . . . . . . . . . . . . . . 3 1.3. Dynamic, Anonymous, or Unregistered Clients . . . . . . . . 3 2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Other References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Richer Expires April 10, 2011 [Page 2] Internet-Draft oauth-instance October 2010 1. Introduction This extension to the OAuth 2 [I-D.ietf-oauth-v2] protocol defines two additional parameters that a client can include in requests to the user authorization endpoint which can be used to identify an instance of a given client and distinguish it from other instances of the same client that a user may authorize. These are intended to aid in the user experience and to be used in addition to the client identifier as defined in OAuth 2 [I-D.ietf-oauth-v2]. 1.1. Multiple Copies of One Client A given client identifier may represent more than one access grant for a given user within a system protected by OAuth. For example, a user may authorize the same installed client on both a laptop and a desktop computer. Each of these would have the same client identifier but be issued different tokens and will have been granted access separately. This extension is intended to allow the two client instances to identify themselves to the authorization server in a way that the user could later differentiate which tokens belonged to which copy of the client. 1.2. Proxied Client Access An OAuth client capable of using the web-server flow could allow the user to interact with it through another means such as email or SMS. In this case, the OAuth client is a single entity with a single client ID which in turn could have multiple distinct grants per user. For example, in an email-proxied system, a user could grant access to the email proxy using multiple separate email addresses. In each of these, the client is the proxy itself, but the grant is being made on behalf of a particular email account. This extension is intended to allow the proxy client to identify to the authorization server which address is being requested. 1.3. Dynamic, Anonymous, or Unregistered Clients An authorization server can allow unregistered or anonymous clients to access its protected resources. In these cases, the client credentials generally act as a user-agent string, providing a machine-identifiable string claimed by the client itself. This extension is intended to allow such clients to present identifying information to the end-user through the authorization endpoint. See the security considerations section for more information. Richer Expires April 10, 2011 [Page 3] Internet-Draft oauth-instance October 2010 2. Parameters instance_name OPTIONAL A short, human-readable name that the server SHOULD display to the end-user along with the client name. instance_description OPTIONAL A longer, human-readable description that the server MAY display to the end-user along with the client name. If a client presents the instance_description, it MUST also present an instance_name. The server MUST NOT assume any format or structure to either of the parameters. If present, the authorization server SHOULD [MAY?] store this information along with its associated access grant in order to present it to the user at a future time. The authorization server MAY allow the end-user to edit or augment the client-presented information prior to storage. The authorization server MAY impose size limitations on either or both parameters, and such limitations SHOULD be documented as part of the the authorization server's API. 3. IANA Considerations This document makes no request of IANA. 4. Security Considerations The instance_name and instance_description parameters MUST be treated as self-asserted information and MUST NOT be treated as a replacement for a client credential as defined in OAuth 2 [I-D.ietf-oauth-v2]. Instead, the instance parameters MUST be treated with a level of trust appropriate to the end client. When this information is displayed to the user, the authorization server MUST present it in such a way as to make clear to the end user that the instance information is self-asserted by the client and has not been validated. The authorization server MUST NOT display the instance information in lieu of a pre-registered display name, if available, but SHOULD display the instance information in addition to a pre-registered display name, if available. Richer Expires April 10, 2011 [Page 4] Internet-Draft oauth-instance October 2010 5. History This extension is a continuation of the concepts proposed by the x_oauth_display_name [google_oauth] parameter as deployed by Google. Google has used this extension parameter to allow for unregistered clients using the consumer key and secret of anonymous/anonymous to identify themselves to the system. In this deployment, as far as the Authorization Server is concerned, all unregistered apps are different instances of the anonymous/anonymous client. As dicussed above (Section 1), this extension seeks to standardize use for unregistered, proxied, and multi-instance clients alike. 6. References 6.1. Normative References [I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Other References [google_oauth] "Google OAuth API Documentation", . Author's Address Justin Richer (editor) The MITRE Corporation Richer Expires April 10, 2011 [Page 5] --=-//qBBygUU+1mOwVYYd2e Content-Type: application/xml; name="draft-richer-oauth-instance-01.xml" Content-Disposition: attachment; filename="draft-richer-oauth-instance-01.xml" Content-Transfer-Encoding: 7bit OAuth Client Instance Extension The MITRE Corporation
This specification defines two client instance extension parameters for OAuth 2.0 user authorization requests. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This extension to the OAuth 2 protocol defines two additional parameters that a client can include in requests to the user authorization endpoint which can be used to identify an instance of a given client and distinguish it from other instances of the same client that a user may authorize. These are intended to aid in the user experience and to be used in addition to the client identifier as defined in OAuth 2.
A given client identifier may represent more than one access grant for a given user within a system protected by OAuth. For example, a user may authorize the same installed client on both a laptop and a desktop computer. Each of these would have the same client identifier but be issued different tokens and will have been granted access separately. This extension is intended to allow the two client instances to identify themselves to the authorization server in a way that the user could later differentiate which tokens belonged to which copy of the client.
An OAuth client capable of using the web-server flow could allow the user to interact with it through another means such as email or SMS. In this case, the OAuth client is a single entity with a single client ID which in turn could have multiple distinct grants per user. For example, in an email-proxied system, a user could grant access to the email proxy using multiple separate email addresses. In each of these, the client is the proxy itself, but the grant is being made on behalf of a particular email account. This extension is intended to allow the proxy client to identify to the authorization server which address is being requested.
An authorization server can allow unregistered or anonymous clients to access its protected resources. In these cases, the client credentials generally act as a user-agent string, providing a machine-identifiable string claimed by the client itself. This extension is intended to allow such clients to present identifying information to the end-user through the authorization endpoint. See the security considerations section for more information.
OPTIONAL A short, human-readable name that the server SHOULD display to the end-user along with the client name. OPTIONAL A longer, human-readable description that the server MAY display to the end-user along with the client name. If a client presents the instance_description, it MUST also present an instance_name. The server MUST NOT assume any format or structure to either of the parameters. If present, the authorization server SHOULD [MAY?] store this information along with its associated access grant in order to present it to the user at a future time. The authorization server MAY allow the end-user to edit or augment the client-presented information prior to storage. The authorization server MAY impose size limitations on either or both parameters, and such limitations SHOULD be documented as part of the the authorization server's API.
This document makes no request of IANA.
The instance_name and instance_description parameters MUST be treated as self-asserted information and MUST NOT be treated as a replacement for a client credential as defined in OAuth 2. Instead, the instance parameters MUST be treated with a level of trust appropriate to the end client. When this information is displayed to the user, the authorization server MUST present it in such a way as to make clear to the end user that the instance information is self-asserted by the client and has not been validated. The authorization server MUST NOT display the instance information in lieu of a pre-registered display name, if available, but SHOULD display the instance information in addition to a pre-registered display name, if available.
This extension is a continuation of the concepts proposed by the x_oauth_display_name parameter as deployed by Google. Google has used this extension parameter to allow for unregistered clients using the consumer key and secret of anonymous/anonymous to identify themselves to the system. In this deployment, as far as the Authorization Server is concerned, all unregistered apps are different instances of the anonymous/anonymous client. As dicussed above, this extension seeks to standardize use for unregistered, proxied, and multi-instance clients alike.
Google OAuth API Documentation --=-//qBBygUU+1mOwVYYd2e-- From ve7jtb@ve7jtb.com Sun Oct 31 04:46:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4A13A6845 for ; Sun, 31 Oct 2010 04:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VufQg8vQM6mG for ; Sun, 31 Oct 2010 04:46:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 001A73A683C for ; Sun, 31 Oct 2010 04:46:36 -0700 (PDT) Received: by iwn40 with SMTP id 40so6084690iwn.31 for ; Sun, 31 Oct 2010 04:48:35 -0700 (PDT) Received: by 10.231.14.73 with SMTP id f9mr12780861iba.25.1288525715129; Sun, 31 Oct 2010 04:48:35 -0700 (PDT) Received: from 70-9-55-37.pools.spcsdns.net (70-9-55-37.pools.spcsdns.net [70.9.55.37]) by mx.google.com with ESMTPS id 8sm6805249iba.16.2010.10.31.04.48.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 04:48:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-659-980863515; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sun, 31 Oct 2010 08:48:28 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> To: John Panzer X-Mailer: Apple Mail (2.1081) Cc: "openid-specs-connect@lists.openid.net" , "openid-specs-ab@lists.openid.net" , "webfinger@googlegroups.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 11:46:39 -0000 --Apple-Mail-659-980863515 Content-Type: multipart/alternative; boundary=Apple-Mail-658-980863426 --Apple-Mail-658-980863426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John is correct. =20 Also when using a URL identifier like a blog it is possible to publish a = XRD via link headers as well. =20 That helps make publishing meta-data open to a broader selection of = users. If a site wanted to have a oAuth protected XRD service there is nothing = to stop that. In XRI/XRDS resolution we had per service discovery, much the same as MS = is proposing for similar reasons. People criticized that in XRI/XRDS as being too complicated. That is = why it is not in the current XRD spec. We do need to make a side by side comparison. I know that people have asked for a JSON format XRD document option. = That is on the OASIS TC list of things to work on. John Bradley On 2010-10-29, at 3:35 PM, John Panzer wrote: > I think that it would be good to have a writeup like this that = describes the differences and pros and cons of each approach. Perhaps on = a Wiki page? >=20 > Some random thoughts: >=20 > One thing: host-meta is highly cacheable, so the # of round trips = will hopefully be comparable for large services with significant = traffic. In fact the user XRD is also cacheable as well so there can be = zero round trips. This proposal defines a mechanism separate from HTTP = caching in order to cache responses, it'd be good to have a rationale = for doing that (and to have an explanation of how this should interact = with additional HTTP level caching.) >=20 > This mechanism appears to require multiple round trips to a server if = you want to discover multiple services. =20 >=20 > This proposal seems to require that the /well-known provider run a = significant service on their endpoint, as opposed to just dropping a = file in place. I think that the forwarding mechanism may be a way = around that? How would I hook into this mechanism if I really only can = drop static files on my web server, but I can perhaps use cloud services = that I've registered with to actually power the discovery? >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer >=20 >=20 >=20 > On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock = wrote: > Hello! > This draft is looking nice, the idea and specification is simple and > straightforward. I would like to draw the connection to other > discovery approaches. >=20 > The introductory example in the draft was this one: > GET = /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&servi= ce=3Durn:adatum.com:calendar > HTTP/1.1 >=20 > This returns the following response: > { > "locations":["http://calendars.proseware.com/calendars/joseph"] > } >=20 > As per my understanding - please correct me if I'm wrong - this should > be semantically equivalent to the following: > 1) Perform host-meta discovery for example.com, which returns an XRD > with the webfinger endpoint. > 2) Do webfinger for joe@example.com. > 3) The final XRD contains the following: > > [...] > href=3D"http://calendars.proseware.com/calendars/joseph" /> > [...] > >=20 > Both approaches work, but SWD is a shortcut removes parsing > requirements and fetching roundtrips from the client. >=20 > Thoughts, anyone?! >=20 > Regards, > Lukas Rosenstock >=20 > 2010/10/27 Mike Jones : > > Yaron Goland and I are submitting this Simple Web Discovery (SWD) = draft > > (attached and at > > = http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) = for > > consideration by the community to address this need. SWD is simple = to > > understand and implement, enables different permissions to be = applied to > > discovery of different services, and is JSON-based. I look forward = to > > discussing this with many of you next week at IIW. > > > > > > > > -- = Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --Apple-Mail-658-980863426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii John = is correct.  

Also when using a URL identifier = like a blog it is possible to publish a XRD via link headers as well. =  
That helps make publishing meta-data open to a broader = selection of users.

If a site wanted to have a = oAuth protected XRD service there is nothing to stop = that.

In XRI/XRDS resolution we had per service = discovery, much the same as MS is proposing for similar = reasons.

People criticized that in XRI/XRDS as = being too complicated.  That is why it is not in the current XRD = spec.

We do need to make a side by side = comparison.

I know that people have asked for a = JSON format XRD document option.   That is on the OASIS TC list of = things to work on.

John Bradley
On = 2010-10-29, at 3:35 PM, John Panzer wrote:

I think = that it would be good to have a writeup like this that describes the = differences and pros and cons of each approach. Perhaps on a Wiki = page?

Some random = thoughts:

One thing:  host-meta is highly = cacheable, so the # of round trips will hopefully be comparable for = large services with significant traffic.  In fact the user XRD is = also cacheable as well so there can be zero round trips.  This = proposal defines a mechanism separate from HTTP caching in order to = cache responses, it'd be good to have a rationale for doing that (and to = have an explanation of how this should interact with additional HTTP = level caching.)

This mechanism appears to require multiple round = trips to a server if you want to discover multiple services. =  

This proposal seems to require that the = /well-known provider run a significant service on their endpoint, as = opposed to just dropping a file in place.  I think that the = forwarding mechanism may be a way around that?  How would I hook = into this mechanism if I really only can drop static files on my web = server, but I can perhaps use cloud services that I've registered with = to actually power the discovery?

--
John Panzer / = Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Fri, Oct 29, 2010 at 4:04 AM, = Lukas Rosenstock <lr@lukasrosenstock.net> = wrote:
Hello!
This draft is looking nice, the idea and specification is simple and
straightforward. I would like to draw the connection to other
discovery approaches.

The introductory example in the draft was this one:
GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&service=3Durn:adatum.com:calenda= r
HTTP/1.1

This returns the following response:
{
 "locations":["http://calendars.proseware.com/calendars/joseph"] }

As per my understanding - please correct me if I'm wrong - this = should
be semantically equivalent to the following:
1) Perform host-meta discovery for example.com, which returns an XRD
with the webfinger endpoint.
2) Do webfinger for joe@example.com.
3) The final XRD contains the following:
<XRD>
[...]
<Link rel=3D"urn:adatum.com:calendar"
href=3D"http://calendars.proseware.com/calendars/joseph" = />
[...]
</XRD>

Both approaches work, but SWD is a shortcut removes parsing
requirements and fetching roundtrips from the client.

Thoughts, anyone?!

Regards,
 Lukas Rosenstock

2010/10/27 Mike Jones <Michael.Jones@microsoft.com>:
> Yaron Goland and I are submitting this Simple Web Discovery = (SWD) draft
> (attached and at
> http://self-issued.info/docs/draft-jones-simple-web-disc= overy-00.html) for
> consideration by the community to address this need.  SWD is = simple to
> understand and implement, enables different permissions to be = applied to
> discovery of different services, and is JSON-based.  I look = forward to
> discussing this with many of you next week at IIW.
>
>
>
> =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;  -- Mike
=
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
Openid-specs-ab = mailing list
Openid-specs-ab@lists.ope= nid.net
http://l= ists.openid.net/mailman/listinfo/openid-specs-ab

= --Apple-Mail-658-980863426-- --Apple-Mail-659-980863515 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEw MzExMTQ4MjlaMCMGCSqGSIb3DQEJBDEWBBSwzLzbhBwfpVF1SBNAKQtsyIMPrDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQA5LwOjfvVsMnUZAKmv615wpCTNATwxGdiUSeF6fhfwsY6AOJaNiweAT7uSLgtQbONGY2rMF0Up dtsvThs1TTxDOs9T+4PvcJ0UMexMb5AUc3tjCpQ7vftfubgu6+KTKStscJUrTiUtRLuBbkDCDjy1 aZ7NJBCMfmpTFJbULfC2eUwlZVYzrwxuKp/HveSjRDF8bhEDl/3dlIbvlSGSbl+oBuANqRBTKEyV OihtTHphctsX1EUJissrVUJM2Ebda1nEF2x0tVD0K9opRqGbnaPwWVmqP0ZuO938e8BGfc5K2aK0 EPfzDe33RW+chCtSEgy05eyiORPEPV8LRHcqbGHoAAAAAAAA --Apple-Mail-659-980863515-- From lr@lukasrosenstock.net Sun Oct 31 08:20:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729593A6975 for ; Sun, 31 Oct 2010 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W0jrNbwcbiv for ; Sun, 31 Oct 2010 08:20:43 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7251A3A6925 for ; Sun, 31 Oct 2010 08:20:43 -0700 (PDT) Received: by gya6 with SMTP id 6so3011977gya.31 for ; Sun, 31 Oct 2010 08:22:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.190.145 with SMTP id di17mr340414qcb.252.1288538562272; Sun, 31 Oct 2010 08:22:42 -0700 (PDT) Received: by 10.229.181.213 with HTTP; Sun, 31 Oct 2010 08:22:42 -0700 (PDT) X-Originating-IP: [91.34.24.149] In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Sun, 31 Oct 2010 16:22:42 +0100 Message-ID: From: Lukas Rosenstock To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "openid-specs-connect@lists.openid.net" , "openid-specs-ab@lists.openid.net" , "webfinger@googlegroups.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Simple Web Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 15:20:44 -0000 2010/10/29 John Panzer : > I think that it would be good to have a writeup like this that describes = the > differences and pros and cons of each approach. Perhaps on a Wiki page? Feel free to copy this to a wiki page: 1) Server-side requirements: - XRD/Webfinger: creating .well-known, placing a static host-meta file with appropriate content type, a Webfinger endpoint which could be static as well (e.g. by mapping to a file named like the account identifier) - SWD: creating .well-known, placing a dynamic endpoint which can parse the input (requested user and service) and return the output as one service from a list of services for the user 2) Server delegation: - XRD/Webfinger: host-meta can point to a third-party host for rel=3D"lrdd" - SWD: defines its own delegation mechanism based on a JSON file 3) Authentication: - not fully defined but possible in both approaches via HTTP Basic authentication or OAuth 4) Consumer-side requirements: - XRD/Webfinger: fetching host-meta (preferrably with caching), parsing XML for lrdd endpoint; webfinger request, parsing XML for required service links - SWD: one request for user and service, parsing JSON for endpoint; multiple trips for multiple requests or if redirection is required 5) Network bandwidth requirements: - XRD/Webfinger: two requests (host-meta and lrdd), of which one is cacheable for multiple users (same domain); transmission of irrelevant data is very likely if XRDs are getting bigger - SWD: one request only, lightweight data; but can become inefficient if a longer list of services is fetched (individually) > Some random thoughts: > One thing: =A0host-meta is highly cacheable, so the # of round trips will > hopefully be comparable for large services with significant traffic. =A0I= n > fact the user XRD is also cacheable as well so there can be zero round > trips. =A0This proposal defines a mechanism separate from HTTP caching in > order to cache responses, it'd be good to have a rationale for doing that > (and to have an explanation of how this should interact with additional H= TTP > level caching.) > This mechanism appears to require multiple round trips to a server if you > want to discover multiple services. > This proposal seems to require that the /well-known provider run a > significant service on their endpoint, as opposed to just dropping a file= in > place. =A0I think that the forwarding mechanism may be a way around that?= =A0How > would I hook into this mechanism if I really only can drop static files o= n > my web server, but I can perhaps use cloud services that I've registered > with to actually power the discovery? I've tried to include these thoughts in the compilation. Lukas