Re: [OAUTH-WG] OAuth Digest, Vol 40, Issue 12

robert flores <> Tue, 14 February 2012 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A52FD21E80F1 for <>; Tue, 14 Feb 2012 12:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_43=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rvu4QhBsQbeJ for <>; Tue, 14 Feb 2012 12:45:43 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 3723321E80EF for <>; Tue, 14 Feb 2012 12:45:43 -0800 (PST)
Received: from [] by with NNFMP; 14 Feb 2012 20:45:37 -0000
Received: from [] by with NNFMP; 14 Feb 2012 20:45:37 -0000
Received: from [] by with NNFMP; 14 Feb 2012 20:45:37 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 6561 invoked by uid 60001); 14 Feb 2012 20:45:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1329252336; bh=OCE8lEpci8EgJPHZd8g0PT7AI1R4NLKUCkO6lkr08Ek=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WAg9ygu121GdirWP3anM/KA7fvjyqMNrUKup4pamN+VuNby1YkPlqcJU2OH0en9PC1tuCX19MVsfJUOdRbjPvrtheu+6kRco3ZPKFYobN/CxX2Lo6kiIJriQzk9byMJSLX/8Gx8YSdbMEbHCfHUwPRRUYSmMORsdliji21ib81I=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cPMKQPZVB9+AItsku9gok8/tPQgSqxvDyRo90DzE8SqjCYNkHQgPDoyltuIAV82KoDIAn+cueVV4BmNEeXlZcWqvIfSalqBzJ1Y3Pwnr7CopcpzRpVKZTud0PC911VwkdUmiwYG/IDCEFjZn+Ov+iew9JQJeLwCCnKWztYJijtk=;
X-YMail-OSG: EzHyDU8VM1nhToPQPz54m5hNzKtqFJm8t_MUyuK09QuPnO6 Rp6ZMmiDmyHpKQvXXgs8WRTK_2T41D.8sdPbn0kLh_Y0kyEdHGqg0JUdfQJL V3yOKTvmX2FErdlD8oQHE1j7mAn6HiEkFj84K3t6CLSUWaAVWEt05SGzpA2Y _sG5kHoc0.kpNtg9GpHP0pCNCM8pup5XgIsjSTmACPMo06L6Qsy8lfjBxw9w Ft5FQG61rsISkXDyP1s15INVwXtlwskUhQ1uDVtSF_sFzK0HbooHqTcMQ51Q MkwUJrGElcElmWVuzOg8MColP3cey.7bg6V7id3TVNWW6QA18jTdpbA3LCZl MflOoFSA8S55QuN5OPjO_gLPAo9Y9LSawM66Y_ezF5pSiY.luTnWTqMu_JDm gxEQrAv8NfMI75bxo4yqmGpvW2cAZ_4dLj9ntFRsJF01Pru5B9dATR3mAKUQ iyzYAmrycA5V4ZeOBbqnD.yw1tNxWro9J55XNHIpNWt1A1eAm6KXbcxH7WUd M_JMuHomi.nzm.2JJTyKo3oFekBPbj5e3by4LaS.4H1zlG9d4Dbmkc33BJHS bTI8BXzFQlZtzRzTO6Iw980s6yoP_Yg--
Received: from [] by via HTTP; Tue, 14 Feb 2012 12:45:36 PST
X-Mailer: YahooMailWebService/
Message-ID: <>
Date: Tue, 14 Feb 2012 12:45:36 -0800
From: robert flores <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 40, Issue 12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2012 20:45:44 -0000

re: New Exponent add to list of ad-list of : eucolypitcal value : majorus .¿&: component: programe: save&ridity-Junquerah:@autoresponder.lawe:need od:force@removal.point.maintree of all and any!logrithuime to product.uranium.overkilt:tiltdotlawe:of yucca&.junqureah=eucalypatuse.made.underrighte.lawe.via.cola!pont.point.excarpo'kexarp!warrant!clavic.lawe'!excalibure!!@reasone.@age'um:eucalip.lawe=barracuda!pont.protriues:magna.carta'.lehale.issue(r):carnium:lawe!.mint&.tea.pointe:excaliber.issue!&.add.programe: name'ded!'edd: ( of reasearh.finite:editor:(!= :"FOG!.(carl.sandburge.poeme':22:29:20:20!issuer:r:r:5!)§=¶!..Phineas.Fog!!u.l.d.):Honeywell.Products.Inc!.§10-4+!good!oute! to All'e Persone' at V:Very.Goode!.over&.oute:10-4!.

On Tue, Feb 14, 2012 3:00 PM EST wrote:

>If you have received this digest without all the individual message
>attachments you will need to update your digest options in your list
>subscription.  To do so, go to 
>Click the 'Unsubscribe or edit options' button, log in, and set "Get
>MIME or Plain Text Digests?" to MIME.  You can set this option
>globally for all the list digests you receive at this point.
>Send OAuth mailing list submissions to
>To subscribe or unsubscribe via the World Wide Web, visit
>or, via email, send a message with subject or body 'help' to
>You can reach the person managing the list at
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of OAuth digest..."
>Today's Topics:
>   1. Re: FW: Appsdir review of draft-ietf-oauth-v2-23
>      (Henry S. Thompson)
>Message: 1
>Date: Tue, 14 Feb 2012 17:07:12 +0000
>From: (Henry S. Thompson)
>To: Justin Richer <>
>Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23
>Message-ID: <>
>Content-Type: text/plain; charset=us-ascii
>[Sigh, resending with corrected CC list]
>Justin writes:
>> [Henry wrote]:
>> Subject: Appsdir review of draft-ietf-oauth-v2-23
>> I have been selected as the Applications Area Directorate reviewer for
>> this draft (for background on appsdir, please see <a  rel="nofollow"
>> href=""></a>).
>> Please resolve these comments along with any other Last Call comments
>> you may receive. Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> Document: draft-ietf-oauth-v2-23
>> Title: The OAuth 2.0 Authorization Protocol
>> Reviewer: Henry S. Thompson
>> Review Date: 2012-02-07
>> IETF Last Call Date: 2012-01-24
>> Summary: This draft is almost ready for publication as an Proposed
>>           Standard but has a few issues that should be fixed
>>           before publication
>> [Note - My expertise is in the areas of markup and architecture, with
>> only the average geek's understanding of security and cryptographic
>> technologies.  Any comments below on security issues are therefore of
>> the nature of general audience concerns, rather than technical
>> worries.]
>> Major Issues:
>>  The failure to require TLS here is worrying.  At the very
>> least I would expect a requirement that clients which do _not_ require
>> TLS MUST provide significant user feedback calling attention to this
>> -- by analogy, absence of a padlock does _not_ suffice. . .
>> There are two bits going on here, and I think there's confusion
>> again about this being a *client* controlled endpoint. First, not
>> all callback redirects are remote HTTP URLs. A <a rel="nofollow"
>> href="http://localhost/">http://localhost/</a> callback or an app://
>> callback are going to be very common with installed clients, and in
>> both of these cases TLS makes no sense to require. Second, and this
>> is the reason spelled out in the text, you can't really expect all
>> *clients* to use proper TLS on their redirects. If it's a remote
>> HTTP call, then it's likely a very Bad Idea to go over a plaintext
>> socket, yes. But there are enough other cases where mandating it
>> doesn't make sense.
>> Suggestion: call out second non-HTTP use case here as well, perhaps
>> stop calling it an "endpoint" to differentiate it from the
>> server-side pieces.
>OK, sounds like I didn't fully understand the context here.  Providing
>the examples you give as motivation would help keep others from making
>the same mistake. . .
>> [3].1.2.5  In a somewhat parallel case, I would expect this section to
>> at least explain why the SHOULD NOT is not a MUST NOT. Since in
>> practice the distinction between trusted and untrusted 3rd-party
>> scripting is difficult if not impossible to draw, as written the 2nd
>> para is effectively overriden by the third.
>> Assuming this means
>Yes, sorry.
>> A MUST NOT is impossible to enforce here. You're telling people to
>> not include jQuery in their JavaScript app. Truth is, any third
>> party library that you include in your app could get access to the
>> security bits whether it's on the callback page or not. I think it's
>> appropriate to provide guidance for best practices here, and the
>> MUST be first and SHOULD be only makes sense. People will get it
>> wrong in spite of what the spec says here one way or another.
>Hmmm.  Either I'm misreading the text, or I don't understand your
>argument. . .  The existing "MUST NOT" para applies to untrusted js.
>The second para. is nearly identical in terms of what it wants done,
>but covers _all_ js.  Writing MUST/SHOULD NOT and knowing people will
>get it wrong just undermines the value of the spec.
>> Suggestion: drop the requirements (and move them to the security
>> doc), or otherwise no change.
>If by that you mean, moving it to the security section, and observing
>there that _failure_ to sanitise early is a risk, by effectively
>COMPROMISE, that would work for me.
>> 11  It seems at best old-fashioned that the designer of a new access
>> token type, parameter, endpoint response type or extension error has
>> no better tool available than Google to help him/her discover whether
>> the name they have in mind is in use already.  The same is true under
>> the proposed approach for any developer trying to determine what they
>> can use or must support.  Is there some reason that mandated URI
>> templates, after the fashion of
>> are not mandated for the registries, e.g.
>> ?  If there is a good reason, please use it to at least explicitly
>> acknowledge and justify the basis for failing to provide a way for
>> users and developers to use the "follow your nose" strategy
>> [1].  If there is no good reason, please include the appropriate
>> language to require something along the lines suggested above.  If you
>> need a model, see [2].
>> I'm confused - is this a request to use a full URI for all extension
>> values? I thought the purpose of a registry was to deconflict the
>> short names, and that URIs could be used for anything else.
>No, I appreciate that you want to use registered short names in the
>protocol, that's just fine.  My problem is that you have left users,
>developers etc. with no way to discover what shortnames have been
>registered short of a non-trivial and error-prone informal search
>What I'm asking for is support for probe URI prefixes for each family
>of shortnames.  So, just as today I use "text/n3" as the media type for
>my Notation3 documents, I can check that this is a registered media
>type by attempting to retrieve
>and I can see all the registered text types by retrieving from
>likewise I ought to be able to check e.g. the "bearer" token type by
>attempting retrieval from (something along the lines of)
>and I should be able to see all the registered token types by retrieving from
>Hope this clarifies what I meant.
>> Minor Issues:
>> A short summary of the changes from OAuth 1.0/RFC5849 would have
>> been helpful, and it might still be a good idea to add one. . .
>> I don't think this is possible. OAuth2 is built nfundamentally
>> differently from OAuth1, so this paragraph might as well read "just
>> about everything but the concept". Suggestion: don't add this,
>> unless someone can come up with a succinct way to summarize the
>> decision to build on a new foundation.
>OK, thanks.  Even something like the above short statement would be
>useful . . .
>> 4.1 Would it be helpful to indicate that steps D&E may occur at
>> any time after C, and may be repeated subsequently?
>> D&E may be delayed, but shouldn't be repeated. The Access Code is
>> one-time-use, and in the best deployments will expire after a short
>> period of time. Suggestion: leave as is.
>OK, I just think as it is it invites misinterpretation.
>> 11.1 It might be useful to have an 11.1.2, which repeats references
>> to the bearer and mac access token type registration drafts?
>> Is this a request to pre-register the two 'core' token types?
>Yes, in that what I had in mind was making 11.1 parallel to ll.2, 3
>and 4 in this regard.
>[I'm sorry about the mailing list confusion.  But please don't punish
> me again by sending HTML change bar markup which I have to hand edit :-]
>       Henry S. Thompson, School of Informatics, University of Edinburgh
>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                Fax: (44) 131 650-4587, e-mail:
>                       URL:
> [mail from me _always_ has a .sig like this -- mail without it is forged spam]
>OAuth mailing list
>End of OAuth Digest, Vol 40, Issue 12