From nobody Mon Dec 1 00:18:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0FA1A1B19 for ; Mon, 1 Dec 2014 00:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e79Oa-Qt8nK for ; Mon, 1 Dec 2014 00:18:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933741A1AFB for ; Mon, 1 Dec 2014 00:18:50 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1XmWUJ2pQO-008upk; Mon, 01 Dec 2014 09:18:48 +0100 Message-ID: <547C2466.7070708@gmx.net> Date: Mon, 01 Dec 2014 09:18:46 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Richer References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <4BFAB728-BF73-4213-8CDF-CC5080695C0F@mit.edu> In-Reply-To: <4BFAB728-BF73-4213-8CDF-CC5080695C0F@mit.edu> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dRisDWCQE65pFvfQIuxemoRgRSJfJxVn6" X-Provags-ID: V03:K0:5jeJIbP7iYkbabVWsiUJdjFICcarc6vSktMjD58FagzrgS8Hnhj 5jmT/AVy6Qz0PxmuTvN6R27AnxyxnIRFIxdg7eK5qYjxLHLtD8Jm84xZM4jdJhlPsljVFmI SOPqPv5OZM7QGXCSFiu80LKBQaWMzNMR3EdyNmVTP7PzfCZTd/YXKoveCp9J/eDp8B88109 080ilH4yw1O0QUsiYq/2Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dat-IgimBbj_C7Mi1Usc4oYbc4Q Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 08:18:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dRisDWCQE65pFvfQIuxemoRgRSJfJxVn6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, thanks for making the change in the upcoming version. Ciao Hannes On 12/01/2014 03:21 AM, Justin Richer wrote: > Hannes, >=20 > I=92ve had a chance to more thoroughly re-read both the drafts and your= > notes, I think you=92re actually correct about the IANA registration. W= e > register =93client_id=94 and =93client_secret=94, even though they can=92= t be > requested by the client. As such, we do need to register > =93registration_access_token=94 and the =93registration_client_uri=94 i= n the > registry. We=92ll make sure those are in the next revision of the docum= ent. >=20 > =97 Justin >=20 > On Nov 26, 2014, at 8:32 AM, Justin Richer > wrote: >=20 >> And by =936790=94 below I obviously mean RFC6749. >> >> (Note to self, don=92t write working group emails this early in the >> morning.) >> >> =97 Justin >> >> On Nov 26, 2014, at 8:31 AM, Justin Richer > > wrote: >> >>> >>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig >>> > wrote:= >>> >>>> Hi Justin, >>>> >>>> thanks for your quick response. A few remarks below. >>>> >>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>>> Hannes, thank you for the review. Answers inline. >>>>> >>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig >>>>> > wrot= e: >>>>> >>>>>> Hi Justin, Mike, John, Maciej, >>>>>> >>>>>> as part of my shepherd write-up I carefully read through >>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the document is in= >>>>>> good shape but I have a few minor clarification questions that >>>>>> should be resolved before the document goes to the IESG. >>>>>> >>>>>> In Section 1.4. "Registration Tokens and Client Credentials" you >>>>>> explain the different credential types and I was wondering why you= >>>>>> aren't issuing client_secrets to all clients instead of introducin= g >>>>>> another credential, the registration access token. While you try t= o >>>>>> explain the reasons those appear somewhat constructed. For example= , >>>>>> you say that "not all types of clients have client credentials" bu= t >>>>>> you are the author of the specification and you can essentially >>>>>> decide what to do. The registration access token is essentially th= e >>>>>> same as the client credential since it is "is uniquely bound to th= e >>>>>> client identifier". >>>>>> >>>>>> I believe we have discussed this issue in the past but I don't >>>>>> remember what the reasoning was. Can you describe what your design= >>>>>> rational was (and add it to the document)? >>>>> >>>>> That's exactly the question this section is trying to answer, and i= f >>>>> it can be made clearer then please suggest some text that will help= >>>>> that purpose. The rationale for the registration access token is ve= ry >>>>> simple: we want to have a means to call the management endpoint in = a >>>>> protected manner, and treating the management endpoint as an OAuth >>>>> Protected Resource makes a lot of sense. RFC6750 gives us the means= >>>>> to make an authorized call to an API endpoint, so we're re-using th= at >>>>> instead of trying to invent some other mechanism. Shouldn't we be >>>>> helping the world get away from API passwords? >>>>> >>>>> And it's very true that not every client is going to have a client >>>>> secret to use at the token endpoint -- some will have no use of one= >>>>> (public and implicit clients) and some will be using TLS or >>>>> asymmetric keys (JWT assertions, for instance) or other mechanisms = to >>>>> authenticate that don't involve the secret. Instead of forcing thes= e >>>>> clients to use a client secret for one new endpoint, or forcing tha= t >>>>> endpoint to potentially support the infinite number of client >>>>> authentication mechanisms, we decided to just use OAuth. These are >>>>> OAuth clients, remember -- they will *all* have the ability to send= >>>>> OAuth tokens to a protected resource already built in. >>>>> >>>> >>>> Here is the point I don't quite get: the registration access token i= s >>>> essentially the same as a client secret. You as a specification auth= or >>>> essentially decides whether clients will get a client secret or a >>>> registration access token. It is under your control. >>>> >>>> To be more specific, here is what you could have done: >>>> >>>> C -> S: Client Registration Request >>>> C <- S: Client Information Response (with new client secret) >>>> >>>> C -> S: Read or Update Request (with client id/client secret) >>>> C <- S: Client Information Response >>>> >>>> Instead, you currently have this exchange: >>>> >>>> C -> S: Client Registration Request >>>> C <- S: Client Information Response (with new reg. access token) >>>> >>>> C -> S: Read or Update Request (with client id + reg. access token) >>>> C <- S: Client Information Response >>>> >>>> Do you see the similarity that I see? >>> >>> For clients that use a client secret to authenticate to the token >>> endpoint, your point makes sense, but for clients who would not >>> otherwise have a client secret, it doesn=92t. You end up with a >>> confusing state where you=92re giving somebody a =93client_secret=94 = which >>> is defined in 6790 to be used at the token endpoint but then telling >>> them not to use it at the token endpoint (where they use something >>> else or do=92t use it at all) but to use it at this new endpoint >>> instead. Can you see the confusion point here? I think it=92s only >>> going to get worse as we get more clients that use auth mechanisms >>> that don=92t depend on a shared secret (public key, TLS, etc.).=20 >>> >>> Instead we=92re giving people an OAuth access token to access a >>> protected API, something that OAuth clients ought to know how to do >>> anyway. This mechanism also gives us an opportunity to potentially >>> use the new PoP tokens (once they=92re actually defined) in place of >>> the bearer credential that=92s defined today.=20 >>> >>>> >>>>>> >>>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>>> >>>>>> " The Authorization Server MAY rotate the client's registration >>>>>> access token and/or client credentials (such as a "client_secret")= >>>>>> throughout the lifetime of the client. " >>>>>> >>>>>> You might want to add reasons why the authorization server may wan= t >>>>>> to take this step. >>>>> >>>>> OK, but there's nothing normative here in my view. It's basically u= p >>>>> to the auth server to say "well let's make a new credential". Can y= ou >>>>> suggest text that would clarify this? >>>>> >>>> >>>> What about making the spec simpler by not allowing credential rotati= on? >>>> Rekying is a useful concept under two circumstances, namely >>>> * when they provide a performance improvement (such as it is the cas= e >>>> with session resumption in TLS where you can do an abbreviated hands= hake >>>> without all the heavy public key crypto) >>>> * when the entrophy of the key is exhausted, which typically happens= if >>>> you exceed a number of data packets sent under a given key. Often th= is >>>> is tied to the way how freshness is ensured and the need to avoid >>>> encrypting data with the same initialization vector/nonce twice. >>>> >>>> Neither of these two cases seem to apply here (IMHO). >>> >>> >>> Rekeying the client is useful in a whole lot more cases than these >>> two, and most of them boil down to =93Something seems fishy=94. I thi= nk >>> if anything we need to eventually figure out how to do *more* secret >>> rotation, including a proactive mechanism started by the client (as >>> Brian has mentioned, among others).=20 >>> >>>> >>>> >>>>>> >>>>>> There are also a bit too many SHOULDs in the document. Every time >>>>>> you write SHOULD you have to keep in mind to tell the reader what >>>>>> happens in the other case. For example, in Section Section 1.4.1 >>>>>> you write: >>>>>> >>>>>> " The registration access token SHOULD be rotated only in response= >>>>>> to an update request to the client configuration endpoint, at >>>>>> which point the new registration access token is returned to the >>>>>> client and the old registration access token SHOULD be discarded b= y >>>>>> both parties. " >>>>>> >>>>>> Here the question arises whether you are using the SHOULD to >>>>>> indicate that the authorization server does not always need to >>>>>> rotate the registration access token and if he does then is must >>>>>> only happen in response to an update request or does it indicate >>>>>> that the authorization server could also rotate it in response to >>>>>> other calls? >>>>> >>>>> It's more that the server SHOULD NOT throw out a registration acces= s >>>>> token that a client still thinks is good without some way to >>>>> communicate the new token to the client. Think of it this way, you'= ve >>>>> got the token, the server decides to chuck it on you -- what do you= >>>>> do? You can try calling your READ or UPDATE operations to get the n= ew >>>>> one but no dice, your token is bad. So what we're saying here is no= t >>>>> to throw out the client's only means of finding out if its keys are= >>>>> good anymore. >>>> >>>> I think I got confused with the description of the state management = (as >>>> described in the document). There is some fuzziness. >>>> >>>> Here I would prefer to have either no rekeying (which would make the= >>>> issue go away) or a very deterministic way of rekeying. >>>> >>>> I prefer the former. >>> >>> I=92m not a fan of enforcing permanent credentials on the world. And = we >>> have the same construct with refresh tokens today, for what it=92s wo= rth. >>> >>>> >>>>> >>>>>> >>>>>> Also, in the second line one would wonder why the old registration= >>>>>> access token isn't mandatorily discarded. If there are good >>>>>> reasons, then tell the reader. >>>>> >>>>> We've tried to put requirements on the server discarding tokens in >>>>> the past, but there was significant pushback from providers who use= >>>>> non-revocable time-limited tokens. Maybe they won't be doing that >>>>> here, for the reason above. >>>> >>>> >>>> I wouldn't reflect that in the document. Of course, you can never be= >>>> sure that the implementation really discards any state but for the >>>> purpose of the protocol state machine it is gone. >>>> >>>>> >>>>>> Furthermore, the text in Section 2.2 seems to contract this >>>>>> statement: " If the authorization server includes a new client >>>>>> secret and/or registration access token in its response, the clien= t >>>>>> MUST immediately discard its previous client secret and/or >>>>>> registration access token. " >>>>> >>>>> This is a requirement on the client, not the server, so it's not >>>>> bound by the token lifetime restrictions above. We're telling the >>>>> client to stop using a secret or token after it's been given a new >>>>> one, that's fine. >>>> >>>> OK >>>> >>>>> >>>>>> In Section 2.2 you write: " However, since read operations are >>>>>> intended to be idempotent, the read request itself SHOULD NOT caus= e >>>>>> changes to the client's registered metadata values. " >>>>>> >>>>>> I am wondering whether this SHOULD NOT statement adds a lot of >>>>>> value since you allow the request to change metadata values. >>>>> >>>>> I think you're right, since the metadata values might have changed >>>>> through outside forces since the client last read, and all the >>>>> clients need to be able to deal with that. We can remove that line.= >>>> >>>> OK >>>> >>>>> >>>>>> You also write the security consideration section: " the >>>>>> registration access token MAY be rotated when the developer or >>>>>> client does a read or update operation on the client's client >>>>>> configuration endpoint. " >>>>>> >>>>>> This means that the content of the registration access token may >>>>>> also change with a read operation. >>>>> >>>>> That's correct. >>>>> >>>>>> Terminology: >>>>>> >>>>>> Sometimes you write "Client Information Response" and sometimes >>>>>> "client information response" The same with "Authorization Server"= >>>>>> and "authorization server" >>>>> >>>>> They're all supposed to be lower cased, as is the style in RFC6749.= I >>>>> tried to bump everything down in a previous edit but it looks like = I >>>>> missed some. >>>>> >>>>>> Typo: >>>>>> >>>>>> " Some values in the response, including the "client_secret" and >>>>>> r"egistration_access_token", MAY be ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> different from those in the initial registration response. " >>>>> >>>>> Thanks, noted! >>>>> >>>>>> >>>>>> In Section 2.4 "Client Delete Request" you write: >>>>>> >>>>>> " The authorization server SHOULD immediately invalidate all >>>>>> existing authorization grants and currently-active tokens >>>>>> associated with this client. " >>>>>> >>>>>> Under what circumstances wouldn't the authorization invalidate all= >>>>>> grants and active tokens? >>>>> >>>>> When it's using a non-revocable stateless token and it can't >>>>> physically do that. Too bad 2119 doesn't have MUST IF POSSIBLE or >>>>> equivalent. >>>> >>>> Maybe it would be good to add this information. >>>> >>>> It might also be worthwhile whether this notion of a non-vocable >>>> stateless token actually exists in this context since we are really >>>> talking about the same infrastructure here. This registration manage= ment >>>> mechanism is really very central to the authorization server (unlike= >>>> some other access token mechanisms where we talk about the resource >>>> server, which may be in a different administrative domain even). >>> >>> Why doesn=92t the existing SHOULD cover this? >>> >>>> >>>>> >>>>>> You might also want to say what tokens you are talking about since= >>>>>> there are at least the following tokens around: - access tokens - >>>>>> refresh tokens - registration access tokens - initial access token= >>>>> >>>>> OK, we can add that. >>>>> >>>>>> >>>>>> " If the server does not support the delete method, the server >>>>>> MUST respond with an HTTP 405 Not Supported. " >>>>>> >>>>>> Why aren't you demanding that the server must support this method?= >>>>>> This would essentially mean that there would be some cases where >>>>>> deregistration isn't possible. Of course, there may be the questio= n >>>>>> how important deregistration actually is if the registration >>>>>> automatically expires. >>>>> >>>>> Because delete is not always an easy operation to implement. The >>>>> client should be able to call the endpoint with the DELETE verb and= >>>>> at least know if it's allowed to do that or not. >>>> >>>> Hmmm. I didn't know that the delete method is difficult to implement= =2E >>> >>> Depends on your infrastructure and how things get propagated between >>> components. >>> >>>> >>>>> >>>>>> >>>>>> You write: " If the client does not exist on this server, the >>>>>> server MUST respond with HTTP 401 Unauthorized and the registratio= n >>>>>> access token used to make this request SHOULD be immediately >>>>>> revoked. " >>>>>> >>>>>> If the client does not exist and someone sends a request with a >>>>>> random registration access token I am not sure what exactly you >>>>>> want to revoke here. >>>>> >>>>> It's not the case of a random token, it's the case of a client havi= ng >>>>> been deleted but using an otherwise valid access token. If the >>>>> token's no good, you don't get this far -- you return a 401 as >>>>> defined in RFC6750. >>>> >>>> I guess it might make sense to add this information. >>> >>> It=92s already in there, in the paragraph just before the one you quo= ted: >>> >>> If the registration access token used to make this request is not >>> valid, the server MUST respond with an error as described in OAuth= >>> Bearer Token Usage [RFC6750 ]= =2E >>> >>> >>>> >>>>> >>>>>> >>>>>> In Section 3.1. "Client Information Response" you state the new >>>>>> elements that are returned to the client. While the client_secret >>>>>> has an expires_at field the registration_access_token doesn't. Doe= s >>>>>> the expiry value of the client_secret_expires_at automatically >>>>>> indicate the lifetime of the registration access token? I think >>>>>> so. But what happens if the client_secret is not issued? To make i= t >>>>>> more complicated you write the following text in the security >>>>>> consideration section: >>>>>> >>>>>> " While the client secret can expire, the registration access >>>>>> token SHOULD NOT expire while a client is still actively >>>>>> registered. " >>>>> >>>>> There isn't a separate expiration for the registration access token= >>>>> because it's not supposed to unceremoniously expire on a client. It= >>>>> should be good until it gets rotated out on a future read/update >>>>> operation or the client's registration is no good anymore. >>>> >>>> I think it might be good to have a small section that explains how s= tate >>>> management works. >>> >>> Can you suggest text for this beyond the paragraph that=92s already t= here? >>> >>>>> >>>>>> >>>>>> The IANA consideration section is empty. Wouldn't it be necessary >>>>>> to register 'registration_access_token' and >>>>>> 'registration_client_uri' into the OAuth Dynamic Registration >>>>>> Client Metadata Registry? >>>>> >>>>> No, these are not client metadata. The client can not send these in= a >>>>> registration request, so they don't need to be in there. >>>> >>>> Really? >>>> >>>> I thought that the IANA registry created with Section 5.1 of >>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was meant to = be >>>> used with the Client Registration Request and the Client Registratio= n >>>> Response exchange. The 'registration_access_token' and >>>> 'registration_client_uri' parameters are used in the response. >>>> >>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an inconsiste= ncy: >>>> The protocol interaction should either be >>>> >>>> >>>> C -> AS: Client Registration Request >>>> C <- AS: Client Registration Response >>>> >>>> OR >>>> >>>> C -> AS: Client Registration Request >>>> C <- AS: Client Registration Error Response >>>> >>>> Currently, sometimes the term "Client Registration Response" or "Cli= ent >>>> Information Response" is used. We need to fix this since it spills o= ver >>>> to the management API document as well. >>> >>> Client Information Response and Client Error Response are sub-classes= >>> of Client Registration Response. If that=92s not clear from the curre= nt >>> document, please suggest new wording to make it clearer. >>> >>>> >>>> Also, I noticed that we say that the server MUST support TLS 1.2 RFC= >>>> 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 anymore. >>> >>> Kathleen made a similar comment on dyn-reg and suggested text that >>> we=92ll incorporate (unless there are objections from others on the l= ist). >>> >>>> >>>> In Figure 1 it might be useful to indicate that exchanges A, B, C, a= nd D >>>> are inherited from the dynamic client registration document and only= >>>> step D is enhanced with additional parameters, as described in Secti= on >>>> 3.1. Furthermore, I wonder whether it would make sense to somehow >>>> indicate in the figure that the endpoints are actually part of the >>>> Authorization Server. >>> >>> While they usually are the same in practice, these endpoints might >>> not be part of the Authorization Server =97 they might be part of a >>> separate (but related) service that handles objects of various kinds >>> within a security domain. No reason to tie them together unnecessaril= y.=20 >>> >>> =97 Justin >>> >>> >>>> >>>> Ciao >>>> Hannes >>>> >>>>> >>>>> -- Justin >>>>> >>>> >>>> _______________________________________________ >>>> 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 >=20 --dRisDWCQE65pFvfQIuxemoRgRSJfJxVn6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfCRnAAoJEGhJURNOOiAtxMkH/2S4UNpI8EyaGHuvH28ds2zy G7VzB4ojaPIbOFqUSSSoKxEHuN8ad5OAIhNgznDJG24iRvU9CunggK17xY5LDJzp FkTW359LHnRtzOTvPf+NkX+byRX+qh3Px6P5FPp1dRk9apn5rYLcvVOWlM5iGAt5 BU7QhKs+o+hNArYbKRJVMftQyFq39OG5WqEJCJqNFykogZmFE/maTK10hUXb+Jz3 ScVyFzL7ohJrJAL8O1d8gAfurhkk+4MR5bLSvKLrXzulGZ+aTBdMhXSbaLnTkADu 6VwGltMwZFJIbVA6JoW9q51YqP1isRuaKqQjoipnA4ipdMzyp+WCuOPLmqijWFo= =cQFM -----END PGP SIGNATURE----- --dRisDWCQE65pFvfQIuxemoRgRSJfJxVn6-- From nobody Mon Dec 1 01:27:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2569B1A013B for ; Mon, 1 Dec 2014 01:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKQ90hobvflq for ; Mon, 1 Dec 2014 01:27:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E911A00CD for ; Mon, 1 Dec 2014 01:27:30 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1nOg-1YBXZE07B4-00tgjF; Mon, 01 Dec 2014 10:27:26 +0100 Message-ID: <547C347C.7070908@gmx.net> Date: Mon, 01 Dec 2014 10:27:24 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Richer References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> In-Reply-To: <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Oq8Uf5KQ6Gbv86fKMcMxa20JmX2W4GkkE" X-Provags-ID: V03:K0:DeAL591SuxTy2m2FEruonSER0UyDcRWZQ4m3SJAJinc9YXNtjnH l9r2i/AJk7d04UlYAdPtPBWTXlhDFxdr84lVRJv1bgD05wgYxhBk0BQI+XA7SqxO0oCec2z Fq8Q78HxOk8jsfE+ByeWDWwNKGckbuH+j9UEHc/jY0fyAnsi880Tdcx/re+4ja4TJ+pJjSM q7gLhcwCACVrsgmblfEdA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9HZJwtuW2zY-mbWt7bS0L_RNrI4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 09:27:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Oq8Uf5KQ6Gbv86fKMcMxa20JmX2W4GkkE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, a few comments inline: On 11/26/2014 02:32 PM, Justin Richer wrote: > And by =936790=94 below I obviously mean RFC6749. >=20 > (Note to self, don=92t write working group emails this early in the mor= ning.) >=20 > =97 Justin >=20 > On Nov 26, 2014, at 8:31 AM, Justin Richer > wrote: >=20 >> >> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig >> > wrote: >> >>> Hi Justin, >>> >>> thanks for your quick response. A few remarks below. >>> >>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>> Hannes, thank you for the review. Answers inline. >>>> >>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig >>>> > wrote= : >>>> >>>>> Hi Justin, Mike, John, Maciej, >>>>> >>>>> as part of my shepherd write-up I carefully read through >>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the document is in >>>>> good shape but I have a few minor clarification questions that >>>>> should be resolved before the document goes to the IESG. >>>>> >>>>> In Section 1.4. "Registration Tokens and Client Credentials" you >>>>> explain the different credential types and I was wondering why you >>>>> aren't issuing client_secrets to all clients instead of introducing= >>>>> another credential, the registration access token. While you try to= >>>>> explain the reasons those appear somewhat constructed. For example,= >>>>> you say that "not all types of clients have client credentials" but= >>>>> you are the author of the specification and you can essentially >>>>> decide what to do. The registration access token is essentially the= >>>>> same as the client credential since it is "is uniquely bound to the= >>>>> client identifier". >>>>> >>>>> I believe we have discussed this issue in the past but I don't >>>>> remember what the reasoning was. Can you describe what your design >>>>> rational was (and add it to the document)? >>>> >>>> That's exactly the question this section is trying to answer, and if= >>>> it can be made clearer then please suggest some text that will help >>>> that purpose. The rationale for the registration access token is ver= y >>>> simple: we want to have a means to call the management endpoint in a= >>>> protected manner, and treating the management endpoint as an OAuth >>>> Protected Resource makes a lot of sense. RFC6750 gives us the means >>>> to make an authorized call to an API endpoint, so we're re-using tha= t >>>> instead of trying to invent some other mechanism. Shouldn't we be >>>> helping the world get away from API passwords? >>>> >>>> And it's very true that not every client is going to have a client >>>> secret to use at the token endpoint -- some will have no use of one >>>> (public and implicit clients) and some will be using TLS or >>>> asymmetric keys (JWT assertions, for instance) or other mechanisms t= o >>>> authenticate that don't involve the secret. Instead of forcing these= >>>> clients to use a client secret for one new endpoint, or forcing that= >>>> endpoint to potentially support the infinite number of client >>>> authentication mechanisms, we decided to just use OAuth. These are >>>> OAuth clients, remember -- they will *all* have the ability to send >>>> OAuth tokens to a protected resource already built in. >>>> >>> >>> Here is the point I don't quite get: the registration access token is= >>> essentially the same as a client secret. You as a specification autho= r >>> essentially decides whether clients will get a client secret or a >>> registration access token. It is under your control. >>> >>> To be more specific, here is what you could have done: >>> >>> C -> S: Client Registration Request >>> C <- S: Client Information Response (with new client secret) >>> >>> C -> S: Read or Update Request (with client id/client secret) >>> C <- S: Client Information Response >>> >>> Instead, you currently have this exchange: >>> >>> C -> S: Client Registration Request >>> C <- S: Client Information Response (with new reg. access token) >>> >>> C -> S: Read or Update Request (with client id + reg. access token) >>> C <- S: Client Information Response >>> >>> Do you see the similarity that I see? >> >> For clients that use a client secret to authenticate to the token >> endpoint, your point makes sense, but for clients who would not >> otherwise have a client secret, it doesn=92t. You end up with a >> confusing state where you=92re giving somebody a =93client_secret=94 w= hich >> is defined in 6790 to be used at the token endpoint but then telling >> them not to use it at the token endpoint (where they use something >> else or do=92t use it at all) but to use it at this new endpoint >> instead. Can you see the confusion point here? I think it=92s only goi= ng >> to get worse as we get more clients that use auth mechanisms that >> don=92t depend on a shared secret (public key, TLS, etc.).=20 >> >> Instead we=92re giving people an OAuth access token to access a >> protected API, something that OAuth clients ought to know how to do >> anyway. This mechanism also gives us an opportunity to potentially use= >> the new PoP tokens (once they=92re actually defined) in place of the >> bearer credential that=92s defined today.=20 >> I believe I now understand your line of argument. You are saying that re-using the client secret for this purpose will confuse developers since the client credential is used in other places as well. So, the confusion could then be: * Client starts the dynamic client registration exchange without a client secret. * Later than that exchange he gets a client secret, which is supposed to be used for the dynamic client registration management only * A developer might think that he can now also use that client secret with anything else as well where a client secret can be used. The questions are now: a) Is this potential confusion real or just imagined? b) Wouldn't this be desired behaviour to begin with? If it is a real concern and if you don=92t' want to have that behaviour then maybe you want to motivate the design decision in that direction in Section 1.4. >>> >>>>> >>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>> >>>>> " The Authorization Server MAY rotate the client's registration >>>>> access token and/or client credentials (such as a "client_secret") >>>>> throughout the lifetime of the client. " >>>>> >>>>> You might want to add reasons why the authorization server may want= >>>>> to take this step. >>>> >>>> OK, but there's nothing normative here in my view. It's basically up= >>>> to the auth server to say "well let's make a new credential". Can yo= u >>>> suggest text that would clarify this? >>>> >>> >>> What about making the spec simpler by not allowing credential rotatio= n? >>> Rekying is a useful concept under two circumstances, namely >>> * when they provide a performance improvement (such as it is the case= >>> with session resumption in TLS where you can do an abbreviated handsh= ake >>> without all the heavy public key crypto) >>> * when the entrophy of the key is exhausted, which typically happens = if >>> you exceed a number of data packets sent under a given key. Often thi= s >>> is tied to the way how freshness is ensured and the need to avoid >>> encrypting data with the same initialization vector/nonce twice. >>> >>> Neither of these two cases seem to apply here (IMHO). >> >> >> Rekeying the client is useful in a whole lot more cases than these >> two, and most of them boil down to =93Something seems fishy=94. I thin= k if >> anything we need to eventually figure out how to do *more* secret >> rotation, including a proactive mechanism started by the client (as >> Brian has mentioned, among others).=20 >> The alternative to rekeying (or secret rotation) inside the dynamic client registration management protocol is to actually re-start the protocol run from scratch. To me it is not obvious whether the added complexity for credential rotation is worth the effort given the alternative. >>> >>> >>>>> >>>>> There are also a bit too many SHOULDs in the document. Every time >>>>> you write SHOULD you have to keep in mind to tell the reader what >>>>> happens in the other case. For example, in Section Section 1.4.1 >>>>> you write: >>>>> >>>>> " The registration access token SHOULD be rotated only in response >>>>> to an update request to the client configuration endpoint, at >>>>> which point the new registration access token is returned to the >>>>> client and the old registration access token SHOULD be discarded by= >>>>> both parties. " >>>>> >>>>> Here the question arises whether you are using the SHOULD to >>>>> indicate that the authorization server does not always need to >>>>> rotate the registration access token and if he does then is must >>>>> only happen in response to an update request or does it indicate >>>>> that the authorization server could also rotate it in response to >>>>> other calls? >>>> >>>> It's more that the server SHOULD NOT throw out a registration access= >>>> token that a client still thinks is good without some way to >>>> communicate the new token to the client. Think of it this way, you'v= e >>>> got the token, the server decides to chuck it on you -- what do you >>>> do? You can try calling your READ or UPDATE operations to get the ne= w >>>> one but no dice, your token is bad. So what we're saying here is not= >>>> to throw out the client's only means of finding out if its keys are >>>> good anymore. >>> >>> I think I got confused with the description of the state management (= as >>> described in the document). There is some fuzziness. >>> >>> Here I would prefer to have either no rekeying (which would make the >>> issue go away) or a very deterministic way of rekeying. >>> >>> I prefer the former. >> >> I=92m not a fan of enforcing permanent credentials on the world. And w= e >> have the same construct with refresh tokens today, for what it=92s wor= th. It is only permanent in the sense of a full dynamic client registration management protocol run. >> >>> >>>> >>>>> >>>>> Also, in the second line one would wonder why the old registration >>>>> access token isn't mandatorily discarded. If there are good >>>>> reasons, then tell the reader. >>>> >>>> We've tried to put requirements on the server discarding tokens in >>>> the past, but there was significant pushback from providers who use >>>> non-revocable time-limited tokens. Maybe they won't be doing that >>>> here, for the reason above. >>> >>> >>> I wouldn't reflect that in the document. Of course, you can never be >>> sure that the implementation really discards any state but for the >>> purpose of the protocol state machine it is gone. >>> >>>> >>>>> Furthermore, the text in Section 2.2 seems to contract this >>>>> statement: " If the authorization server includes a new client >>>>> secret and/or registration access token in its response, the client= >>>>> MUST immediately discard its previous client secret and/or >>>>> registration access token. " >>>> >>>> This is a requirement on the client, not the server, so it's not >>>> bound by the token lifetime restrictions above. We're telling the >>>> client to stop using a secret or token after it's been given a new >>>> one, that's fine. >>> >>> OK >>> >>>> >>>>> In Section 2.2 you write: " However, since read operations are >>>>> intended to be idempotent, the read request itself SHOULD NOT cause= >>>>> changes to the client's registered metadata values. " >>>>> >>>>> I am wondering whether this SHOULD NOT statement adds a lot of >>>>> value since you allow the request to change metadata values. >>>> >>>> I think you're right, since the metadata values might have changed >>>> through outside forces since the client last read, and all the >>>> clients need to be able to deal with that. We can remove that line. >>> >>> OK >>> >>>> >>>>> You also write the security consideration section: " the >>>>> registration access token MAY be rotated when the developer or >>>>> client does a read or update operation on the client's client >>>>> configuration endpoint. " >>>>> >>>>> This means that the content of the registration access token may >>>>> also change with a read operation. >>>> >>>> That's correct. >>>> >>>>> Terminology: >>>>> >>>>> Sometimes you write "Client Information Response" and sometimes >>>>> "client information response" The same with "Authorization Server" >>>>> and "authorization server" >>>> >>>> They're all supposed to be lower cased, as is the style in RFC6749. = I >>>> tried to bump everything down in a previous edit but it looks like I= >>>> missed some. >>>> >>>>> Typo: >>>>> >>>>> " Some values in the response, including the "client_secret" and >>>>> r"egistration_access_token", MAY be ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> different from those in the initial registration response. " >>>> >>>> Thanks, noted! >>>> >>>>> >>>>> In Section 2.4 "Client Delete Request" you write: >>>>> >>>>> " The authorization server SHOULD immediately invalidate all >>>>> existing authorization grants and currently-active tokens >>>>> associated with this client. " >>>>> >>>>> Under what circumstances wouldn't the authorization invalidate all >>>>> grants and active tokens? >>>> >>>> When it's using a non-revocable stateless token and it can't >>>> physically do that. Too bad 2119 doesn't have MUST IF POSSIBLE or >>>> equivalent. >>> >>> Maybe it would be good to add this information. >>> >>> It might also be worthwhile whether this notion of a non-vocable >>> stateless token actually exists in this context since we are really >>> talking about the same infrastructure here. This registration managem= ent >>> mechanism is really very central to the authorization server (unlike >>> some other access token mechanisms where we talk about the resource >>> server, which may be in a different administrative domain even). >> >> Why doesn=92t the existing SHOULD cover this? Because the should does not explain when to revoke the grants/tokens and when not to do it. You wrote it in this email (in context of these non-revocable tokens) but how should an implementer know when he reads through the draft? The problem is really about assumptions being made that are not explained further. For example, the assumption that there are tokens that are not revocable and the implications that result from those on the design of the protocol (potentially at multiple places in the document). >> >>> >>>> >>>>> You might also want to say what tokens you are talking about since >>>>> there are at least the following tokens around: - access tokens - >>>>> refresh tokens - registration access tokens - initial access token >>>> >>>> OK, we can add that. >>>> >>>>> >>>>> " If the server does not support the delete method, the server >>>>> MUST respond with an HTTP 405 Not Supported. " >>>>> >>>>> Why aren't you demanding that the server must support this method? >>>>> This would essentially mean that there would be some cases where >>>>> deregistration isn't possible. Of course, there may be the question= >>>>> how important deregistration actually is if the registration >>>>> automatically expires. >>>> >>>> Because delete is not always an easy operation to implement. The >>>> client should be able to call the endpoint with the DELETE verb and >>>> at least know if it's allowed to do that or not. >>> >>> Hmmm. I didn't know that the delete method is difficult to implement.= >> >> Depends on your infrastructure and how things get propagated between >> components. There are a number of unstated assumptions here that would be worthwhile to point out. >> >>> >>>> >>>>> >>>>> You write: " If the client does not exist on this server, the >>>>> server MUST respond with HTTP 401 Unauthorized and the registration= >>>>> access token used to make this request SHOULD be immediately >>>>> revoked. " >>>>> >>>>> If the client does not exist and someone sends a request with a >>>>> random registration access token I am not sure what exactly you >>>>> want to revoke here. >>>> >>>> It's not the case of a random token, it's the case of a client havin= g >>>> been deleted but using an otherwise valid access token. If the >>>> token's no good, you don't get this far -- you return a 401 as >>>> defined in RFC6750. >>> >>> I guess it might make sense to add this information. >> >> It=92s already in there, in the paragraph just before the one you quot= ed: >> >> If the registration access token used to make this request is not >> valid, the server MUST respond with an error as described in OAuth >> Bearer Token Usage [RFC6750 ].= >> But the argument that you provided is for "the case of a client having been deleted but using an otherwise valid access token" but the text you cite talks about the registration access token not being valid. Those appear to be two different cases. >> >>> >>>> >>>>> >>>>> In Section 3.1. "Client Information Response" you state the new >>>>> elements that are returned to the client. While the client_secret >>>>> has an expires_at field the registration_access_token doesn't. Does= >>>>> the expiry value of the client_secret_expires_at automatically >>>>> indicate the lifetime of the registration access token? I think >>>>> so. But what happens if the client_secret is not issued? To make it= >>>>> more complicated you write the following text in the security >>>>> consideration section: >>>>> >>>>> " While the client secret can expire, the registration access >>>>> token SHOULD NOT expire while a client is still actively >>>>> registered. " >>>> >>>> There isn't a separate expiration for the registration access token >>>> because it's not supposed to unceremoniously expire on a client. It >>>> should be good until it gets rotated out on a future read/update >>>> operation or the client's registration is no good anymore. >>> >>> I think it might be good to have a small section that explains how st= ate >>> management works. >> >> Can you suggest text for this beyond the paragraph that=92s already th= ere? Yes, I can do that. If you could ship a new update then I can read through the entire document again and figure out how to create a state machine. If you, of course, get rid of this credential rotation then I don't have to do it though. >> >>>> >>>>> >>>>> The IANA consideration section is empty. Wouldn't it be necessary >>>>> to register 'registration_access_token' and >>>>> 'registration_client_uri' into the OAuth Dynamic Registration >>>>> Client Metadata Registry? >>>> >>>> No, these are not client metadata. The client can not send these in = a >>>> registration request, so they don't need to be in there. >>> >>> Really? >>> >>> I thought that the IANA registry created with Section 5.1 of >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was meant to b= e >>> used with the Client Registration Request and the Client Registration= >>> Response exchange. The 'registration_access_token' and >>> 'registration_client_uri' parameters are used in the response. >>> >>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an inconsisten= cy: >>> The protocol interaction should either be >>> >>> >>> C -> AS: Client Registration Request >>> C <- AS: Client Registration Response >>> >>> OR >>> >>> C -> AS: Client Registration Request >>> C <- AS: Client Registration Error Response >>> >>> Currently, sometimes the term "Client Registration Response" or "Clie= nt >>> Information Response" is used. We need to fix this since it spills ov= er >>> to the management API document as well. >> >> Client Information Response and Client Error Response are sub-classes >> of Client Registration Response. If that=92s not clear from the curren= t >> document, please suggest new wording to make it clearer. As a shepherd I read through both documents in detail and I didn't figure that out. That gives me reasons to believe that others wouldn't figure that out either. I would make the change already in Figure 1 of Dynamic Client Registration Protocol document. +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- Software Statement (OPTIONAL) | | v v +-----------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client or | | Registration | | Developer |<-(D)- Client Registration Response---| Endpoint | | | +---------------+ +-----------+ Client Registration Response:=3D Client Information Response OR Client Error Response Same change to Figure 1 in the dynamic client registration management document. You could even indicate in the figure which parts are already specified in the dynamic client registration spec and which are added via the dynamic client registration management doc. >> >>> >>> Also, I noticed that we say that the server MUST support TLS 1.2 RFC >>> 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 anymore. >> >> Kathleen made a similar comment on dyn-reg and suggested text that >> we=92ll incorporate (unless there are objections from others on the li= st). Ack. >> >>> >>> In Figure 1 it might be useful to indicate that exchanges A, B, C, an= d D >>> are inherited from the dynamic client registration document and only >>> step D is enhanced with additional parameters, as described in Sectio= n >>> 3.1. Furthermore, I wonder whether it would make sense to somehow >>> indicate in the figure that the endpoints are actually part of the >>> Authorization Server. >> >> While they usually are the same in practice, these endpoints might not= >> be part of the Authorization Server =97 they might be part of a separa= te >> (but related) service that handles objects of various kinds within a >> security domain. No reason to tie them together unnecessarily.=20 You can state that someone in the text but endpoints by itself don't exist since they have to be at some server. Even if the endpoints are in separate boxes there needs to be a close cooperation between the two since otherwise we create new interoperability challenges. Ciao Hannes >> >> =97 Justin >> >> >>> >>> Ciao >>> Hannes >>> >>>> >>>> -- Justin >>>> >>> >>> _______________________________________________ >>> 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 --Oq8Uf5KQ6Gbv86fKMcMxa20JmX2W4GkkE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfDR8AAoJEGhJURNOOiAtAFYIAJwBJq5qfx6+qox7b3lWhh6v +y7pQe2znYbpVyXG/2PmrB0aeDigrBtW/063m4rhDlN+RVpaia3KdWXhnqj/4n+e YvKDwQ9lCZF67xTK7MfTkB0Z7LMJrrwIT/kVSS8NO58YBIeiW3mEBAuoLEl2kc4g P8VuX366qqPLzPcdOb7BQV8J4VqjEtT5GTle1i74teAi3YU4wHtP+GGYIcMpjc78 h7JVQSPAE/l9GPa3Oh5sM5DFLccYvS7Q4echvOA+Z4cIijepzJCwkogddgFp3ZBJ m/3eORUjgFaFmqT+qS2DHk7t3okouieR6o7OEiNggN3YAbKqaDpRTo5u93ZXM5Y= =pWSR -----END PGP SIGNATURE----- --Oq8Uf5KQ6Gbv86fKMcMxa20JmX2W4GkkE-- From nobody Mon Dec 1 01:38:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5E1A1B1F for ; Mon, 1 Dec 2014 01:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ierlAVDV-IMq for ; Mon, 1 Dec 2014 01:38:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807E91A1B1E for ; Mon, 1 Dec 2014 01:38:37 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MTwYX-1XVHsg1qdd-00Qjed for ; Mon, 01 Dec 2014 10:38:35 +0100 Message-ID: <547C371A.6040507@gmx.net> Date: Mon, 01 Dec 2014 10:38:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="un7H9BFLXpDK9JSSpOSujU2Ko5LQi8p8X" X-Provags-ID: V03:K0:ve3c4Y5p9omoS1cdLBYj2YSeNJwIQx8C17kq9IrF5GCHpGMM8vu eygrVOQk83MQ9idP/YZ77L2OGXxBRyz4yBqkpoUSfnjzfdW1F4OjHgLv6PSqm9xxVRtmaib tOZZz6Q6PV42rtY6REUBYBsJCq1KJpfson7BBVpOTR5EP6t4LFwFpjLRUV+FbsspltjfCYE 0fT/jKxb5T7KPZO1sv7PA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nor_dstvK_c7QoDw__zsMhRgH-c Subject: [OAUTH-WG] WGLC on "OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 09:38:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --un7H9BFLXpDK9JSSpOSujU2Ko5LQi8p8X Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, as discussed at the last IETF meeting we are also starting a working group last call for the token introspection specification. Here is the document: http://tools.ietf.org/html/draft-ietf-oauth-introspection-01 Please send you comments to the OAuth mailing list by December 15, 2014. Ciao Hannes & Derek --un7H9BFLXpDK9JSSpOSujU2Ko5LQi8p8X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfDcaAAoJEGhJURNOOiAtDcMH/2TDm/VWcjbrdnhttFK+LA+W CMde2tiSVIpCa+u/8I30QJgwLG9CDuByjKYBTz8qxOkXQuvmPeoWT3Zq9XJILIyS dpNDFl9mkwDMrN9eAaK2SXSxTvPQSU74NZvMHzM7B9nS+brtHb5lJryxh8NexuqC vuwc5gz06XRTdenHmHj2LyBbzpLmGnaoOl+IxzH8vaX8T/nSl1qjjJwzqDENCRxv nVDZ5KUC1VEfmiN2NEv4JARRxRN3QXb3UML5fPTfZRA16q6BYkKT//mtchRPTsd7 U75rVj/4QmABgLqYUKH4rSIMApnNBF73YnUYPmGAaP5HWIYEPo88k+kHj/EG4qY= =B/TG -----END PGP SIGNATURE----- --un7H9BFLXpDK9JSSpOSujU2Ko5LQi8p8X-- From nobody Mon Dec 1 02:56:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E470E1A1B36 for ; Mon, 1 Dec 2014 02:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZPgUzUM4SWz for ; Mon, 1 Dec 2014 02:56:34 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254B21A1B35 for ; Mon, 1 Dec 2014 02:56:34 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so13679239wgh.30 for ; Mon, 01 Dec 2014 02:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QfrhXgcmklJf46VjY3fXaWmKpmZ4sL5Bv+ILGtXOR+I=; b=xonyafRhWbGl2VFzCUp3Su5CYUEL4moDUlosMFouMD6Gknt4zVLdKmqroyJHTKTLXl lVo5FzKQoa39/Aa3J3HNH/G1fOQF/z+nEHkoHfbNmbajU5rUiBzMxGw5rA6bbaHJlONh 624tYdLgOBCdPL4ggdh8LGMJAcCqay8Rjj3mn5Su9lZkFrXuqXCnF78b4JDWVLAc57L9 9WISNaFUfqwGB2Bcrsuoi71peKQDXheBeYBPzdrRt+y4t2d89y9HBrEnZuCqn7Cx4fAm NnilDY3jN708rSI1N4ewNNl75R7KMXvLvPMIaNs8k9QVcNT9eFOy8Y3vba/YoPHnjlAI tvnw== X-Received: by 10.180.88.33 with SMTP id bd1mr81977634wib.10.1417431392939; Mon, 01 Dec 2014 02:56:32 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id fk12sm7369126wic.6.2014.12.01.02.56.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 02:56:32 -0800 (PST) Message-ID: <547C495F.1010402@gmail.com> Date: Mon, 01 Dec 2014 10:56:31 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20141201024133.16302.20230.idtracker@ietfa.amsl.com> In-Reply-To: <20141201024133.16302.20230.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wqJ_Y4MrNyoJN-EX-0rccwtXBno Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 10:56:36 -0000 Hi Justin Nicely written text, as usual. Few comments: - I haven't found a reference to a data format of POST requests. I'm presuming it is going to be a form payload (would mean the server code can write more or less the same code dealing with POST & GET queries) ? - consider directly specifying an optional 'client_ip' property - consider adding an optional request_method (or request_verb) hint, a given scope can be restricted to say GET only, can be useful when a protected resource is written to support GET and POST over the same resource_id URI; The text that the endpoint may support other parameters (such a client ip address) covers the last 2 parameters, but I guess it would be more inter-operable to 'promote' the parameters that may be of general use. Thanks, Sergey On 01/12/14 02:41, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-01.txt > Pages : 10 > Date : 2014-11-30 > > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Dec 1 02:58:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4581A1B38 for ; Mon, 1 Dec 2014 02:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78i6NJezfYwL for ; Mon, 1 Dec 2014 02:58:02 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1493B1A1B35 for ; Mon, 1 Dec 2014 02:58:02 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so5479634wgh.22 for ; Mon, 01 Dec 2014 02:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u7U+HcB2eE6rYy9up3GrDMzx7Nk45drlplrTM5rE/jY=; b=QBnn3jbKSBz255dBpvzhjU8dV+oKTcFus/uuq7vhQezmxzkhMsQvoSVn6JgtvMfMj6 fs8E8mJy9FwxV0sD2Nz4C+iwwTL4OepPYQUdFzNjKaSZbeMTrxA/g9aDUXK42a7fW7pQ xcpuSU1ys5bAGUxjuJepbJxoXUWo1AWSLEB9dEYIpxz2RHh/tN0aJ66//jTFsobIE/D+ mWCCg87zhfx6D1/CUVxfoLXtnTVRVdlTVjKFf0xgGKmp/1SbmAyiu4fw+xr0wrcVUA6O Q2ccTwZcsf4v0MQ2BTN4f6u6nNonSz3NhGKMPmyqJ/mZtj8PsKOAS7YdhxVJrPMjqeQw 820A== X-Received: by 10.194.62.144 with SMTP id y16mr37299503wjr.117.1417431480844; Mon, 01 Dec 2014 02:58:00 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id j2sm27072994wjs.28.2014.12.01.02.57.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 02:58:00 -0800 (PST) Message-ID: <547C49B7.90805@gmail.com> Date: Mon, 01 Dec 2014 10:57:59 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20141201024133.16302.20230.idtracker@ietfa.amsl.com> <547C495F.1010402@gmail.com> In-Reply-To: <547C495F.1010402@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/J26raH4vpEfCHTeyD5DOqy21is4 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 10:58:04 -0000 On 01/12/14 10:56, Sergey Beryozkin wrote: > Hi Justin > > Nicely written text, as usual. > Few comments: > - I haven't found a reference to a data format of POST requests. > I'm presuming it is going to be a form payload (would mean the server > code can write more or less the same code dealing with POST & GET > queries) ? Oops :-), sorry, did not scroll down to the example in the text Thanks, Sergey > - consider directly specifying an optional 'client_ip' property > - consider adding an optional request_method (or request_verb) hint, a > given scope can be restricted to say GET only, can be useful when a > protected resource is written to support GET and POST over the same > resource_id URI; > > The text that the endpoint may support other parameters (such a client > ip address) covers the last 2 parameters, but I guess it would be more > inter-operable to 'promote' the parameters that may be of general use. > > Thanks, Sergey > > > > > On 01/12/14 02:41, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> >> Title : OAuth 2.0 Token Introspection >> Author : Justin Richer >> Filename : draft-ietf-oauth-introspection-01.txt >> Pages : 10 >> Date : 2014-11-30 >> >> Abstract: >> This specification defines a method for a protected resource to query >> an OAuth 2.0 authorization server to determine the active state of an >> OAuth 2.0 token and to determine meta-information about this token. >> OAuth 2.0 deployments can use this method to convey information about >> the authorization context of the token from the authorization server >> to the protected resource. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-introspection-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From nobody Mon Dec 1 03:09:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74D1A1B3F for ; Mon, 1 Dec 2014 03:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CirVoeU8JAK for ; Mon, 1 Dec 2014 03:09:28 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178971A1B37 for ; Mon, 1 Dec 2014 03:09:24 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so13849342wgh.27 for ; Mon, 01 Dec 2014 03:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=N7d0twz4NMpgHHLAm4o5MQBu9sGWjZqm66CFIO7Dodw=; b=FIa+rNRZbvnVWX2SaYS3sOsPkYDNRkgvu/2Oo4rc1qvAnNshBqXeLFkQB9X28667TK dNbsbmRXJZcV8Ed6PQ8ZmBCU2bxWcMsNlEGlU3abTTk+7/okGFC1t16OxjzVgq29ze8V i7oFaDZQ3Em+1o6hX+B6fvIbJb8D5KfdGOG8SJu9RLxNM35nB8gYwVhzlltpDZ42I2oc KtsVShi7CDyJRw7Qraa+QXDfbN/99Ud9jPbAHwUP86tCZshE/SO8xw5HhSj8tUotjphy YZwggjZhbg17axN3d+7llBLexW/rCyJc8qlUqpZZs2eC2cw5k3aAFma3iSAqNHA4OPsz sopw== X-Received: by 10.194.2.164 with SMTP id 4mr25280647wjv.55.1417432162711; Mon, 01 Dec 2014 03:09:22 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id gf6sm14306186wjc.11.2014.12.01.03.09.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 03:09:21 -0800 (PST) Message-ID: <547C4C60.50008@gmail.com> Date: Mon, 01 Dec 2014 11:09:20 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20141201024133.16302.20230.idtracker@ietfa.amsl.com> <547C495F.1010402@gmail.com> In-Reply-To: <547C495F.1010402@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MWjPUnRpo7jWbMumnP6KMmUr370 Subject: [OAUTH-WG] Access token response in application/jwt format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 11:09:35 -0000 Hi OIDC UserInfo endpoint supports returning UserInfo directly in JSON or JWS and/or JWE encoded. It is not only useful for OIDC RP clients but also allows for supporting a proper HTTP content negotiation, example, the implementation of OIDC UserInfo endpoint has a better choice of where an optional JWE/JWS encoding can be done, directly in the code or via the filters reacting to HTTP Accept. IMHO it would be good to get it supported directly in OAuth2 token responses too. Among other thing it would also help with making the whole JOSE effort more popular. Just an idea, I do not expect any action from the group, but hopefully it will be reviewed over time Sergey From nobody Mon Dec 1 03:36:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1791A1B49 for ; Mon, 1 Dec 2014 03:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smvZZHwey37c for ; Mon, 1 Dec 2014 03:36:09 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDBA1A1B47 for ; Mon, 1 Dec 2014 03:36:07 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-54-547c52a50f10 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9F.21.03762.6A25C745; Mon, 1 Dec 2014 06:36:06 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB1Ba5Qr016257; Mon, 1 Dec 2014 06:36:05 -0500 Received: from [IPv6:2607:fb90:2402:7470:0:44:6067:c801] (ma52536d0.tmodns.net [208.54.37.165]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB1Ba3a8022634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Dec 2014 06:36:04 -0500 Date: Mon, 01 Dec 2014 06:36:01 -0500 Message-ID: Importance: normal From: Justin Richer To: Sergey Beryozkin , oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1443392620913940" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrLssqCbEoO80i8XJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mr7MnstY0BdSsbP3OXMD44PALkZODgkBE4mH C0+xQ9hiEhfurWfrYuTiEBJYzCRxbf10FpCEkMAGRome2SkQiQtMEneP/mYGSbAIqEosO36e DcQWFvCUWHJ6L1gDr4CbxPcZ54BsDg5OASGJrl0SIGE2oPLpa1qYQGwRAWuJG4+nM0KUC0qc nPkErJVZIFRi5//p7BMYeWchSc1CkoKw1SX+zLvEDGErSkzpfggU5wCy1SSWtSohCy9gZFvF KJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRHKKSPDsY3xxUOsQowMGoxMMrMb86 RIg1say4MvcQoyQHk5Io79LAmhAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxvvYFyvCmJlVWp RfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvH0gQwWLUtNTK9Iyc0oQ0kwcnCDD eYCGh4HU8BYXJOYWZ6ZD5E8xKkqJ87KBJARAEhmleXC9sBTyilEc6BVhXilgQhHiAaYfuO5X QIOZgAYzNFeCDC5JREhJNTDuNHo1jTXlvFDIjEsJEgU5B9oZLrpatrpZGr4Mqj28OTQ+b9pM uVPmbz1ezzi0LuLUqaC4A3LOr3+XBX/7z729LNd0b3qkLLPI17X5Cu0H3q3L3Nupf/L87J8T L9qJdp9s6Tx7YmP34eiO8Fetl3oSj0cev2TXHrXt8VteHpuExRFJCrvi1u9SYinOSDTUYi4q TgQAE6zd8/wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hX5mEJWU1bF1DFZs-j2xuhcUu_I Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 11:36:13 -0000 ----_com.android.email_1443392620913940 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T2gsIHRoYW5rcywgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSBleHBsaWNpdGx5IHN0YXRlZCEgWWVz LCBpdCdzIGZvcm0gcGFyYW1ldGVycy7CoAoKCi0tIEp1c3RpbgoKLyBTZW50IGZyb20gbXkgcGhv bmUgLwoKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogU2VyZ2V5IEJl cnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb20+IApEYXRlOjEyLzAxLzIwMTQgIDU6NTcgQU0g IChHTVQtMDU6MDApIApUbzogb2F1dGhAaWV0Zi5vcmcgCkNjOiAgClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtaW50cm9zcGVjdGlvbi0wMS50eHQg CgpPbiAwMS8xMi8xNCAxMDo1NiwgU2VyZ2V5IEJlcnlvemtpbiB3cm90ZToKPiBIaSBKdXN0aW4K Pgo+IE5pY2VseSB3cml0dGVuIHRleHQsIGFzIHVzdWFsLgo+IEZldyBjb21tZW50czoKPiAtIEkg aGF2ZW4ndCBmb3VuZCBhIHJlZmVyZW5jZSB0byBhIGRhdGEgZm9ybWF0IG9mIFBPU1QgcmVxdWVz dHMuCj4gSSdtIHByZXN1bWluZyBpdCBpcyBnb2luZyB0byBiZSBhIGZvcm0gcGF5bG9hZCAod291 bGQgbWVhbiB0aGUgc2VydmVyCj4gY29kZSBjYW4gd3JpdGUgbW9yZSBvciBsZXNzIHRoZSBzYW1l IGNvZGUgZGVhbGluZyB3aXRoIFBPU1QgJiBHRVQKPiBxdWVyaWVzKSA/Ck9vcHMgOi0pLCBzb3Jy eSwgZGlkIG5vdCBzY3JvbGwgZG93biB0byB0aGUgZXhhbXBsZSBpbiB0aGUgdGV4dAoKVGhhbmtz LCBTZXJnZXkKPiAtIGNvbnNpZGVyIGRpcmVjdGx5IHNwZWNpZnlpbmcgYW4gb3B0aW9uYWwgJ2Ns aWVudF9pcCcgcHJvcGVydHkKPiAtIGNvbnNpZGVyIGFkZGluZyBhbiBvcHRpb25hbCByZXF1ZXN0 X21ldGhvZCAob3IgcmVxdWVzdF92ZXJiKSBoaW50LCBhCj4gZ2l2ZW4gc2NvcGUgY2FuIGJlIHJl c3RyaWN0ZWQgdG8gc2F5IEdFVCBvbmx5LCBjYW4gYmUgdXNlZnVsIHdoZW4gYQo+IHByb3RlY3Rl ZCByZXNvdXJjZSBpcyB3cml0dGVuIHRvIHN1cHBvcnQgR0VUIGFuZCBQT1NUIG92ZXIgdGhlIHNh bWUKPiByZXNvdXJjZV9pZCBVUkk7Cj4KPiBUaGUgdGV4dCB0aGF0IHRoZSBlbmRwb2ludCBtYXkg c3VwcG9ydCBvdGhlciBwYXJhbWV0ZXJzIChzdWNoIGEgY2xpZW50Cj4gaXAgYWRkcmVzcykgY292 ZXJzIHRoZSBsYXN0IDIgcGFyYW1ldGVycywgYnV0IEkgZ3Vlc3MgaXQgd291bGQgYmUgbW9yZQo+ IGludGVyLW9wZXJhYmxlIHRvICdwcm9tb3RlJyB0aGUgcGFyYW1ldGVycyB0aGF0IG1heSBiZSBv ZiBnZW5lcmFsIHVzZS4KPgo+IFRoYW5rcywgU2VyZ2V5Cj4KPgo+Cj4KPiBPbiAwMS8xMi8xNCAw Mjo0MSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOgo+Pgo+PiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMKPj4g ZGlyZWN0b3JpZXMuCj4+ICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgV2ViIEF1 dGhvcml6YXRpb24gUHJvdG9jb2wgV29ya2luZwo+PiBHcm91cCBvZiB0aGUgSUVURi4KPj4KPj4g ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogT0F1dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb24K Pj4gICAgICAgICAgQXV0aG9yICAgICAgICAgIDogSnVzdGluIFJpY2hlcgo+PiAgICAgRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1vYXV0aC1pbnRyb3NwZWN0aW9uLTAxLnR4dAo+PiAgICAg UGFnZXMgICAgICAgICAgIDogMTAKPj4gICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMTEtMzAK Pj4KPj4gQWJzdHJhY3Q6Cj4+ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG1ldGhv ZCBmb3IgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgdG8gcXVlcnkKPj4gICAgIGFuIE9BdXRoIDIuMCBh dXRob3JpemF0aW9uIHNlcnZlciB0byBkZXRlcm1pbmUgdGhlIGFjdGl2ZSBzdGF0ZSBvZiBhbgo+ PiAgICAgT0F1dGggMi4wIHRva2VuIGFuZCB0byBkZXRlcm1pbmUgbWV0YS1pbmZvcm1hdGlvbiBh Ym91dCB0aGlzIHRva2VuLgo+PiAgICAgT0F1dGggMi4wIGRlcGxveW1lbnRzIGNhbiB1c2UgdGhp cyBtZXRob2QgdG8gY29udmV5IGluZm9ybWF0aW9uIGFib3V0Cj4+ICAgICB0aGUgYXV0aG9yaXph dGlvbiBjb250ZXh0IG9mIHRoZSB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgo+ PiAgICAgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZS4KPj4KPj4KPj4KPj4gVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtaW50cm9zcGVjdGlvbi8KPj4KPj4g VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6Cj4+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtaW50cm9zcGVjdGlvbi0wMQo+Pgo+ PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6Cj4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtaW50cm9zcGVj dGlvbi0wMQo+Pgo+Pgo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZgo+PiBzdWJtaXNzaW9uCj4+IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuCj4+ Cj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoKPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KPj4KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gT0F1dGggbWFpbGluZyBs aXN0Cj4+IE9BdXRoQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgKPj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK ----_com.android.email_1443392620913940 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5PaCwgdGhhbmtzLCB0aGF0 IGlzIHN1cHBvc2VkIHRvIGJlIGV4cGxpY2l0bHkgc3RhdGVkISBZZXMsIGl0J3MgZm9ybSBwYXJh bWV0ZXJzLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZTo5cHgiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyAiPi0tIEp1c3Rp bjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyAiPjxicj48L2Rpdj48ZGl2IHN0eWxl PSJmb250LXNpemU6IDlweDsgIj4vIFNlbnQgZnJvbSBteSBwaG9uZSAvPC9kaXY+PC9kaXY+PGRp dj48L2Rpdj48ZGl2PjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0tLTxicj5Gcm9tOiBTZXJnZXkgQmVyeW96a2luICZsdDtzYmVyeW96a2luQGdtYWlsLmNvbSZn dDsgPGJyPkRhdGU6MTIvMDEvMjAxNCAgNTo1NyBBTSAgKEdNVC0wNTowMCkgPGJyPlRvOiBvYXV0 aEBpZXRmLm9yZyA8YnI+Q2M6ICA8YnI+U3ViamVjdDogUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1vYXV0aC1pbnRyb3NwZWN0aW9uLTAxLnR4dCA8YnI+PGJyPk9uIDAxLzEy LzE0IDEwOjU2LCBTZXJnZXkgQmVyeW96a2luIHdyb3RlOjxicj4mZ3Q7IEhpIEp1c3Rpbjxicj4m Z3Q7PGJyPiZndDsgTmljZWx5IHdyaXR0ZW4gdGV4dCwgYXMgdXN1YWwuPGJyPiZndDsgRmV3IGNv bW1lbnRzOjxicj4mZ3Q7IC0gSSBoYXZlbid0IGZvdW5kIGEgcmVmZXJlbmNlIHRvIGEgZGF0YSBm b3JtYXQgb2YgUE9TVCByZXF1ZXN0cy48YnI+Jmd0OyBJJ20gcHJlc3VtaW5nIGl0IGlzIGdvaW5n IHRvIGJlIGEgZm9ybSBwYXlsb2FkICh3b3VsZCBtZWFuIHRoZSBzZXJ2ZXI8YnI+Jmd0OyBjb2Rl IGNhbiB3cml0ZSBtb3JlIG9yIGxlc3MgdGhlIHNhbWUgY29kZSBkZWFsaW5nIHdpdGggUE9TVCAm YW1wOyBHRVQ8YnI+Jmd0OyBxdWVyaWVzKSA/PGJyPk9vcHMgOi0pLCBzb3JyeSwgZGlkIG5vdCBz Y3JvbGwgZG93biB0byB0aGUgZXhhbXBsZSBpbiB0aGUgdGV4dDxicj48YnI+VGhhbmtzLCBTZXJn ZXk8YnI+Jmd0OyAtIGNvbnNpZGVyIGRpcmVjdGx5IHNwZWNpZnlpbmcgYW4gb3B0aW9uYWwgJ2Ns aWVudF9pcCcgcHJvcGVydHk8YnI+Jmd0OyAtIGNvbnNpZGVyIGFkZGluZyBhbiBvcHRpb25hbCBy ZXF1ZXN0X21ldGhvZCAob3IgcmVxdWVzdF92ZXJiKSBoaW50LCBhPGJyPiZndDsgZ2l2ZW4gc2Nv cGUgY2FuIGJlIHJlc3RyaWN0ZWQgdG8gc2F5IEdFVCBvbmx5LCBjYW4gYmUgdXNlZnVsIHdoZW4g YTxicj4mZ3Q7IHByb3RlY3RlZCByZXNvdXJjZSBpcyB3cml0dGVuIHRvIHN1cHBvcnQgR0VUIGFu ZCBQT1NUIG92ZXIgdGhlIHNhbWU8YnI+Jmd0OyByZXNvdXJjZV9pZCBVUkk7PGJyPiZndDs8YnI+ Jmd0OyBUaGUgdGV4dCB0aGF0IHRoZSBlbmRwb2ludCBtYXkgc3VwcG9ydCBvdGhlciBwYXJhbWV0 ZXJzIChzdWNoIGEgY2xpZW50PGJyPiZndDsgaXAgYWRkcmVzcykgY292ZXJzIHRoZSBsYXN0IDIg cGFyYW1ldGVycywgYnV0IEkgZ3Vlc3MgaXQgd291bGQgYmUgbW9yZTxicj4mZ3Q7IGludGVyLW9w ZXJhYmxlIHRvICdwcm9tb3RlJyB0aGUgcGFyYW1ldGVycyB0aGF0IG1heSBiZSBvZiBnZW5lcmFs IHVzZS48YnI+Jmd0Ozxicj4mZ3Q7IFRoYW5rcywgU2VyZ2V5PGJyPiZndDs8YnI+Jmd0Ozxicj4m Z3Q7PGJyPiZndDs8YnI+Jmd0OyBPbiAwMS8xMi8xNCAwMjo0MSwgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIHdyb3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+Jmd0OyZn dDsgZGlyZWN0b3JpZXMuPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmc8YnI+Jmd0 OyZndDsgR3JvdXAgb2YgdGhlIElFVEYuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDog T0F1dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb248YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSnVzdGluIFJpY2hl cjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRyYWZ0LWlldGYtb2F1dGgtaW50cm9z cGVjdGlvbi0wMS50eHQ8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFnZXMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgOiAxMDxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDogMjAxNC0xMS0zMDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBt ZXRob2QgZm9yIGEgcHJvdGVjdGVkIHJlc291cmNlIHRvIHF1ZXJ5PGJyPiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIHNlcnZlciB0byBk ZXRlcm1pbmUgdGhlIGFjdGl2ZSBzdGF0ZSBvZiBhbjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBPQXV0aCAyLjAgdG9rZW4gYW5kIHRvIGRldGVybWluZSBtZXRhLWluZm9ybWF0 aW9uIGFib3V0IHRoaXMgdG9rZW4uPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9BdXRoIDIuMCBkZXBsb3ltZW50cyBjYW4gdXNlIHRoaXMgbWV0aG9kIHRvIGNvbnZleSBpbmZv cm1hdGlvbiBhYm91dDxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYXV0 aG9yaXphdGlvbiBjb250ZXh0IG9mIHRoZSB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlcjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGUgcHJvdGVjdGVk IHJlc291cmNlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+ Jmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0 aC1pbnRyb3NwZWN0aW9uLzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGVyZSdzIGFsc28gYSBo dG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+Jmd0OyZndDsgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1pbnRyb3NwZWN0aW9uLTAxPGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDo8YnI+Jmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1vYXV0aC1pbnRyb3NwZWN0aW9uLTAxPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZn dDsmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mPGJyPiZndDsmZ3Q7IHN1Ym1pc3Npb248YnI+Jmd0OyZndDsgdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4mZ3Q7Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBPQXV0aCBtYWls aW5nIGxpc3Q8YnI+Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7PGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5P QXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48L2JvZHk+PC9odG1sPg== ----_com.android.email_1443392620913940-- From nobody Mon Dec 1 04:19:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41131A1B66 for ; Mon, 1 Dec 2014 04:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17wB3y-2fexQ for ; Mon, 1 Dec 2014 04:19:04 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4991A1B54 for ; Mon, 1 Dec 2014 04:19:04 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so13973813wgh.3 for ; Mon, 01 Dec 2014 04:19:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8ey7zI6x84nhMK7NC7w7CudR0v68pI666bLQVDXHTK0=; b=ZO3TXHnBhZ/YuGzCpze5GBIVtBKBusG/8p3/NvnPPahhIhr3pmOEb4W2pYph7znE7w CrVz3LTZ8nt05vcxKGUJsqp2v3hUnIflsy/Ejvurk0JPlGjwvWyzkDj+rZx36qFswqK2 WG0tz1MUCo+VKhFb4UzgengK7RC0a/Lx5GGazukRFalQxsUrHrc7oWeX+gfT1eNBKHKK +obIgKZ1vgcMjnGw9pgh/qF8Gt/CmTS2iKoVEpdpFvBHuIWe/Ph7lGOK9Iop8V+mRZPJ 20oRBGDhx+oROLBJVwxQwYuBlIBgpiUljDhhaN9Hvg9JTdzGmttYXkVNNNCqcDKkJmjr GX4w== X-Gm-Message-State: ALoCoQnlqVUPlq+BKEteFcpXdgTYHQjNP9voO2gZbpoQk1+xoJJ3wl4Tx5pkY+fz1JtSyngVuimo X-Received: by 10.194.176.100 with SMTP id ch4mr94914009wjc.101.1417436342750; Mon, 01 Dec 2014 04:19:02 -0800 (PST) Received: from [10.47.81.161] (host217-39-14-209.in-addr.btopenworld.com. [217.39.14.209]) by mx.google.com with ESMTPSA id cp4sm27360332wjb.16.2014.12.01.04.19.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 04:19:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C5860180-9F49-4C3F-83D4-12DC9EA87AAA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547C347C.7070908@gmx.net> Date: Mon, 1 Dec 2014 09:18:59 -0300 Message-Id: <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <547C347C.7070908@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v1IS5PWmLlNLlW3fwkeIVwsZMz0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 12:19:10 -0000 --Apple-Mail=_C5860180-9F49-4C3F-83D4-12DC9EA87AAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hannes, You seem not to like the idea of client credential rotation. This is something we have wrestled with from the very beginning of = Connect Dynamic client registration. In the early drafts we re-used the client secret for authentication to = the registration/update endpoint.=20 That was rejected by developers as too likely to cause unrecoverable = errors if transactions fail.=20 eg the server thinks it has rotated the secret, but the client doesn't = correctly get the response. They also found the dual use of client secret confusing. When we added OAuth protection to registration, it made sense to use = the same mechanism to protect the endpoint for updates. This allowed the client secret rotation to be recoverable if there was a = problem. Ultimately we didn't do updates for symmetric client secrets in the = Connect version, leaving that for the IETF draft. Via registration of a jwks_uri in Dynamic Client registation, server = based clients can rotate asymmetric keys. =20 However that doesn't help native clients at all, given that they can't = publish a jwks_uri without some other protocol and credentials to push = it to a server (Turtles). You ask why have the complexity of key rollover when the client can just = re-register (start the protocol flow from the start) The answer to that is that many AS use sticky scopes. If a client_id is = granted scope "x" by a user then the user is not re-prompted to = authorize scope "x" again for that client if the client asks for scopes = "x" and "y" on a later request. When the client's access/refresh = tokens expire and the user is sent back to the AS for a new code the AS = wants to reduce the complexity of the dialogs. (Privacy people may argue that people should be re-prompted every time = but that is not the current practice) If the client must get a new client_id every time it rotates it's = secret, then all of the previous grants are going to get blown away, and = it would need to invalidate all it's refresh tokens and start again re = authorizing every user. That is such a scary idea to clients that they = would just never volunteer to rotate credentials, servers would also = probably never enforce rotation as well as this would be seen as = breaking OAuth. Clients needing to have two client_id and secrets to avoid blowing away = refresh tokens also adds a lot of complexity to clients and would = require a total rewrite. We could somehow migrate grants and refresh tokens over to a new = client_id and secret, however this also seems more complicated for both = the client and AS, not really achieving anything more than rotating the = secret alone. So that leaves us with the question of is it necessary to rotate = symmetric client secrets in the first place? When HTTP basic is used for client authentication the client_secret is a = password that is passed in effectively plain text as part of the = request. There are two issues to consider: 1. Brute force attacks, this can be mitigated by using high entropy = passwords (eg 256 bit) however RFC 6749 doesn't provide any guidance on = that point. (I suspect most people based on the examples are using 60-70 = bits of entropy) For low entropy passwords rotation is = required(especially since rate limiting may be difficult, yes I do have = an attack in mind) 2. Man in the middle attacks. SSL encryption is deprecated but I = suspect is going to take a while to be turned off on the server side. = Mobile clients could loose both there secret and refresh token due to = this attack, or other certificate/DNS attacks. Rotation limits the = window that those credentials are good for. (though in many cases all = the damage that could be done can be done in one go) While I would like to get rid of symmetric key rotation I don't think we = can given the current deployment landscape. John B. > On Dec 1, 2014, at 6:27 AM, Hannes Tschofenig = wrote: >=20 > Hi Justin, >=20 > a few comments inline: >=20 > On 11/26/2014 02:32 PM, Justin Richer wrote: >> And by =936790=94 below I obviously mean RFC6749. >>=20 >> (Note to self, don=92t write working group emails this early in the = morning.) >>=20 >> =97 Justin >>=20 >> On Nov 26, 2014, at 8:31 AM, Justin Richer > > wrote: >>=20 >>>=20 >>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig >>> > = wrote: >>>=20 >>>> Hi Justin, >>>>=20 >>>> thanks for your quick response. A few remarks below. >>>>=20 >>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>>> Hannes, thank you for the review. Answers inline. >>>>>=20 >>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig >>>>> > = wrote: >>>>>=20 >>>>>> Hi Justin, Mike, John, Maciej, >>>>>>=20 >>>>>> as part of my shepherd write-up I carefully read through >>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the document is = in >>>>>> good shape but I have a few minor clarification questions that >>>>>> should be resolved before the document goes to the IESG. >>>>>>=20 >>>>>> In Section 1.4. "Registration Tokens and Client Credentials" you >>>>>> explain the different credential types and I was wondering why = you >>>>>> aren't issuing client_secrets to all clients instead of = introducing >>>>>> another credential, the registration access token. While you try = to >>>>>> explain the reasons those appear somewhat constructed. For = example, >>>>>> you say that "not all types of clients have client credentials" = but >>>>>> you are the author of the specification and you can essentially >>>>>> decide what to do. The registration access token is essentially = the >>>>>> same as the client credential since it is "is uniquely bound to = the >>>>>> client identifier". >>>>>>=20 >>>>>> I believe we have discussed this issue in the past but I don't >>>>>> remember what the reasoning was. Can you describe what your = design >>>>>> rational was (and add it to the document)? >>>>>=20 >>>>> That's exactly the question this section is trying to answer, and = if >>>>> it can be made clearer then please suggest some text that will = help >>>>> that purpose. The rationale for the registration access token is = very >>>>> simple: we want to have a means to call the management endpoint in = a >>>>> protected manner, and treating the management endpoint as an OAuth >>>>> Protected Resource makes a lot of sense. RFC6750 gives us the = means >>>>> to make an authorized call to an API endpoint, so we're re-using = that >>>>> instead of trying to invent some other mechanism. Shouldn't we be >>>>> helping the world get away from API passwords? >>>>>=20 >>>>> And it's very true that not every client is going to have a client >>>>> secret to use at the token endpoint -- some will have no use of = one >>>>> (public and implicit clients) and some will be using TLS or >>>>> asymmetric keys (JWT assertions, for instance) or other mechanisms = to >>>>> authenticate that don't involve the secret. Instead of forcing = these >>>>> clients to use a client secret for one new endpoint, or forcing = that >>>>> endpoint to potentially support the infinite number of client >>>>> authentication mechanisms, we decided to just use OAuth. These are >>>>> OAuth clients, remember -- they will *all* have the ability to = send >>>>> OAuth tokens to a protected resource already built in. >>>>>=20 >>>>=20 >>>> Here is the point I don't quite get: the registration access token = is >>>> essentially the same as a client secret. You as a specification = author >>>> essentially decides whether clients will get a client secret or a >>>> registration access token. It is under your control. >>>>=20 >>>> To be more specific, here is what you could have done: >>>>=20 >>>> C -> S: Client Registration Request >>>> C <- S: Client Information Response (with new client secret) >>>>=20 >>>> C -> S: Read or Update Request (with client id/client secret) >>>> C <- S: Client Information Response >>>>=20 >>>> Instead, you currently have this exchange: >>>>=20 >>>> C -> S: Client Registration Request >>>> C <- S: Client Information Response (with new reg. access token) >>>>=20 >>>> C -> S: Read or Update Request (with client id + reg. access token) >>>> C <- S: Client Information Response >>>>=20 >>>> Do you see the similarity that I see? >>>=20 >>> For clients that use a client secret to authenticate to the token >>> endpoint, your point makes sense, but for clients who would not >>> otherwise have a client secret, it doesn=92t. You end up with a >>> confusing state where you=92re giving somebody a =93client_secret=94 = which >>> is defined in 6790 to be used at the token endpoint but then telling >>> them not to use it at the token endpoint (where they use something >>> else or do=92t use it at all) but to use it at this new endpoint >>> instead. Can you see the confusion point here? I think it=92s only = going >>> to get worse as we get more clients that use auth mechanisms that >>> don=92t depend on a shared secret (public key, TLS, etc.).=20 >>>=20 >>> Instead we=92re giving people an OAuth access token to access a >>> protected API, something that OAuth clients ought to know how to do >>> anyway. This mechanism also gives us an opportunity to potentially = use >>> the new PoP tokens (once they=92re actually defined) in place of the >>> bearer credential that=92s defined today.=20 >>>=20 >=20 > I believe I now understand your line of argument. >=20 > You are saying that re-using the client secret for this purpose will > confuse developers since the client credential is used in other places > as well. >=20 > So, the confusion could then be: >=20 > * Client starts the dynamic client registration exchange without a > client secret. > * Later than that exchange he gets a client secret, which is supposed = to > be used for the dynamic client registration management only > * A developer might think that he can now also use that client secret > with anything else as well where a client secret can be used. >=20 >=20 > The questions are now: >=20 > a) Is this potential confusion real or just imagined? > b) Wouldn't this be desired behaviour to begin with? >=20 > If it is a real concern and if you don=92t' want to have that = behaviour > then maybe you want to motivate the design decision in that direction = in > Section 1.4. >=20 >=20 >=20 >>>>=20 >>>>>>=20 >>>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>>>=20 >>>>>> " The Authorization Server MAY rotate the client's registration >>>>>> access token and/or client credentials (such as a = "client_secret") >>>>>> throughout the lifetime of the client. " >>>>>>=20 >>>>>> You might want to add reasons why the authorization server may = want >>>>>> to take this step. >>>>>=20 >>>>> OK, but there's nothing normative here in my view. It's basically = up >>>>> to the auth server to say "well let's make a new credential". Can = you >>>>> suggest text that would clarify this? >>>>>=20 >>>>=20 >>>> What about making the spec simpler by not allowing credential = rotation? >>>> Rekying is a useful concept under two circumstances, namely >>>> * when they provide a performance improvement (such as it is the = case >>>> with session resumption in TLS where you can do an abbreviated = handshake >>>> without all the heavy public key crypto) >>>> * when the entrophy of the key is exhausted, which typically = happens if >>>> you exceed a number of data packets sent under a given key. Often = this >>>> is tied to the way how freshness is ensured and the need to avoid >>>> encrypting data with the same initialization vector/nonce twice. >>>>=20 >>>> Neither of these two cases seem to apply here (IMHO). >>>=20 >>>=20 >>> Rekeying the client is useful in a whole lot more cases than these >>> two, and most of them boil down to =93Something seems fishy=94. I = think if >>> anything we need to eventually figure out how to do *more* secret >>> rotation, including a proactive mechanism started by the client (as >>> Brian has mentioned, among others).=20 >>>=20 >=20 >=20 > The alternative to rekeying (or secret rotation) inside the dynamic > client registration management protocol is to actually re-start the > protocol run from scratch. >=20 > To me it is not obvious whether the added complexity for credential > rotation is worth the effort given the alternative. >=20 >=20 >>>>=20 >>>>=20 >>>>>>=20 >>>>>> There are also a bit too many SHOULDs in the document. Every time >>>>>> you write SHOULD you have to keep in mind to tell the reader what >>>>>> happens in the other case. For example, in Section Section 1.4.1 >>>>>> you write: >>>>>>=20 >>>>>> " The registration access token SHOULD be rotated only in = response >>>>>> to an update request to the client configuration endpoint, at >>>>>> which point the new registration access token is returned to the >>>>>> client and the old registration access token SHOULD be discarded = by >>>>>> both parties. " >>>>>>=20 >>>>>> Here the question arises whether you are using the SHOULD to >>>>>> indicate that the authorization server does not always need to >>>>>> rotate the registration access token and if he does then is must >>>>>> only happen in response to an update request or does it indicate >>>>>> that the authorization server could also rotate it in response to >>>>>> other calls? >>>>>=20 >>>>> It's more that the server SHOULD NOT throw out a registration = access >>>>> token that a client still thinks is good without some way to >>>>> communicate the new token to the client. Think of it this way, = you've >>>>> got the token, the server decides to chuck it on you -- what do = you >>>>> do? You can try calling your READ or UPDATE operations to get the = new >>>>> one but no dice, your token is bad. So what we're saying here is = not >>>>> to throw out the client's only means of finding out if its keys = are >>>>> good anymore. >>>>=20 >>>> I think I got confused with the description of the state management = (as >>>> described in the document). There is some fuzziness. >>>>=20 >>>> Here I would prefer to have either no rekeying (which would make = the >>>> issue go away) or a very deterministic way of rekeying. >>>>=20 >>>> I prefer the former. >>>=20 >>> I=92m not a fan of enforcing permanent credentials on the world. And = we >>> have the same construct with refresh tokens today, for what it=92s = worth. >=20 > It is only permanent in the sense of a full dynamic client = registration > management protocol run. >=20 >=20 >>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Also, in the second line one would wonder why the old = registration >>>>>> access token isn't mandatorily discarded. If there are good >>>>>> reasons, then tell the reader. >>>>>=20 >>>>> We've tried to put requirements on the server discarding tokens in >>>>> the past, but there was significant pushback from providers who = use >>>>> non-revocable time-limited tokens. Maybe they won't be doing that >>>>> here, for the reason above. >>>>=20 >>>>=20 >>>> I wouldn't reflect that in the document. Of course, you can never = be >>>> sure that the implementation really discards any state but for the >>>> purpose of the protocol state machine it is gone. >>>>=20 >>>>>=20 >>>>>> Furthermore, the text in Section 2.2 seems to contract this >>>>>> statement: " If the authorization server includes a new client >>>>>> secret and/or registration access token in its response, the = client >>>>>> MUST immediately discard its previous client secret and/or >>>>>> registration access token. " >>>>>=20 >>>>> This is a requirement on the client, not the server, so it's not >>>>> bound by the token lifetime restrictions above. We're telling the >>>>> client to stop using a secret or token after it's been given a new >>>>> one, that's fine. >>>>=20 >>>> OK >>>>=20 >>>>>=20 >>>>>> In Section 2.2 you write: " However, since read operations are >>>>>> intended to be idempotent, the read request itself SHOULD NOT = cause >>>>>> changes to the client's registered metadata values. " >>>>>>=20 >>>>>> I am wondering whether this SHOULD NOT statement adds a lot of >>>>>> value since you allow the request to change metadata values. >>>>>=20 >>>>> I think you're right, since the metadata values might have changed >>>>> through outside forces since the client last read, and all the >>>>> clients need to be able to deal with that. We can remove that = line. >>>>=20 >>>> OK >>>>=20 >>>>>=20 >>>>>> You also write the security consideration section: " the >>>>>> registration access token MAY be rotated when the developer or >>>>>> client does a read or update operation on the client's client >>>>>> configuration endpoint. " >>>>>>=20 >>>>>> This means that the content of the registration access token may >>>>>> also change with a read operation. >>>>>=20 >>>>> That's correct. >>>>>=20 >>>>>> Terminology: >>>>>>=20 >>>>>> Sometimes you write "Client Information Response" and sometimes >>>>>> "client information response" The same with "Authorization = Server" >>>>>> and "authorization server" >>>>>=20 >>>>> They're all supposed to be lower cased, as is the style in = RFC6749. I >>>>> tried to bump everything down in a previous edit but it looks like = I >>>>> missed some. >>>>>=20 >>>>>> Typo: >>>>>>=20 >>>>>> " Some values in the response, including the "client_secret" and >>>>>> r"egistration_access_token", MAY be ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> different from those in the initial registration response. " >>>>>=20 >>>>> Thanks, noted! >>>>>=20 >>>>>>=20 >>>>>> In Section 2.4 "Client Delete Request" you write: >>>>>>=20 >>>>>> " The authorization server SHOULD immediately invalidate all >>>>>> existing authorization grants and currently-active tokens >>>>>> associated with this client. " >>>>>>=20 >>>>>> Under what circumstances wouldn't the authorization invalidate = all >>>>>> grants and active tokens? >>>>>=20 >>>>> When it's using a non-revocable stateless token and it can't >>>>> physically do that. Too bad 2119 doesn't have MUST IF POSSIBLE or >>>>> equivalent. >>>>=20 >>>> Maybe it would be good to add this information. >>>>=20 >>>> It might also be worthwhile whether this notion of a non-vocable >>>> stateless token actually exists in this context since we are really >>>> talking about the same infrastructure here. This registration = management >>>> mechanism is really very central to the authorization server = (unlike >>>> some other access token mechanisms where we talk about the resource >>>> server, which may be in a different administrative domain even). >>>=20 >>> Why doesn=92t the existing SHOULD cover this? >=20 > Because the should does not explain when to revoke the grants/tokens = and > when not to do it. You wrote it in this email (in context of these > non-revocable tokens) but how should an implementer know when he reads > through the draft? >=20 > The problem is really about assumptions being made that are not > explained further. For example, the assumption that there are tokens > that are not revocable and the implications that result from those on > the design of the protocol (potentially at multiple places in the > document). >=20 >=20 >>>=20 >>>>=20 >>>>>=20 >>>>>> You might also want to say what tokens you are talking about = since >>>>>> there are at least the following tokens around: - access tokens - >>>>>> refresh tokens - registration access tokens - initial access = token >>>>>=20 >>>>> OK, we can add that. >>>>>=20 >>>>>>=20 >>>>>> " If the server does not support the delete method, the server >>>>>> MUST respond with an HTTP 405 Not Supported. " >>>>>>=20 >>>>>> Why aren't you demanding that the server must support this = method? >>>>>> This would essentially mean that there would be some cases where >>>>>> deregistration isn't possible. Of course, there may be the = question >>>>>> how important deregistration actually is if the registration >>>>>> automatically expires. >>>>>=20 >>>>> Because delete is not always an easy operation to implement. The >>>>> client should be able to call the endpoint with the DELETE verb = and >>>>> at least know if it's allowed to do that or not. >>>>=20 >>>> Hmmm. I didn't know that the delete method is difficult to = implement. >>>=20 >>> Depends on your infrastructure and how things get propagated between >>> components. >=20 > There are a number of unstated assumptions here that would be = worthwhile > to point out. >=20 >>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> You write: " If the client does not exist on this server, the >>>>>> server MUST respond with HTTP 401 Unauthorized and the = registration >>>>>> access token used to make this request SHOULD be immediately >>>>>> revoked. " >>>>>>=20 >>>>>> If the client does not exist and someone sends a request with a >>>>>> random registration access token I am not sure what exactly you >>>>>> want to revoke here. >>>>>=20 >>>>> It's not the case of a random token, it's the case of a client = having >>>>> been deleted but using an otherwise valid access token. If the >>>>> token's no good, you don't get this far -- you return a 401 as >>>>> defined in RFC6750. >>>>=20 >>>> I guess it might make sense to add this information. >>>=20 >>> It=92s already in there, in the paragraph just before the one you = quoted: >>>=20 >>> If the registration access token used to make this request is not >>> valid, the server MUST respond with an error as described in OAuth >>> Bearer Token Usage [RFC6750 = ]. >>>=20 >=20 >=20 > But the argument that you provided is for "the case of a client having > been deleted but using an otherwise valid access token" but the text = you > cite talks about the registration access token not being valid. Those > appear to be two different cases. >=20 >>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> In Section 3.1. "Client Information Response" you state the new >>>>>> elements that are returned to the client. While the client_secret >>>>>> has an expires_at field the registration_access_token doesn't. = Does >>>>>> the expiry value of the client_secret_expires_at automatically >>>>>> indicate the lifetime of the registration access token? I think >>>>>> so. But what happens if the client_secret is not issued? To make = it >>>>>> more complicated you write the following text in the security >>>>>> consideration section: >>>>>>=20 >>>>>> " While the client secret can expire, the registration access >>>>>> token SHOULD NOT expire while a client is still actively >>>>>> registered. " >>>>>=20 >>>>> There isn't a separate expiration for the registration access = token >>>>> because it's not supposed to unceremoniously expire on a client. = It >>>>> should be good until it gets rotated out on a future read/update >>>>> operation or the client's registration is no good anymore. >>>>=20 >>>> I think it might be good to have a small section that explains how = state >>>> management works. >>>=20 >>> Can you suggest text for this beyond the paragraph that=92s already = there? >=20 > Yes, I can do that. If you could ship a new update then I can read > through the entire document again and figure out how to create a state > machine. >=20 > If you, of course, get rid of this credential rotation then I don't = have > to do it though. >=20 >=20 >>>=20 >>>>>=20 >>>>>>=20 >>>>>> The IANA consideration section is empty. Wouldn't it be necessary >>>>>> to register 'registration_access_token' and >>>>>> 'registration_client_uri' into the OAuth Dynamic Registration >>>>>> Client Metadata Registry? >>>>>=20 >>>>> No, these are not client metadata. The client can not send these = in a >>>>> registration request, so they don't need to be in there. >>>>=20 >>>> Really? >>>>=20 >>>> I thought that the IANA registry created with Section 5.1 of >>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was meant to = be >>>> used with the Client Registration Request and the Client = Registration >>>> Response exchange. The 'registration_access_token' and >>>> 'registration_client_uri' parameters are used in the response. >>>>=20 >>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an = inconsistency: >>>> The protocol interaction should either be >>>>=20 >>>>=20 >>>> C -> AS: Client Registration Request >>>> C <- AS: Client Registration Response >>>>=20 >>>> OR >>>>=20 >>>> C -> AS: Client Registration Request >>>> C <- AS: Client Registration Error Response >>>>=20 >>>> Currently, sometimes the term "Client Registration Response" or = "Client >>>> Information Response" is used. We need to fix this since it spills = over >>>> to the management API document as well. >>>=20 >>> Client Information Response and Client Error Response are = sub-classes >>> of Client Registration Response. If that=92s not clear from the = current >>> document, please suggest new wording to make it clearer. >=20 > As a shepherd I read through both documents in detail and I didn't > figure that out. That gives me reasons to believe that others wouldn't > figure that out either. >=20 > I would make the change already in Figure 1 of Dynamic Client > Registration Protocol document. >=20 >=20 >=20 > +--------(A)- Initial Access Token (OPTIONAL) > | > | +----(B)- Software Statement (OPTIONAL) > | | > v v > +-----------+ = +---------------+ > | |--(C)- Client Registration Request -->| Client = | > | Client or | | Registration = | > | Developer |<-(D)- Client Registration Response---| Endpoint = | > | | = +---------------+ > +-----------+ >=20 > Client Registration Response:=3D > Client Information Response OR > Client Error Response >=20 > Same change to Figure 1 in the dynamic client registration management > document. You could even indicate in the figure which parts are = already > specified in the dynamic client registration spec and which are added > via the dynamic client registration management doc. >=20 >>>=20 >>>>=20 >>>> Also, I noticed that we say that the server MUST support TLS 1.2 = RFC >>>> 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 anymore. >>>=20 >>> Kathleen made a similar comment on dyn-reg and suggested text that >>> we=92ll incorporate (unless there are objections from others on the = list). >=20 > Ack. >=20 >>>=20 >>>>=20 >>>> In Figure 1 it might be useful to indicate that exchanges A, B, C, = and D >>>> are inherited from the dynamic client registration document and = only >>>> step D is enhanced with additional parameters, as described in = Section >>>> 3.1. Furthermore, I wonder whether it would make sense to somehow >>>> indicate in the figure that the endpoints are actually part of the >>>> Authorization Server. >>>=20 >>> While they usually are the same in practice, these endpoints might = not >>> be part of the Authorization Server =97 they might be part of a = separate >>> (but related) service that handles objects of various kinds within a >>> security domain. No reason to tie them together unnecessarily.=20 >=20 > You can state that someone in the text but endpoints by itself don't > exist since they have to be at some server. Even if the endpoints are = in > separate boxes there needs to be a close cooperation between the two > since otherwise we create new interoperability challenges. >=20 > Ciao > Hannes >=20 >>>=20 >>> =97 Justin >>>=20 >>>=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>=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 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C5860180-9F49-4C3F-83D4-12DC9EA87AAA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDExMjE4NjBaMCMGCSqGSIb3DQEJBDEWBBQPZvo47Y9dNPT+QjMyyCSy Ts3TNTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAykcEOQwVSFucLe93nNuZqM4A6dPNYjK+UYVdA8Rg6NIv0/5gWlOes 3P/Mss0UmB7eEB5eXLqCdL6Nz+8PpAPlHKDSrqKvwoCp6Isrbe4D0lG8uhdLfuW6VU/t2O+9DnYs vEJ6+OTevZwTLFKDs6qUzd5WvHbRIxpx+UdIMDbVo8c1JOrFZSETD1suZWEJ55J4TGQI9GpQeKr2 DTkpTEjffutsd7BBOFAm7jfMhjE5FoPCQkk8ehl8TjdE5ZcwG1616CfbUmlG2w6Po5HM34NRDwZu 6D8dInZTpIQw9W/wsoNdfqCWEzCz0+qnSGM2ojjeyD3LwKKIpNCgNaTv5PeTAAAAAAAA --Apple-Mail=_C5860180-9F49-4C3F-83D4-12DC9EA87AAA-- From nobody Mon Dec 1 06:35:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455111A1BE0 for ; Mon, 1 Dec 2014 06:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg_A5YEYXqef for ; Mon, 1 Dec 2014 06:34:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523881A1BD2 for ; Mon, 1 Dec 2014 06:34:53 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LnPnu-1YNboV2Ybm-00hfj9; Mon, 01 Dec 2014 15:34:50 +0100 Message-ID: <547C7C88.1010000@gmx.net> Date: Mon, 01 Dec 2014 15:34:48 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <547C347C.7070908@gmx.net> <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> In-Reply-To: <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kwcr0LjbwSlPL4wBInR2SJMdJsINELrio" X-Provags-ID: V03:K0:twAWlnB1/Hp6FIRKUsW+IueFo+WMMdnOv3G7Mcx+N9DAZhO0Adg dTU0TYka6GZ4yGfHXakqRr6zDkCq0FkOnTYEcOFFYBgxX9D0DBq62iZbnf/RFqBDu9gJ0rD RkY3Yrf28PBGLh5DPdK9XjYR9DThwDERuq5F7RHY/xkzOVxzQWjX/J++oObMBZPCfNX2/UI qvipLZqFJMUucLwYYDxWA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZIlyYBlrlAdAYr_AWKyiYa1fdSE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:35:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kwcr0LjbwSlPL4wBInR2SJMdJsINELrio Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, thanks for jumping in. On 12/01/2014 01:18 PM, John Bradley wrote: > Hannes, >=20 > You seem not to like the idea of client credential rotation. It is not that I do not like it but I would like to accomplish a few things with my shepherd review: * Ensure that the document is consistent and that nothing is missing. * Double-check whether the design decisions have really been understood.= * Avoid unnecessary complexity. * Document design decisions so that the reader also understands them rather than having to read through the mailing list achieve. > This is something we have wrestled with from the very beginning of > Connect Dynamic client registration. In the early drafts we re-used > the client secret for authentication to the registration/update > endpoint. Actually, I would see the client secret and the credential rotation as two separate issues. >=20 > That was rejected by developers as too likely to cause unrecoverable > errors if transactions fail. eg the server thinks it has rotated the > secret, but the client doesn't correctly get the response. They also > found the dual use of client secret confusing. It is always good to hear developer feedback. I guess that feedback was given in person rather than on the mailing list. >=20 > When we added OAuth protection to registration, it made sense to use > the same mechanism to protect the endpoint for updates. This allowed > the client secret rotation to be recoverable if there was a problem. It certainly makes sense to re-use mechanisms. >=20 > Ultimately we didn't do updates for symmetric client secrets in the > Connect version, leaving that for the IETF draft. Interesting. Do you expect to later inherit the work back to the OpenID Connect? >=20 > Via registration of a jwks_uri in Dynamic Client registation, server > based clients can rotate asymmetric keys. However that doesn't help > native clients at all, given that they can't publish a jwks_uri > without some other protocol and credentials to push it to a server > (Turtles). >=20 > You ask why have the complexity of key rollover when the client can > just re-register (start the protocol flow from the start) >=20 > The answer to that is that many AS use sticky scopes. If a client_id > is granted scope "x" by a user then the user is not re-prompted to > authorize scope "x" again for that client if the client asks for > scopes "x" and "y" on a later request. When the client's > access/refresh tokens expire and the user is sent back to the AS for > a new code the AS wants to reduce the complexity of the dialogs.=20 > (Privacy people may argue that people should be re-prompted every > time but that is not the current practice) I am not sure whether this has anything to do with the dynamic client registration management API. I was not under the assumption that the user would be asked to approve interactions with the dynamic client registration management API. >=20 > If the client must get a new client_id every time it rotates it's > secret, then all of the previous grants are going to get blown away, > and it would need to invalidate all it's refresh tokens and start > again re authorizing every user. That is such a scary idea to > clients that they would just never volunteer to rotate credentials, > servers would also probably never enforce rotation as well as this > would be seen as breaking OAuth. I had naively thought that a new protocol run with the dynamic client registration protocol would not lead to a new client id when the client already has one. It turns out, after re-reading the dynamic client registration protocol document, that the Client Registration Request does not offer a way for the client to transmit a previously obtained client id to the AS. Hence, the AS allocates a new client id (and a new client secret) unless it has some other unspecified ways to find out whether this is an already registered client or not. Because of the way how the dynamic client registration protocol is written requires you to introduce another credential, the registration access token. > Clients needing to have two client_id and secrets to avoid blowing > away refresh tokens also adds a lot of complexity to clients and > would require a total rewrite. I agree that having two client ids and requesting a new client id with every new protocol run would be far from ideal. >=20 > We could somehow migrate grants and refresh tokens over to a new > client_id and secret, however this also seems more complicated for > both the client and AS, not really achieving anything more than > rotating the secret alone. Sounds certainly complex. >=20 > So that leaves us with the question of is it necessary to rotate > symmetric client secrets in the first place? >=20 > When HTTP basic is used for client authentication the client_secret > is a password that is passed in effectively plain text as part of the > request. >=20 > There are two issues to consider: >=20 > 1. Brute force attacks, this can be mitigated by using high entropy > passwords (eg 256 bit) however RFC 6749 doesn't provide any guidance > on that point. (I suspect most people based on the examples are using > 60-70 bits of entropy) For low entropy passwords rotation is > required(especially since rate limiting may be difficult, yes I do > have an attack in mind) We should have given recommendations for the use of the client secret. Our fault. But in any case, we are talking about an online attack here and doing a brute force attack on a server for the client secret might not necessarily be an efficient way to get anywhere. >=20 > 2. Man in the middle attacks. SSL encryption is deprecated but I > suspect is going to take a while to be turned off on the server side. > Mobile clients could loose both there secret and refresh token due to > this attack, or other certificate/DNS attacks. Rotation limits the > window that those credentials are good for. (though in many cases > all the damage that could be done can be done in one go) I don't think that any increase of the key length for the client secret will make any difference here since we are sending the secrets in clear over the TLS protected channel. If the TLS channel is compromised then the attacker will see the keys. > While I would like to get rid of symmetric key rotation I don't think > we can given the current deployment landscape. =46rom the discussion I conclude that the credential rotation is needed (because of the way how the dynamic client registration is currently designed and we don't want to re-design it at this point in time). What would be useful is * to explain some of that background in the credential rotation section, and * issue a new draft. I could then go through the document again and see whether I can draw a state machine to make the interactions a bit clear. Ciao Hannes >=20 > John B. >=20 >> On Dec 1, 2014, at 6:27 AM, Hannes Tschofenig >> wrote: >>=20 >> Hi Justin, >>=20 >> a few comments inline: >>=20 >> On 11/26/2014 02:32 PM, Justin Richer wrote: >>> And by =936790=94 below I obviously mean RFC6749. >>>=20 >>> (Note to self, don=92t write working group emails this early in the >>> morning.) >>>=20 >>> =97 Justin >>>=20 >>> On Nov 26, 2014, at 8:31 AM, Justin Richer >> > wrote: >>>=20 >>>>=20 >>>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig=20 >>>> > >>>> wrote: >>>>=20 >>>>> Hi Justin, >>>>>=20 >>>>> thanks for your quick response. A few remarks below. >>>>>=20 >>>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>>>> Hannes, thank you for the review. Answers inline. >>>>>>=20 >>>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig=20 >>>>>> >>>>> > wrote: >>>>>>=20 >>>>>>> Hi Justin, Mike, John, Maciej, >>>>>>>=20 >>>>>>> as part of my shepherd write-up I carefully read through=20 >>>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the >>>>>>> document is in good shape but I have a few minor >>>>>>> clarification questions that should be resolved before >>>>>>> the document goes to the IESG. >>>>>>>=20 >>>>>>> In Section 1.4. "Registration Tokens and Client >>>>>>> Credentials" you explain the different credential types >>>>>>> and I was wondering why you aren't issuing client_secrets >>>>>>> to all clients instead of introducing another credential, >>>>>>> the registration access token. While you try to explain >>>>>>> the reasons those appear somewhat constructed. For >>>>>>> example, you say that "not all types of clients have >>>>>>> client credentials" but you are the author of the >>>>>>> specification and you can essentially decide what to do. >>>>>>> The registration access token is essentially the same as >>>>>>> the client credential since it is "is uniquely bound to >>>>>>> the client identifier". >>>>>>>=20 >>>>>>> I believe we have discussed this issue in the past but I >>>>>>> don't remember what the reasoning was. Can you describe >>>>>>> what your design rational was (and add it to the >>>>>>> document)? >>>>>>=20 >>>>>> That's exactly the question this section is trying to >>>>>> answer, and if it can be made clearer then please suggest >>>>>> some text that will help that purpose. The rationale for >>>>>> the registration access token is very simple: we want to >>>>>> have a means to call the management endpoint in a protected >>>>>> manner, and treating the management endpoint as an OAuth=20 >>>>>> Protected Resource makes a lot of sense. RFC6750 gives us >>>>>> the means to make an authorized call to an API endpoint, so >>>>>> we're re-using that instead of trying to invent some other >>>>>> mechanism. Shouldn't we be helping the world get away from >>>>>> API passwords? >>>>>>=20 >>>>>> And it's very true that not every client is going to have a >>>>>> client secret to use at the token endpoint -- some will >>>>>> have no use of one (public and implicit clients) and some >>>>>> will be using TLS or asymmetric keys (JWT assertions, for >>>>>> instance) or other mechanisms to authenticate that don't >>>>>> involve the secret. Instead of forcing these clients to use >>>>>> a client secret for one new endpoint, or forcing that=20 >>>>>> endpoint to potentially support the infinite number of >>>>>> client authentication mechanisms, we decided to just use >>>>>> OAuth. These are OAuth clients, remember -- they will *all* >>>>>> have the ability to send OAuth tokens to a protected >>>>>> resource already built in. >>>>>>=20 >>>>>=20 >>>>> Here is the point I don't quite get: the registration access >>>>> token is essentially the same as a client secret. You as a >>>>> specification author essentially decides whether clients will >>>>> get a client secret or a registration access token. It is >>>>> under your control. >>>>>=20 >>>>> To be more specific, here is what you could have done: >>>>>=20 >>>>> C -> S: Client Registration Request C <- S: Client >>>>> Information Response (with new client secret) >>>>>=20 >>>>> C -> S: Read or Update Request (with client id/client >>>>> secret) C <- S: Client Information Response >>>>>=20 >>>>> Instead, you currently have this exchange: >>>>>=20 >>>>> C -> S: Client Registration Request C <- S: Client >>>>> Information Response (with new reg. access token) >>>>>=20 >>>>> C -> S: Read or Update Request (with client id + reg. access >>>>> token) C <- S: Client Information Response >>>>>=20 >>>>> Do you see the similarity that I see? >>>>=20 >>>> For clients that use a client secret to authenticate to the >>>> token endpoint, your point makes sense, but for clients who >>>> would not otherwise have a client secret, it doesn=92t. You end >>>> up with a confusing state where you=92re giving somebody a >>>> =93client_secret=94 which is defined in 6790 to be used at the >>>> token endpoint but then telling them not to use it at the token >>>> endpoint (where they use something else or do=92t use it at all) >>>> but to use it at this new endpoint instead. Can you see the >>>> confusion point here? I think it=92s only going to get worse as >>>> we get more clients that use auth mechanisms that don=92t depend >>>> on a shared secret (public key, TLS, etc.). >>>>=20 >>>> Instead we=92re giving people an OAuth access token to access a=20 >>>> protected API, something that OAuth clients ought to know how >>>> to do anyway. This mechanism also gives us an opportunity to >>>> potentially use the new PoP tokens (once they=92re actually >>>> defined) in place of the bearer credential that=92s defined >>>> today. >>>>=20 >>=20 >> I believe I now understand your line of argument. >>=20 >> You are saying that re-using the client secret for this purpose >> will confuse developers since the client credential is used in >> other places as well. >>=20 >> So, the confusion could then be: >>=20 >> * Client starts the dynamic client registration exchange without a=20 >> client secret. * Later than that exchange he gets a client secret, >> which is supposed to be used for the dynamic client registration >> management only * A developer might think that he can now also use >> that client secret with anything else as well where a client secret >> can be used. >>=20 >>=20 >> The questions are now: >>=20 >> a) Is this potential confusion real or just imagined? b) Wouldn't >> this be desired behaviour to begin with? >>=20 >> If it is a real concern and if you don=92t' want to have that >> behaviour then maybe you want to motivate the design decision in >> that direction in Section 1.4. >>=20 >>=20 >>=20 >>>>>=20 >>>>>>>=20 >>>>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>>>>=20 >>>>>>> " The Authorization Server MAY rotate the client's >>>>>>> registration access token and/or client credentials (such >>>>>>> as a "client_secret") throughout the lifetime of the >>>>>>> client. " >>>>>>>=20 >>>>>>> You might want to add reasons why the authorization >>>>>>> server may want to take this step. >>>>>>=20 >>>>>> OK, but there's nothing normative here in my view. It's >>>>>> basically up to the auth server to say "well let's make a >>>>>> new credential". Can you suggest text that would clarify >>>>>> this? >>>>>>=20 >>>>>=20 >>>>> What about making the spec simpler by not allowing credential >>>>> rotation? Rekying is a useful concept under two >>>>> circumstances, namely * when they provide a performance >>>>> improvement (such as it is the case with session resumption >>>>> in TLS where you can do an abbreviated handshake without all >>>>> the heavy public key crypto) * when the entrophy of the key >>>>> is exhausted, which typically happens if you exceed a number >>>>> of data packets sent under a given key. Often this is tied to >>>>> the way how freshness is ensured and the need to avoid=20 >>>>> encrypting data with the same initialization vector/nonce >>>>> twice. >>>>>=20 >>>>> Neither of these two cases seem to apply here (IMHO). >>>>=20 >>>>=20 >>>> Rekeying the client is useful in a whole lot more cases than >>>> these two, and most of them boil down to =93Something seems >>>> fishy=94. I think if anything we need to eventually figure out >>>> how to do *more* secret rotation, including a proactive >>>> mechanism started by the client (as Brian has mentioned, among >>>> others). >>>>=20 >>=20 >>=20 >> The alternative to rekeying (or secret rotation) inside the >> dynamic client registration management protocol is to actually >> re-start the protocol run from scratch. >>=20 >> To me it is not obvious whether the added complexity for >> credential rotation is worth the effort given the alternative. >>=20 >>=20 >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> There are also a bit too many SHOULDs in the document. >>>>>>> Every time you write SHOULD you have to keep in mind to >>>>>>> tell the reader what happens in the other case. For >>>>>>> example, in Section Section 1.4.1 you write: >>>>>>>=20 >>>>>>> " The registration access token SHOULD be rotated only in >>>>>>> response to an update request to the client configuration >>>>>>> endpoint, at which point the new registration access >>>>>>> token is returned to the client and the old registration >>>>>>> access token SHOULD be discarded by both parties. " >>>>>>>=20 >>>>>>> Here the question arises whether you are using the SHOULD >>>>>>> to indicate that the authorization server does not always >>>>>>> need to rotate the registration access token and if he >>>>>>> does then is must only happen in response to an update >>>>>>> request or does it indicate that the authorization server >>>>>>> could also rotate it in response to other calls? >>>>>>=20 >>>>>> It's more that the server SHOULD NOT throw out a >>>>>> registration access token that a client still thinks is >>>>>> good without some way to communicate the new token to the >>>>>> client. Think of it this way, you've got the token, the >>>>>> server decides to chuck it on you -- what do you do? You >>>>>> can try calling your READ or UPDATE operations to get the >>>>>> new one but no dice, your token is bad. So what we're >>>>>> saying here is not to throw out the client's only means of >>>>>> finding out if its keys are good anymore. >>>>>=20 >>>>> I think I got confused with the description of the state >>>>> management (as described in the document). There is some >>>>> fuzziness. >>>>>=20 >>>>> Here I would prefer to have either no rekeying (which would >>>>> make the issue go away) or a very deterministic way of >>>>> rekeying. >>>>>=20 >>>>> I prefer the former. >>>>=20 >>>> I=92m not a fan of enforcing permanent credentials on the world. >>>> And we have the same construct with refresh tokens today, for >>>> what it=92s worth. >>=20 >> It is only permanent in the sense of a full dynamic client >> registration management protocol run. >>=20 >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Also, in the second line one would wonder why the old >>>>>>> registration access token isn't mandatorily discarded. If >>>>>>> there are good reasons, then tell the reader. >>>>>>=20 >>>>>> We've tried to put requirements on the server discarding >>>>>> tokens in the past, but there was significant pushback from >>>>>> providers who use non-revocable time-limited tokens. Maybe >>>>>> they won't be doing that here, for the reason above. >>>>>=20 >>>>>=20 >>>>> I wouldn't reflect that in the document. Of course, you can >>>>> never be sure that the implementation really discards any >>>>> state but for the purpose of the protocol state machine it is >>>>> gone. >>>>>=20 >>>>>>=20 >>>>>>> Furthermore, the text in Section 2.2 seems to contract >>>>>>> this statement: " If the authorization server includes a >>>>>>> new client secret and/or registration access token in its >>>>>>> response, the client MUST immediately discard its >>>>>>> previous client secret and/or registration access token. >>>>>>> " >>>>>>=20 >>>>>> This is a requirement on the client, not the server, so >>>>>> it's not bound by the token lifetime restrictions above. >>>>>> We're telling the client to stop using a secret or token >>>>>> after it's been given a new one, that's fine. >>>>>=20 >>>>> OK >>>>>=20 >>>>>>=20 >>>>>>> In Section 2.2 you write: " However, since read >>>>>>> operations are intended to be idempotent, the read >>>>>>> request itself SHOULD NOT cause changes to the client's >>>>>>> registered metadata values. " >>>>>>>=20 >>>>>>> I am wondering whether this SHOULD NOT statement adds a >>>>>>> lot of value since you allow the request to change >>>>>>> metadata values. >>>>>>=20 >>>>>> I think you're right, since the metadata values might have >>>>>> changed through outside forces since the client last read, >>>>>> and all the clients need to be able to deal with that. We >>>>>> can remove that line. >>>>>=20 >>>>> OK >>>>>=20 >>>>>>=20 >>>>>>> You also write the security consideration section: " the=20 >>>>>>> registration access token MAY be rotated when the >>>>>>> developer or client does a read or update operation on >>>>>>> the client's client configuration endpoint. " >>>>>>>=20 >>>>>>> This means that the content of the registration access >>>>>>> token may also change with a read operation. >>>>>>=20 >>>>>> That's correct. >>>>>>=20 >>>>>>> Terminology: >>>>>>>=20 >>>>>>> Sometimes you write "Client Information Response" and >>>>>>> sometimes "client information response" The same with >>>>>>> "Authorization Server" and "authorization server" >>>>>>=20 >>>>>> They're all supposed to be lower cased, as is the style in >>>>>> RFC6749. I tried to bump everything down in a previous edit >>>>>> but it looks like I missed some. >>>>>>=20 >>>>>>> Typo: >>>>>>>=20 >>>>>>> " Some values in the response, including the >>>>>>> "client_secret" and r"egistration_access_token", MAY be >>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ different from those in the >>>>>>> initial registration response. " >>>>>>=20 >>>>>> Thanks, noted! >>>>>>=20 >>>>>>>=20 >>>>>>> In Section 2.4 "Client Delete Request" you write: >>>>>>>=20 >>>>>>> " The authorization server SHOULD immediately invalidate >>>>>>> all existing authorization grants and currently-active >>>>>>> tokens associated with this client. " >>>>>>>=20 >>>>>>> Under what circumstances wouldn't the authorization >>>>>>> invalidate all grants and active tokens? >>>>>>=20 >>>>>> When it's using a non-revocable stateless token and it >>>>>> can't physically do that. Too bad 2119 doesn't have MUST IF >>>>>> POSSIBLE or equivalent. >>>>>=20 >>>>> Maybe it would be good to add this information. >>>>>=20 >>>>> It might also be worthwhile whether this notion of a >>>>> non-vocable stateless token actually exists in this context >>>>> since we are really talking about the same infrastructure >>>>> here. This registration management mechanism is really very >>>>> central to the authorization server (unlike some other access >>>>> token mechanisms where we talk about the resource server, >>>>> which may be in a different administrative domain even). >>>>=20 >>>> Why doesn=92t the existing SHOULD cover this? >>=20 >> Because the should does not explain when to revoke the >> grants/tokens and when not to do it. You wrote it in this email (in >> context of these non-revocable tokens) but how should an >> implementer know when he reads through the draft? >>=20 >> The problem is really about assumptions being made that are not=20 >> explained further. For example, the assumption that there are >> tokens that are not revocable and the implications that result from >> those on the design of the protocol (potentially at multiple places >> in the document). >>=20 >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> You might also want to say what tokens you are talking >>>>>>> about since there are at least the following tokens >>>>>>> around: - access tokens - refresh tokens - registration >>>>>>> access tokens - initial access token >>>>>>=20 >>>>>> OK, we can add that. >>>>>>=20 >>>>>>>=20 >>>>>>> " If the server does not support the delete method, the >>>>>>> server MUST respond with an HTTP 405 Not Supported. " >>>>>>>=20 >>>>>>> Why aren't you demanding that the server must support >>>>>>> this method? This would essentially mean that there would >>>>>>> be some cases where deregistration isn't possible. Of >>>>>>> course, there may be the question how important >>>>>>> deregistration actually is if the registration=20 >>>>>>> automatically expires. >>>>>>=20 >>>>>> Because delete is not always an easy operation to >>>>>> implement. The client should be able to call the endpoint >>>>>> with the DELETE verb and at least know if it's allowed to >>>>>> do that or not. >>>>>=20 >>>>> Hmmm. I didn't know that the delete method is difficult to >>>>> implement. >>>>=20 >>>> Depends on your infrastructure and how things get propagated >>>> between components. >>=20 >> There are a number of unstated assumptions here that would be >> worthwhile to point out. >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> You write: " If the client does not exist on this server, >>>>>>> the server MUST respond with HTTP 401 Unauthorized and >>>>>>> the registration access token used to make this request >>>>>>> SHOULD be immediately revoked. " >>>>>>>=20 >>>>>>> If the client does not exist and someone sends a request >>>>>>> with a random registration access token I am not sure >>>>>>> what exactly you want to revoke here. >>>>>>=20 >>>>>> It's not the case of a random token, it's the case of a >>>>>> client having been deleted but using an otherwise valid >>>>>> access token. If the token's no good, you don't get this >>>>>> far -- you return a 401 as defined in RFC6750. >>>>>=20 >>>>> I guess it might make sense to add this information. >>>>=20 >>>> It=92s already in there, in the paragraph just before the one you >>>> quoted: >>>>=20 >>>> If the registration access token used to make this request is >>>> not valid, the server MUST respond with an error as described >>>> in OAuth Bearer Token Usage [RFC6750 >>>> ]. >>>>=20 >>=20 >>=20 >> But the argument that you provided is for "the case of a client >> having been deleted but using an otherwise valid access token" but >> the text you cite talks about the registration access token not >> being valid. Those appear to be two different cases. >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> In Section 3.1. "Client Information Response" you state >>>>>>> the new elements that are returned to the client. While >>>>>>> the client_secret has an expires_at field the >>>>>>> registration_access_token doesn't. Does the expiry value >>>>>>> of the client_secret_expires_at automatically indicate >>>>>>> the lifetime of the registration access token? I think=20 >>>>>>> so. But what happens if the client_secret is not issued? >>>>>>> To make it more complicated you write the following text >>>>>>> in the security consideration section: >>>>>>>=20 >>>>>>> " While the client secret can expire, the registration >>>>>>> access token SHOULD NOT expire while a client is still >>>>>>> actively registered. " >>>>>>=20 >>>>>> There isn't a separate expiration for the registration >>>>>> access token because it's not supposed to unceremoniously >>>>>> expire on a client. It should be good until it gets rotated >>>>>> out on a future read/update operation or the client's >>>>>> registration is no good anymore. >>>>>=20 >>>>> I think it might be good to have a small section that >>>>> explains how state management works. >>>>=20 >>>> Can you suggest text for this beyond the paragraph that=92s >>>> already there? >>=20 >> Yes, I can do that. If you could ship a new update then I can read=20 >> through the entire document again and figure out how to create a >> state machine. >>=20 >> If you, of course, get rid of this credential rotation then I don't >> have to do it though. >>=20 >>=20 >>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> The IANA consideration section is empty. Wouldn't it be >>>>>>> necessary to register 'registration_access_token' and=20 >>>>>>> 'registration_client_uri' into the OAuth Dynamic >>>>>>> Registration Client Metadata Registry? >>>>>>=20 >>>>>> No, these are not client metadata. The client can not send >>>>>> these in a registration request, so they don't need to be >>>>>> in there. >>>>>=20 >>>>> Really? >>>>>=20 >>>>> I thought that the IANA registry created with Section 5.1 of=20 >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was >>>>> meant to be used with the Client Registration Request and the >>>>> Client Registration Response exchange. The >>>>> 'registration_access_token' and 'registration_client_uri' >>>>> parameters are used in the response. >>>>>=20 >>>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an >>>>> inconsistency: The protocol interaction should either be >>>>>=20 >>>>>=20 >>>>> C -> AS: Client Registration Request C <- AS: Client >>>>> Registration Response >>>>>=20 >>>>> OR >>>>>=20 >>>>> C -> AS: Client Registration Request C <- AS: Client >>>>> Registration Error Response >>>>>=20 >>>>> Currently, sometimes the term "Client Registration Response" >>>>> or "Client Information Response" is used. We need to fix this >>>>> since it spills over to the management API document as well. >>>>=20 >>>> Client Information Response and Client Error Response are >>>> sub-classes of Client Registration Response. If that=92s not >>>> clear from the current document, please suggest new wording to >>>> make it clearer. >>=20 >> As a shepherd I read through both documents in detail and I didn't=20 >> figure that out. That gives me reasons to believe that others >> wouldn't figure that out either. >>=20 >> I would make the change already in Figure 1 of Dynamic Client=20 >> Registration Protocol document. >>=20 >>=20 >>=20 >> +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- >> Software Statement (OPTIONAL) | | v v +-----------+ >> +---------------+ | |--(C)- Client Registration Request >> -->| Client | | Client or | >> | Registration | | Developer |<-(D)- Client Registration >> Response---| Endpoint | | | >> +---------------+ +-----------+ >>=20 >> Client Registration Response:=3D Client Information Response OR=20 >> Client Error Response >>=20 >> Same change to Figure 1 in the dynamic client registration >> management document. You could even indicate in the figure which >> parts are already specified in the dynamic client registration spec >> and which are added via the dynamic client registration management >> doc. >>=20 >>>>=20 >>>>>=20 >>>>> Also, I noticed that we say that the server MUST support TLS >>>>> 1.2 RFC 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 >>>>> anymore. >>>>=20 >>>> Kathleen made a similar comment on dyn-reg and suggested text >>>> that we=92ll incorporate (unless there are objections from others >>>> on the list). >>=20 >> Ack. >>=20 >>>>=20 >>>>>=20 >>>>> In Figure 1 it might be useful to indicate that exchanges A, >>>>> B, C, and D are inherited from the dynamic client >>>>> registration document and only step D is enhanced with >>>>> additional parameters, as described in Section 3.1. >>>>> Furthermore, I wonder whether it would make sense to somehow=20 >>>>> indicate in the figure that the endpoints are actually part >>>>> of the Authorization Server. >>>>=20 >>>> While they usually are the same in practice, these endpoints >>>> might not be part of the Authorization Server =97 they might be >>>> part of a separate (but related) service that handles objects >>>> of various kinds within a security domain. No reason to tie >>>> them together unnecessarily. >>=20 >> You can state that someone in the text but endpoints by itself >> don't exist since they have to be at some server. Even if the >> endpoints are in separate boxes there needs to be a close >> cooperation between the two since otherwise we create new >> interoperability challenges. >>=20 >> Ciao Hannes >>=20 >>>>=20 >>>> =97 Justin >>>>=20 >>>>=20 >>>>>=20 >>>>> Ciao Hannes >>>>>=20 >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ OAuth mailing >>>>> list OAuth@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ OAuth mailing >>>> list OAuth@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ OAuth mailing list=20 >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >=20 --Kwcr0LjbwSlPL4wBInR2SJMdJsINELrio Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfHyIAAoJEGhJURNOOiAt/I8IAIfVI92wDglZOKTnf1YUSlLI D4bwr9PztWVwwea0AjqFBKImvJ/Uvv21wNvIti8tCF7HAAAaTp4RtINHtiz+a6g4 n5vg2AS/8jeRmB8ctZ1qfWTIqsZNuuz+kuI/mlNBDgykDeVh0mQ4hnfqocq/nXHR OpeLQiwTXeJZSflUhSKxvQ/oBZBTg3wj2sWcwddkTsaCiGll0vgLmcCpNqNvXjIH XdOjCWAGRVihb5O8cc6lfJebF2E6gG+joiK1HGSSdXP8HF7J8YwAD5pRGutD/teG I1cy/6Hvry5jklVLGgFYs6ohRmEydN53gehxjYKNcTN28yww5ykra0+gWb8NqTI= =Uxm2 -----END PGP SIGNATURE----- --Kwcr0LjbwSlPL4wBInR2SJMdJsINELrio-- From nobody Mon Dec 1 07:23:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3C01A1EFE for ; Mon, 1 Dec 2014 07:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5jMGb3mcS89 for ; Mon, 1 Dec 2014 07:23:28 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AFA1A6EE5 for ; Mon, 1 Dec 2014 07:22:26 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so14431692wgh.13 for ; Mon, 01 Dec 2014 07:22:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XtA+UVhce/pDDgfW1NOw4w8exTDnsI6ZZz2UiK2eMoM=; b=MJdnKs5H11cuXCbl2fXd5QyKODmyd54n1UoVyjkY2CgQmJz6e35jsnf60w1HjEI7Gf /BlAZ7X6N68Eyz0BqXPzQarq6xkBG8fR1MVQcLTYg6DLRx6M5i7iJXr6DWI5sBXuuEtA WhRsah+13x2imjG1SrdoZ4UAiAVOIk5sgNTJSuyAa7YVvvu5UK7ycQlzMjs2TLTe21Tc jGoY50QM08a0LEFpOJ/ywDK8HWAV07jiYjjtThgXIdpGJHdKvIbbJWmqWkj6iZTCdAyV sRoqLM52t4tv2O99Fe+xzIMqmeJXVku7k1OU+y6OeRGVU93+v9iQHxYg4keGl+Chv2kQ L4Ig== X-Gm-Message-State: ALoCoQl3SEYOxdd1fiyK6w7+aPCirf6tecqUWvzsClrpbxzKlBPyYfS5pFqrvp7cA49f81baBTuv X-Received: by 10.194.133.66 with SMTP id pa2mr50022866wjb.134.1417447343944; Mon, 01 Dec 2014 07:22:23 -0800 (PST) Received: from [10.47.81.161] (host217-39-14-209.in-addr.btopenworld.com. [217.39.14.209]) by mx.google.com with ESMTPSA id h14sm28852477wic.8.2014.12.01.07.22.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 07:22:22 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547C7C88.1010000@gmx.net> Date: Mon, 1 Dec 2014 12:21:03 -0300 Message-Id: <99059A3E-9D42-45FB-8DF9-3C33022F92C9@ve7jtb.com> References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <547C347C.7070908@gmx.net> <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> <547C7C88.1010000@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BNEVZ_3QalBPbrFR0hcMuN2j6qg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 15:23:39 -0000 --Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline > On Dec 1, 2014, at 11:34 AM, Hannes Tschofenig = wrote: >=20 > Hi John, >=20 > thanks for jumping in. >=20 > On 12/01/2014 01:18 PM, John Bradley wrote: >> Hannes, >>=20 >> You seem not to like the idea of client credential rotation. >=20 > It is not that I do not like it but I would like to accomplish a few > things with my shepherd review: >=20 > * Ensure that the document is consistent and that nothing is missing. > * Double-check whether the design decisions have really been = understood. > * Avoid unnecessary complexity. > * Document design decisions so that the reader also understands them > rather than having to read through the mailing list achieve. >=20 >=20 >> This is something we have wrestled with from the very beginning of >> Connect Dynamic client registration. In the early drafts we re-used >> the client secret for authentication to the registration/update >> endpoint. >=20 > Actually, I would see the client secret and the credential rotation as > two separate issues. >=20 They are unless you need the client secret to do the update. If you do = that causes problems with using the secret to update the secret. >>=20 >> That was rejected by developers as too likely to cause unrecoverable >> errors if transactions fail. eg the server thinks it has rotated the >> secret, but the client doesn't correctly get the response. They also >> found the dual use of client secret confusing. >=20 > It is always good to hear developer feedback. I guess that feedback = was > given in person rather than on the mailing list. >=20 That happened before the contribution Connect work as a IETF draft and = is on the Connect mailing list. >=20 >>=20 >> When we added OAuth protection to registration, it made sense to use >> the same mechanism to protect the endpoint for updates. This allowed >> the client secret rotation to be recoverable if there was a problem. >=20 > It certainly makes sense to re-use mechanisms. >=20 >>=20 >> Ultimately we didn't do updates for symmetric client secrets in the >> Connect version, leaving that for the IETF draft. >=20 > Interesting. Do you expect to later inherit the work back to the = OpenID > Connect? If there is a RFC that Connect can reference and profile to add the = additional configuration attributes that Connect registration has then that would = be a good outcome in my=20 opinion. I don't think we have ever intended to have two incomparable = registration specs. >=20 >>=20 >> Via registration of a jwks_uri in Dynamic Client registation, server >> based clients can rotate asymmetric keys. However that doesn't help >> native clients at all, given that they can't publish a jwks_uri >> without some other protocol and credentials to push it to a server >> (Turtles). >>=20 >> You ask why have the complexity of key rollover when the client can >> just re-register (start the protocol flow from the start) >>=20 >> The answer to that is that many AS use sticky scopes. If a client_id >> is granted scope "x" by a user then the user is not re-prompted to >> authorize scope "x" again for that client if the client asks for >> scopes "x" and "y" on a later request. When the client's >> access/refresh tokens expire and the user is sent back to the AS for >> a new code the AS wants to reduce the complexity of the dialogs.=20 >> (Privacy people may argue that people should be re-prompted every >> time but that is not the current practice) >=20 > I am not sure whether this has anything to do with the dynamic client > registration management API. >=20 > I was not under the assumption that the user would be asked to approve > interactions with the dynamic client registration management API. The user is not involved in consenting to the registration. However if you create a new client_id to rotate the key the user must re = do all the consents that they had previously granted as it is a new client from the = perspective of the AS. So in that solution to key rollover you do ultimately involve the user,=20= something that we are trying to avoid. >=20 >>=20 >> If the client must get a new client_id every time it rotates it's >> secret, then all of the previous grants are going to get blown away, >> and it would need to invalidate all it's refresh tokens and start >> again re authorizing every user. That is such a scary idea to >> clients that they would just never volunteer to rotate credentials, >> servers would also probably never enforce rotation as well as this >> would be seen as breaking OAuth. >=20 > I had naively thought that a new protocol run with the dynamic client > registration protocol would not lead to a new client id when the = client > already has one. >=20 > It turns out, after re-reading the dynamic client registration = protocol > document, that the Client Registration Request does not offer a way = for > the client to transmit a previously obtained client id to the AS. > Hence, the AS allocates a new client id (and a new client secret) = unless > it has some other unspecified ways to find out whether this is an > already registered client or not. >=20 > Because of the way how the dynamic client registration protocol is > written requires you to introduce another credential, the registration > access token. I think one thing that may be confusing people is that we are trying to = use REST (irony). Originally updates happened at the registration endpoint using the = registration access token=20 instead of the initial access token. Effectively doing what you are = thinking. That is still possible if the registration_client_uri returned is the = same URI at was used to register. To be REST we create a new resource when a client_id is created and = perform the update operations on it, but it is up to the AS how to implement that.=20 I suspect the only real difference is that we are using PUT as it is an = existing resource rather than POST. >> Clients needing to have two client_id and secrets to avoid blowing >> away refresh tokens also adds a lot of complexity to clients and >> would require a total rewrite. > I agree that having two client ids and requesting a new client id with > every new protocol run would be far from ideal. >=20 >>=20 >> We could somehow migrate grants and refresh tokens over to a new >> client_id and secret, however this also seems more complicated for >> both the client and AS, not really achieving anything more than >> rotating the secret alone. >=20 > Sounds certainly complex. >=20 >>=20 >> So that leaves us with the question of is it necessary to rotate >> symmetric client secrets in the first place? >>=20 >> When HTTP basic is used for client authentication the client_secret >> is a password that is passed in effectively plain text as part of the >> request. >>=20 >> There are two issues to consider: >>=20 >> 1. Brute force attacks, this can be mitigated by using high entropy >> passwords (eg 256 bit) however RFC 6749 doesn't provide any guidance >> on that point. (I suspect most people based on the examples are using >> 60-70 bits of entropy) For low entropy passwords rotation is >> required(especially since rate limiting may be difficult, yes I do >> have an attack in mind) >=20 > We should have given recommendations for the use of the client secret. > Our fault. But in any case, we are talking about an online attack here > and doing a brute force attack on a server for the client secret might > not necessarily be an efficient way to get anywhere. That depends on how short the secret is and if there is any rate = limiting. >=20 >>=20 >> 2. Man in the middle attacks. SSL encryption is deprecated but I >> suspect is going to take a while to be turned off on the server side. >> Mobile clients could loose both there secret and refresh token due to >> this attack, or other certificate/DNS attacks. Rotation limits the >> window that those credentials are good for. (though in many cases >> all the damage that could be done can be done in one go) >=20 > I don't think that any increase of the key length for the client = secret > will make any difference here since we are sending the secrets in = clear > over the TLS protected channel. If the TLS channel is compromised then > the attacker will see the keys. Yes >=20 >> While I would like to get rid of symmetric key rotation I don't think >> we can given the current deployment landscape. >=20 > =46rom the discussion I conclude that the credential rotation is = needed > (because of the way how the dynamic client registration is currently > designed and we don't want to re-design it at this point in time). >=20 We were told to make registration crate only no updates. We did that This spec is how you update. It is really the same endpoint if you want = it to be from an implementation point of view. John B. > What would be useful is > * to explain some of that background in the credential rotation = section, > and > * issue a new draft. >=20 > I could then go through the document again and see whether I can draw = a > state machine to make the interactions a bit clear. >=20 > Ciao > Hannes >=20 >>=20 >> John B. >>=20 >>> On Dec 1, 2014, at 6:27 AM, Hannes Tschofenig >>> wrote: >>>=20 >>> Hi Justin, >>>=20 >>> a few comments inline: >>>=20 >>> On 11/26/2014 02:32 PM, Justin Richer wrote: >>>> And by =936790=94 below I obviously mean RFC6749. >>>>=20 >>>> (Note to self, don=92t write working group emails this early in the >>>> morning.) >>>>=20 >>>> =97 Justin >>>>=20 >>>> On Nov 26, 2014, at 8:31 AM, Justin Richer >>> > wrote: >>>>=20 >>>>>=20 >>>>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig=20 >>>>> > >>>>> wrote: >>>>>=20 >>>>>> Hi Justin, >>>>>>=20 >>>>>> thanks for your quick response. A few remarks below. >>>>>>=20 >>>>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote: >>>>>>> Hannes, thank you for the review. Answers inline. >>>>>>>=20 >>>>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig=20 >>>>>>> >>>>>> > wrote: >>>>>>>=20 >>>>>>>> Hi Justin, Mike, John, Maciej, >>>>>>>>=20 >>>>>>>> as part of my shepherd write-up I carefully read through=20 >>>>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the >>>>>>>> document is in good shape but I have a few minor >>>>>>>> clarification questions that should be resolved before >>>>>>>> the document goes to the IESG. >>>>>>>>=20 >>>>>>>> In Section 1.4. "Registration Tokens and Client >>>>>>>> Credentials" you explain the different credential types >>>>>>>> and I was wondering why you aren't issuing client_secrets >>>>>>>> to all clients instead of introducing another credential, >>>>>>>> the registration access token. While you try to explain >>>>>>>> the reasons those appear somewhat constructed. For >>>>>>>> example, you say that "not all types of clients have >>>>>>>> client credentials" but you are the author of the >>>>>>>> specification and you can essentially decide what to do. >>>>>>>> The registration access token is essentially the same as >>>>>>>> the client credential since it is "is uniquely bound to >>>>>>>> the client identifier". >>>>>>>>=20 >>>>>>>> I believe we have discussed this issue in the past but I >>>>>>>> don't remember what the reasoning was. Can you describe >>>>>>>> what your design rational was (and add it to the >>>>>>>> document)? >>>>>>>=20 >>>>>>> That's exactly the question this section is trying to >>>>>>> answer, and if it can be made clearer then please suggest >>>>>>> some text that will help that purpose. The rationale for >>>>>>> the registration access token is very simple: we want to >>>>>>> have a means to call the management endpoint in a protected >>>>>>> manner, and treating the management endpoint as an OAuth=20 >>>>>>> Protected Resource makes a lot of sense. RFC6750 gives us >>>>>>> the means to make an authorized call to an API endpoint, so >>>>>>> we're re-using that instead of trying to invent some other >>>>>>> mechanism. Shouldn't we be helping the world get away from >>>>>>> API passwords? >>>>>>>=20 >>>>>>> And it's very true that not every client is going to have a >>>>>>> client secret to use at the token endpoint -- some will >>>>>>> have no use of one (public and implicit clients) and some >>>>>>> will be using TLS or asymmetric keys (JWT assertions, for >>>>>>> instance) or other mechanisms to authenticate that don't >>>>>>> involve the secret. Instead of forcing these clients to use >>>>>>> a client secret for one new endpoint, or forcing that=20 >>>>>>> endpoint to potentially support the infinite number of >>>>>>> client authentication mechanisms, we decided to just use >>>>>>> OAuth. These are OAuth clients, remember -- they will *all* >>>>>>> have the ability to send OAuth tokens to a protected >>>>>>> resource already built in. >>>>>>>=20 >>>>>>=20 >>>>>> Here is the point I don't quite get: the registration access >>>>>> token is essentially the same as a client secret. You as a >>>>>> specification author essentially decides whether clients will >>>>>> get a client secret or a registration access token. It is >>>>>> under your control. >>>>>>=20 >>>>>> To be more specific, here is what you could have done: >>>>>>=20 >>>>>> C -> S: Client Registration Request C <- S: Client >>>>>> Information Response (with new client secret) >>>>>>=20 >>>>>> C -> S: Read or Update Request (with client id/client >>>>>> secret) C <- S: Client Information Response >>>>>>=20 >>>>>> Instead, you currently have this exchange: >>>>>>=20 >>>>>> C -> S: Client Registration Request C <- S: Client >>>>>> Information Response (with new reg. access token) >>>>>>=20 >>>>>> C -> S: Read or Update Request (with client id + reg. access >>>>>> token) C <- S: Client Information Response >>>>>>=20 >>>>>> Do you see the similarity that I see? >>>>>=20 >>>>> For clients that use a client secret to authenticate to the >>>>> token endpoint, your point makes sense, but for clients who >>>>> would not otherwise have a client secret, it doesn=92t. You end >>>>> up with a confusing state where you=92re giving somebody a >>>>> =93client_secret=94 which is defined in 6790 to be used at the >>>>> token endpoint but then telling them not to use it at the token >>>>> endpoint (where they use something else or do=92t use it at all) >>>>> but to use it at this new endpoint instead. Can you see the >>>>> confusion point here? I think it=92s only going to get worse as >>>>> we get more clients that use auth mechanisms that don=92t depend >>>>> on a shared secret (public key, TLS, etc.). >>>>>=20 >>>>> Instead we=92re giving people an OAuth access token to access a=20 >>>>> protected API, something that OAuth clients ought to know how >>>>> to do anyway. This mechanism also gives us an opportunity to >>>>> potentially use the new PoP tokens (once they=92re actually >>>>> defined) in place of the bearer credential that=92s defined >>>>> today. >>>>>=20 >>>=20 >>> I believe I now understand your line of argument. >>>=20 >>> You are saying that re-using the client secret for this purpose >>> will confuse developers since the client credential is used in >>> other places as well. >>>=20 >>> So, the confusion could then be: >>>=20 >>> * Client starts the dynamic client registration exchange without a=20= >>> client secret. * Later than that exchange he gets a client secret, >>> which is supposed to be used for the dynamic client registration >>> management only * A developer might think that he can now also use >>> that client secret with anything else as well where a client secret >>> can be used. >>>=20 >>>=20 >>> The questions are now: >>>=20 >>> a) Is this potential confusion real or just imagined? b) Wouldn't >>> this be desired behaviour to begin with? >>>=20 >>> If it is a real concern and if you don=92t' want to have that >>> behaviour then maybe you want to motivate the design decision in >>> that direction in Section 1.4. >>>=20 >>>=20 >>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>> In Section 1.4.1. "Credential Rotation" you write: >>>>>>>>=20 >>>>>>>> " The Authorization Server MAY rotate the client's >>>>>>>> registration access token and/or client credentials (such >>>>>>>> as a "client_secret") throughout the lifetime of the >>>>>>>> client. " >>>>>>>>=20 >>>>>>>> You might want to add reasons why the authorization >>>>>>>> server may want to take this step. >>>>>>>=20 >>>>>>> OK, but there's nothing normative here in my view. It's >>>>>>> basically up to the auth server to say "well let's make a >>>>>>> new credential". Can you suggest text that would clarify >>>>>>> this? >>>>>>>=20 >>>>>>=20 >>>>>> What about making the spec simpler by not allowing credential >>>>>> rotation? Rekying is a useful concept under two >>>>>> circumstances, namely * when they provide a performance >>>>>> improvement (such as it is the case with session resumption >>>>>> in TLS where you can do an abbreviated handshake without all >>>>>> the heavy public key crypto) * when the entrophy of the key >>>>>> is exhausted, which typically happens if you exceed a number >>>>>> of data packets sent under a given key. Often this is tied to >>>>>> the way how freshness is ensured and the need to avoid=20 >>>>>> encrypting data with the same initialization vector/nonce >>>>>> twice. >>>>>>=20 >>>>>> Neither of these two cases seem to apply here (IMHO). >>>>>=20 >>>>>=20 >>>>> Rekeying the client is useful in a whole lot more cases than >>>>> these two, and most of them boil down to =93Something seems >>>>> fishy=94. I think if anything we need to eventually figure out >>>>> how to do *more* secret rotation, including a proactive >>>>> mechanism started by the client (as Brian has mentioned, among >>>>> others). >>>>>=20 >>>=20 >>>=20 >>> The alternative to rekeying (or secret rotation) inside the >>> dynamic client registration management protocol is to actually >>> re-start the protocol run from scratch. >>>=20 >>> To me it is not obvious whether the added complexity for >>> credential rotation is worth the effort given the alternative. >>>=20 >>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>> There are also a bit too many SHOULDs in the document. >>>>>>>> Every time you write SHOULD you have to keep in mind to >>>>>>>> tell the reader what happens in the other case. For >>>>>>>> example, in Section Section 1.4.1 you write: >>>>>>>>=20 >>>>>>>> " The registration access token SHOULD be rotated only in >>>>>>>> response to an update request to the client configuration >>>>>>>> endpoint, at which point the new registration access >>>>>>>> token is returned to the client and the old registration >>>>>>>> access token SHOULD be discarded by both parties. " >>>>>>>>=20 >>>>>>>> Here the question arises whether you are using the SHOULD >>>>>>>> to indicate that the authorization server does not always >>>>>>>> need to rotate the registration access token and if he >>>>>>>> does then is must only happen in response to an update >>>>>>>> request or does it indicate that the authorization server >>>>>>>> could also rotate it in response to other calls? >>>>>>>=20 >>>>>>> It's more that the server SHOULD NOT throw out a >>>>>>> registration access token that a client still thinks is >>>>>>> good without some way to communicate the new token to the >>>>>>> client. Think of it this way, you've got the token, the >>>>>>> server decides to chuck it on you -- what do you do? You >>>>>>> can try calling your READ or UPDATE operations to get the >>>>>>> new one but no dice, your token is bad. So what we're >>>>>>> saying here is not to throw out the client's only means of >>>>>>> finding out if its keys are good anymore. >>>>>>=20 >>>>>> I think I got confused with the description of the state >>>>>> management (as described in the document). There is some >>>>>> fuzziness. >>>>>>=20 >>>>>> Here I would prefer to have either no rekeying (which would >>>>>> make the issue go away) or a very deterministic way of >>>>>> rekeying. >>>>>>=20 >>>>>> I prefer the former. >>>>>=20 >>>>> I=92m not a fan of enforcing permanent credentials on the world. >>>>> And we have the same construct with refresh tokens today, for >>>>> what it=92s worth. >>>=20 >>> It is only permanent in the sense of a full dynamic client >>> registration management protocol run. >>>=20 >>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Also, in the second line one would wonder why the old >>>>>>>> registration access token isn't mandatorily discarded. If >>>>>>>> there are good reasons, then tell the reader. >>>>>>>=20 >>>>>>> We've tried to put requirements on the server discarding >>>>>>> tokens in the past, but there was significant pushback from >>>>>>> providers who use non-revocable time-limited tokens. Maybe >>>>>>> they won't be doing that here, for the reason above. >>>>>>=20 >>>>>>=20 >>>>>> I wouldn't reflect that in the document. Of course, you can >>>>>> never be sure that the implementation really discards any >>>>>> state but for the purpose of the protocol state machine it is >>>>>> gone. >>>>>>=20 >>>>>>>=20 >>>>>>>> Furthermore, the text in Section 2.2 seems to contract >>>>>>>> this statement: " If the authorization server includes a >>>>>>>> new client secret and/or registration access token in its >>>>>>>> response, the client MUST immediately discard its >>>>>>>> previous client secret and/or registration access token. >>>>>>>> " >>>>>>>=20 >>>>>>> This is a requirement on the client, not the server, so >>>>>>> it's not bound by the token lifetime restrictions above. >>>>>>> We're telling the client to stop using a secret or token >>>>>>> after it's been given a new one, that's fine. >>>>>>=20 >>>>>> OK >>>>>>=20 >>>>>>>=20 >>>>>>>> In Section 2.2 you write: " However, since read >>>>>>>> operations are intended to be idempotent, the read >>>>>>>> request itself SHOULD NOT cause changes to the client's >>>>>>>> registered metadata values. " >>>>>>>>=20 >>>>>>>> I am wondering whether this SHOULD NOT statement adds a >>>>>>>> lot of value since you allow the request to change >>>>>>>> metadata values. >>>>>>>=20 >>>>>>> I think you're right, since the metadata values might have >>>>>>> changed through outside forces since the client last read, >>>>>>> and all the clients need to be able to deal with that. We >>>>>>> can remove that line. >>>>>>=20 >>>>>> OK >>>>>>=20 >>>>>>>=20 >>>>>>>> You also write the security consideration section: " the=20 >>>>>>>> registration access token MAY be rotated when the >>>>>>>> developer or client does a read or update operation on >>>>>>>> the client's client configuration endpoint. " >>>>>>>>=20 >>>>>>>> This means that the content of the registration access >>>>>>>> token may also change with a read operation. >>>>>>>=20 >>>>>>> That's correct. >>>>>>>=20 >>>>>>>> Terminology: >>>>>>>>=20 >>>>>>>> Sometimes you write "Client Information Response" and >>>>>>>> sometimes "client information response" The same with >>>>>>>> "Authorization Server" and "authorization server" >>>>>>>=20 >>>>>>> They're all supposed to be lower cased, as is the style in >>>>>>> RFC6749. I tried to bump everything down in a previous edit >>>>>>> but it looks like I missed some. >>>>>>>=20 >>>>>>>> Typo: >>>>>>>>=20 >>>>>>>> " Some values in the response, including the >>>>>>>> "client_secret" and r"egistration_access_token", MAY be >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ different from those in the >>>>>>>> initial registration response. " >>>>>>>=20 >>>>>>> Thanks, noted! >>>>>>>=20 >>>>>>>>=20 >>>>>>>> In Section 2.4 "Client Delete Request" you write: >>>>>>>>=20 >>>>>>>> " The authorization server SHOULD immediately invalidate >>>>>>>> all existing authorization grants and currently-active >>>>>>>> tokens associated with this client. " >>>>>>>>=20 >>>>>>>> Under what circumstances wouldn't the authorization >>>>>>>> invalidate all grants and active tokens? >>>>>>>=20 >>>>>>> When it's using a non-revocable stateless token and it >>>>>>> can't physically do that. Too bad 2119 doesn't have MUST IF >>>>>>> POSSIBLE or equivalent. >>>>>>=20 >>>>>> Maybe it would be good to add this information. >>>>>>=20 >>>>>> It might also be worthwhile whether this notion of a >>>>>> non-vocable stateless token actually exists in this context >>>>>> since we are really talking about the same infrastructure >>>>>> here. This registration management mechanism is really very >>>>>> central to the authorization server (unlike some other access >>>>>> token mechanisms where we talk about the resource server, >>>>>> which may be in a different administrative domain even). >>>>>=20 >>>>> Why doesn=92t the existing SHOULD cover this? >>>=20 >>> Because the should does not explain when to revoke the >>> grants/tokens and when not to do it. You wrote it in this email (in >>> context of these non-revocable tokens) but how should an >>> implementer know when he reads through the draft? >>>=20 >>> The problem is really about assumptions being made that are not=20 >>> explained further. For example, the assumption that there are >>> tokens that are not revocable and the implications that result from >>> those on the design of the protocol (potentially at multiple places >>> in the document). >>>=20 >>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> You might also want to say what tokens you are talking >>>>>>>> about since there are at least the following tokens >>>>>>>> around: - access tokens - refresh tokens - registration >>>>>>>> access tokens - initial access token >>>>>>>=20 >>>>>>> OK, we can add that. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> " If the server does not support the delete method, the >>>>>>>> server MUST respond with an HTTP 405 Not Supported. " >>>>>>>>=20 >>>>>>>> Why aren't you demanding that the server must support >>>>>>>> this method? This would essentially mean that there would >>>>>>>> be some cases where deregistration isn't possible. Of >>>>>>>> course, there may be the question how important >>>>>>>> deregistration actually is if the registration=20 >>>>>>>> automatically expires. >>>>>>>=20 >>>>>>> Because delete is not always an easy operation to >>>>>>> implement. The client should be able to call the endpoint >>>>>>> with the DELETE verb and at least know if it's allowed to >>>>>>> do that or not. >>>>>>=20 >>>>>> Hmmm. I didn't know that the delete method is difficult to >>>>>> implement. >>>>>=20 >>>>> Depends on your infrastructure and how things get propagated >>>>> between components. >>>=20 >>> There are a number of unstated assumptions here that would be >>> worthwhile to point out. >>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> You write: " If the client does not exist on this server, >>>>>>>> the server MUST respond with HTTP 401 Unauthorized and >>>>>>>> the registration access token used to make this request >>>>>>>> SHOULD be immediately revoked. " >>>>>>>>=20 >>>>>>>> If the client does not exist and someone sends a request >>>>>>>> with a random registration access token I am not sure >>>>>>>> what exactly you want to revoke here. >>>>>>>=20 >>>>>>> It's not the case of a random token, it's the case of a >>>>>>> client having been deleted but using an otherwise valid >>>>>>> access token. If the token's no good, you don't get this >>>>>>> far -- you return a 401 as defined in RFC6750. >>>>>>=20 >>>>>> I guess it might make sense to add this information. >>>>>=20 >>>>> It=92s already in there, in the paragraph just before the one you >>>>> quoted: >>>>>=20 >>>>> If the registration access token used to make this request is >>>>> not valid, the server MUST respond with an error as described >>>>> in OAuth Bearer Token Usage [RFC6750 >>>>> ]. >>>>>=20 >>>=20 >>>=20 >>> But the argument that you provided is for "the case of a client >>> having been deleted but using an otherwise valid access token" but >>> the text you cite talks about the registration access token not >>> being valid. Those appear to be two different cases. >>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> In Section 3.1. "Client Information Response" you state >>>>>>>> the new elements that are returned to the client. While >>>>>>>> the client_secret has an expires_at field the >>>>>>>> registration_access_token doesn't. Does the expiry value >>>>>>>> of the client_secret_expires_at automatically indicate >>>>>>>> the lifetime of the registration access token? I think=20 >>>>>>>> so. But what happens if the client_secret is not issued? >>>>>>>> To make it more complicated you write the following text >>>>>>>> in the security consideration section: >>>>>>>>=20 >>>>>>>> " While the client secret can expire, the registration >>>>>>>> access token SHOULD NOT expire while a client is still >>>>>>>> actively registered. " >>>>>>>=20 >>>>>>> There isn't a separate expiration for the registration >>>>>>> access token because it's not supposed to unceremoniously >>>>>>> expire on a client. It should be good until it gets rotated >>>>>>> out on a future read/update operation or the client's >>>>>>> registration is no good anymore. >>>>>>=20 >>>>>> I think it might be good to have a small section that >>>>>> explains how state management works. >>>>>=20 >>>>> Can you suggest text for this beyond the paragraph that=92s >>>>> already there? >>>=20 >>> Yes, I can do that. If you could ship a new update then I can read=20= >>> through the entire document again and figure out how to create a >>> state machine. >>>=20 >>> If you, of course, get rid of this credential rotation then I don't >>> have to do it though. >>>=20 >>>=20 >>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IANA consideration section is empty. Wouldn't it be >>>>>>>> necessary to register 'registration_access_token' and=20 >>>>>>>> 'registration_client_uri' into the OAuth Dynamic >>>>>>>> Registration Client Metadata Registry? >>>>>>>=20 >>>>>>> No, these are not client metadata. The client can not send >>>>>>> these in a registration request, so they don't need to be >>>>>>> in there. >>>>>>=20 >>>>>> Really? >>>>>>=20 >>>>>> I thought that the IANA registry created with Section 5.1 of=20 >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was >>>>>> meant to be used with the Client Registration Request and the >>>>>> Client Registration Response exchange. The >>>>>> 'registration_access_token' and 'registration_client_uri' >>>>>> parameters are used in the response. >>>>>>=20 >>>>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an >>>>>> inconsistency: The protocol interaction should either be >>>>>>=20 >>>>>>=20 >>>>>> C -> AS: Client Registration Request C <- AS: Client >>>>>> Registration Response >>>>>>=20 >>>>>> OR >>>>>>=20 >>>>>> C -> AS: Client Registration Request C <- AS: Client >>>>>> Registration Error Response >>>>>>=20 >>>>>> Currently, sometimes the term "Client Registration Response" >>>>>> or "Client Information Response" is used. We need to fix this >>>>>> since it spills over to the management API document as well. >>>>>=20 >>>>> Client Information Response and Client Error Response are >>>>> sub-classes of Client Registration Response. If that=92s not >>>>> clear from the current document, please suggest new wording to >>>>> make it clearer. >>>=20 >>> As a shepherd I read through both documents in detail and I didn't=20= >>> figure that out. That gives me reasons to believe that others >>> wouldn't figure that out either. >>>=20 >>> I would make the change already in Figure 1 of Dynamic Client=20 >>> Registration Protocol document. >>>=20 >>>=20 >>>=20 >>> +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- >>> Software Statement (OPTIONAL) | | v v +-----------+ >>> +---------------+ | |--(C)- Client Registration Request >>> -->| Client | | Client or | >>> | Registration | | Developer |<-(D)- Client Registration >>> Response---| Endpoint | | | >>> +---------------+ +-----------+ >>>=20 >>> Client Registration Response:=3D Client Information Response OR=20 >>> Client Error Response >>>=20 >>> Same change to Figure 1 in the dynamic client registration >>> management document. You could even indicate in the figure which >>> parts are already specified in the dynamic client registration spec >>> and which are added via the dynamic client registration management >>> doc. >>>=20 >>>>>=20 >>>>>>=20 >>>>>> Also, I noticed that we say that the server MUST support TLS >>>>>> 1.2 RFC 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0 >>>>>> anymore. >>>>>=20 >>>>> Kathleen made a similar comment on dyn-reg and suggested text >>>>> that we=92ll incorporate (unless there are objections from others >>>>> on the list). >>>=20 >>> Ack. >>>=20 >>>>>=20 >>>>>>=20 >>>>>> In Figure 1 it might be useful to indicate that exchanges A, >>>>>> B, C, and D are inherited from the dynamic client >>>>>> registration document and only step D is enhanced with >>>>>> additional parameters, as described in Section 3.1. >>>>>> Furthermore, I wonder whether it would make sense to somehow=20 >>>>>> indicate in the figure that the endpoints are actually part >>>>>> of the Authorization Server. >>>>>=20 >>>>> While they usually are the same in practice, these endpoints >>>>> might not be part of the Authorization Server =97 they might be >>>>> part of a separate (but related) service that handles objects >>>>> of various kinds within a security domain. No reason to tie >>>>> them together unnecessarily. >>>=20 >>> You can state that someone in the text but endpoints by itself >>> don't exist since they have to be at some server. Even if the >>> endpoints are in separate boxes there needs to be a close >>> cooperation between the two since otherwise we create new >>> interoperability challenges. >>>=20 >>> Ciao Hannes >>>=20 >>>>>=20 >>>>> =97 Justin >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Ciao Hannes >>>>>>=20 >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ OAuth mailing >>>>>> list OAuth@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ OAuth mailing >>>>> list OAuth@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ OAuth mailing list=20= >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDExNTIxMDRaMCMGCSqGSIb3DQEJBDEWBBQKyD99L9GImvv4a72QnMzu UZl4UTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAe7r1oCR/Cl6lfzj3nsWZn4IPxLSdU7RGmZu3cZDcN2+ge6BSLyWoA CRBsOTLS8rv1rLbYsTGfyBMxkCR5PYOIi1G1IfFL049sEfacGQ5w0AGUcboneKhLkye/je/yEUZv xlCKm2sS6DTHS3hiL62O6IVKleITxSlj6JkfBA/bAAIeKb0/+ro6V3E8+ut42Wiq+O3iPkrlzo61 7fZu20FYZwK0siZwkp0Y6Lb+gd1wx6jK+JbfEv6LoDH4/28IQRfSk+24LlBzbPB3mETnW5ETiYT1 QHUT6JixFWFSwiamOd4h7AkaA7u1A2J5Zh8MllJ6u03g5nhZzMIjxQpHNPRWAAAAAAAA --Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63-- From nobody Mon Dec 1 08:25:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CE61A6F20 for ; Mon, 1 Dec 2014 08:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLb3INiUyoDx for ; Mon, 1 Dec 2014 08:25:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D9D1A1EEC for ; Mon, 1 Dec 2014 08:25:15 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MRjd7-1XTGiG399l-00SvAq for ; Mon, 01 Dec 2014 17:25:13 +0100 Message-ID: <547C9669.3060802@gmx.net> Date: Mon, 01 Dec 2014 17:25:13 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tbbVU1IUEaQP5bfNkpPwnSqdhuVcac2xC" X-Provags-ID: V03:K0:G2+1L+9I8B6b3I+XjZMzp29jFbToF/uHnih14rPp9k6HSjjXzgr DanpvbM1fS1s/rDB7i+TVwJHrQ05cGYuNRdK1GCsEreqYpqGxRXgKyY9OWuaLczDmKHzDJr UkiPGnYMz6kAbJ101iZImdeQk9Yvyy8tu0SRvs/fLMoCSo6rBqCJK357cd7RLaZukykxPwU ZUZM3U4xuYUWQkiO8urEw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/a8c8VYqJomt1I5mVzcjocndeChA Subject: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:25:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tbbVU1IUEaQP5bfNkpPwnSqdhuVcac2xC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I fear we have to write another article to clarify what OAuth does and what it does not do based on the misinformation spread with this recent article: http://www.techopedia.com/definition/26694/oauth A quote from that article: " Graham Williams, a Vancouver-based technology expert, points to what is known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94 w= here people often unwittingly share personal information with third-party websites. " Ciao Hannes --tbbVU1IUEaQP5bfNkpPwnSqdhuVcac2xC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfJZpAAoJEGhJURNOOiAtbncH/1e8pjnszRj6M/JUaytMGhdM 4qiWD4RPUZaD9JcmmIrQBHrDBFBzdPkuYxYuqGdys0BUn4NBg+2wkzoMkLInBUrt KVSiTA2GoBl8eQ6Ww91HVY6FindhI89CuE3ng+QDPmgOyM74SPJMMVTVL8jEpS2o aQfSPc9NLqdbR+RX/kZC6dZCC5PVfuI2Fx8LBMnnnsu9ElEtlqW23j/4F5wFZPrs nm2TgOWdgLu80/KjtMbSM8eonnH+PB9X7E1fU808p3YL0ZpqBh8HmnimnpJZEGF5 RKSxbbXOXXbHcNS6I0nDr+nZNgNIWYVsDmm5m6QMV69uWfAIq23sw2FHyPrUxVI= =1YNT -----END PGP SIGNATURE----- --tbbVU1IUEaQP5bfNkpPwnSqdhuVcac2xC-- From nobody Mon Dec 1 08:42:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF651A6F3F for ; Mon, 1 Dec 2014 08:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEnDRn1fQiPi for ; Mon, 1 Dec 2014 08:42:42 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6F71A6F2F for ; Mon, 1 Dec 2014 08:42:42 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so8948063lbi.18 for ; Mon, 01 Dec 2014 08:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AaEOebW27gUJi8C5PyFiynrrFkn7LTkCIPN47TxL7UA=; b=ad5k/LQ5NF9FjeKOZ7r7AVAtNhf+WPPqXBXgp3W2y7HcxXnV+jveHyQR0+ztQsDfqJ W9RQCgKpOovONTEs4J/9jZNNEECORdfPH2dHjNuW52SaSkJC8WqB0Q2LUfsRM7FX+Eob NuyF9UaUm3TmwFlPESbd9P8B9t7K9cR3jvuOb4169jE2kYsdH8nsyQ1wPVpTv5jfo6oA LJ0bHOqn6mPl9W8tJlEJPRDTyn2paEp2+XylGgg9YW91PKR9+6xpubIixDo5RzzpqlXf rpWfjE90L9feWR0x2UMr1BDOXuEwXUx2/a4T/0yroNQZ+djMmhDKa6x5s1S9IXJr/hIS nprQ== MIME-Version: 1.0 X-Received: by 10.152.238.1 with SMTP id vg1mr17573300lac.83.1417452160742; Mon, 01 Dec 2014 08:42:40 -0800 (PST) Received: by 10.112.49.52 with HTTP; Mon, 1 Dec 2014 08:42:40 -0800 (PST) In-Reply-To: <547C9669.3060802@gmx.net> References: <547C9669.3060802@gmx.net> Date: Mon, 1 Dec 2014 11:42:40 -0500 Message-ID: From: Kathleen Moriarty To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/EQQd0gB9TnNKlVYDBBAwCeYUhvE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:42:44 -0000 Hi Hannes, When something is written up and agreed upon, I'd recommend that we tweet about it in force to get the writeup some attention in an effort to help prevent this in the future. I could blog about it in the IESG blogs too if helpful. On Mon, Dec 1, 2014 at 11:25 AM, Hannes Tschofenig wrote: > Hi all, > > I fear we have to write another article to clarify what OAuth does and > what it does not do based on the misinformation spread with this recent > article: > http://www.techopedia.com/definition/26694/oauth > > A quote from that article: > " > Graham Williams, a Vancouver-based technology expert, points to what is > known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94 w= here people > often unwittingly share personal information with third-party websites. > " > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Mon Dec 1 09:03:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FB91A6FC6 for ; Mon, 1 Dec 2014 09:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MqlXymbG2yT for ; Mon, 1 Dec 2014 09:03:04 -0800 (PST) Received: from nm47-vm9.bullet.mail.bf1.yahoo.com (nm47-vm9.bullet.mail.bf1.yahoo.com [216.109.114.218]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751DB1A6FA9 for ; Mon, 1 Dec 2014 09:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417453383; bh=8v4g1UFLoekvCssbLqp0KlhkYYBKd4iErrCtFK6cONI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bLJPd3wR6G+VnGwvz0n/fulV/UB9Ea9vXw0GCDwuVp429jTEbNuiO4mm2siFMSdtrMsUhO1uo72dfukYJrQCdRUm6kJqEy0V/CP/dTa5TS5piMe3n2N/vWX/JgJR8QSmjhGZ9NGCXJtJmyMFZZf+qf3Iy2Z/hSGi5a7HGKNa+mK7Nz49enrQmHiL9puXUHGELmp8u4MSOm87G/qvTWlhL571B3U7ueYAI3TiXdLqZpEy4g5oGr+1aqRgIpFOi5Laq6KRKM1yXJfEygGz7md+dcBWwoXLKyB8bxf9jildqrBgalNmAF/L9afJ6poH+4qtyU/r4LakvYiEN/amkUq3LA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=CVAqOUPZrDRY6d1pLW85m9jlXDeHDeHuvBlx+I9mjQHDGUpxUyHsF410sfXFb6Pp4vFSPPmaDbQYcNDVq/w5gOsI0cxHlek5mJA3EyYFJEQhayxzi6YEQeEuMuK0hs1cuUrznQKR4/BIDReYVLDB+ynlpavBstqhgYbPwnQAc25UBioKNEq6QsLFUV3hBSUmbNTb6zne12CJE1qOufzCF7V3ay1Zf2wpgKcK4kIBAE1Enoah9eq/51yOtcqPFW5LI3h+Fa4Lp8nI8MsWvgbPGmNDfC5crOx5mREkXkHfj12hSBdtXdrFGhDzjNulaE5edo9/LG65G/fd37cTsj7baQ==; Received: from [66.196.81.174] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 17:03:03 -0000 Received: from [98.139.215.251] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 17:03:03 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 17:03:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 362683.62406.bm@omp1064.mail.bf1.yahoo.com X-YMail-OSG: hGHRjHQVM1mqAYOuPq9tgbVpevMeHNgwI08y1tnRkQewoBKPRCyQNPc13MEyxfv jpLlkkg7aaQUEcwGR7RI6oEXunlUMaUqgJA86QyWGUKU1qurREDAGBJ_DV497S11ikZVReoc88lW Qa0Lo6wm1DdtMyAy3TghzniRxK2CFQHIpK7i5uT01nmEnWjka.BXQSMHs3V.GlWokFaTTSlEAHx9 CWW1OaG1dxpM07Ve2US1WJjlcoLAkf7Zl5K6D4a5NtMzl02JG7JrxqKMEQOsduF.h8.tnq2LlW.5 xCqV_TeztRsqjR1ySMR9Kl9mOyVLqBWIdos2M9oxNrJpiwA0o91exeKSC1rm.d5St5ku32zE8oE0 59.BBEmCMF4R7P480hY58RLigrvgTAqggqu0oqUEpAZA0Xv9fQXu5s3G1fcnJ6AaKosXCWrF6p91 eCtrAhtJoBYBRKYR0ZYa7O0DpkBhqnQAtiI5h2IVR8P2ZPeMFE8HnR7tzvO7T_KaYwGTrymE3FHP OL0Kur_6pNbsjX9r1uX3hrCZjUqZzmL3dTR3Xca3H67oBLkcmIq3Hw60ESonHtYdi7SVaWjgdpEg ikvR6pasOENc5yQpr9ns- Received: by 66.196.80.149; Mon, 01 Dec 2014 17:03:02 +0000 Date: Mon, 1 Dec 2014 17:03:02 +0000 (UTC) From: Bill Mills To: Kathleen Moriarty , Hannes Tschofenig Message-ID: <216513212.3249460.1417453382544.JavaMail.yahoo@jws10654.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3249459_1875943157.1417453382540" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Z_w3v8T5E9QC20N79ToFF5wYSOg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:03:06 -0000 ------=_Part_3249459_1875943157.1417453382540 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable that link does not contain the quoted text. =C2=A0Also the quoted text isn'= t wrong when you look at the FB OAuth usage and how users actually use it.= =20 On Monday, December 1, 2014 8:42 AM, Kathleen Moriarty wrote: =20 Hi Hannes, When something is written up and agreed upon, I'd recommend that we tweet about it in force to get the writeup some attention in an effort to help prevent this in the future.=C2=A0 I could blog about it in the IESG blogs too if helpful. On Mon, Dec 1, 2014 at 11:25 AM, Hannes Tschofenig wrote: > Hi all, > > I fear we have to write another article to clarify what OAuth does and > what it does not do based on the misinformation spread with this recent > article: > http://www.techopedia.com/definition/26694/oauth > > A quote from that article: > " > Graham Williams, a Vancouver-based technology expert, points to what is > known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94 w= here people > often unwittingly share personal information with third-party websites. > " > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_3249459_1875943157.1417453382540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
that link does not contain the quoted text.  = Also the quoted text isn't wrong when you look at the FB OAuth usage and ho= w users actually use it.


=
On Monday, December= 1, 2014 8:42 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= ; wrote:


Hi Han= nes,

When something is written up and = agreed upon, I'd recommend that we
tweet about it in forc= e to get the writeup some attention in an effort
to help = prevent this in the future.  I could blog about it in the IESG
blogs too if helpful.

On Mo= n, Dec 1, 2014 at 11:25 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> Hi all,
>
> I fear we= have to write another article to clarify what OAuth does and
> what it does not do based on the misinformation spread with this = recent
> article:
> http://www.techopedia.com/definition/26694/oauth
>
> A quote from that article:
= > "
> Graham Williams, a Vancouver-based technology= expert, points to what is
> known as an "open authent= ication protocol" =E2=80=94 or OAuth =E2=80=94 where people
> often unwittingly share personal information with third-party websi= tes.
> "
>
>= Ciao
> Hannes
>
>
> _____________________________________________= __
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/oauth
>



--
=
Best regards,
Kathleen


______= _________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------=_Part_3249459_1875943157.1417453382540-- From nobody Mon Dec 1 09:51:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC11A1BCF for ; Mon, 1 Dec 2014 09:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PhcodjvzNoj for ; Mon, 1 Dec 2014 09:51:50 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCC71A1A7E for ; Mon, 1 Dec 2014 09:51:50 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so18299538wiv.8 for ; Mon, 01 Dec 2014 09:51:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=9YVi5T2zqklI8ZxQKKaw+qT4N4iT7+UkzGyNlDp5tk8=; b=iTZpmahoqhy+thkwUm5qk1EASdSKtHmwntwmP9s9Uvia6470AHbOmIJptb6FB98Zqu W+yC+Lv0d/3I4XaclsdohWjRPcPuW4Ibdw+HJGlwFfnwoz5Ox5LndYvofF9ixhp1gEXd FPLiar8JludRBK5qCcHv/DqsLeqi+vAGQW7JNyi7qmHtCDQyaJGuh0rHyFyxJNkFxAYS E2kJuap+18R4dl9kaaxnLcsKzmkRpSuZ6hX3fjhQYCbfmUhKBoZzs9Mytu1k61tpokOB xfPsV0pOc/gRElhoVncrRMLwZOapWp/HKnOCzlgpD/JOU7u3658dshzVZlf+q8pa+AY9 lhYQ== X-Gm-Message-State: ALoCoQkJSSAESEdW5cCEMGmK4yosc3YBeFUjYj5izeoUQRrGxE5/OWU5gz60nko+pwOCR3Ok24bY X-Received: by 10.194.235.193 with SMTP id uo1mr94250526wjc.105.1417456309046; Mon, 01 Dec 2014 09:51:49 -0800 (PST) Received: from [10.47.81.161] (host217-39-14-209.in-addr.btopenworld.com. [217.39.14.209]) by mx.google.com with ESMTPSA id hz9sm28524508wjb.17.2014.12.01.09.51.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 09:51:48 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8C793B51-6F09-4659-BA40-05E9CBB12975"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547C9669.3060802@gmx.net> Date: Mon, 1 Dec 2014 14:51:46 -0300 Message-Id: <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> References: <547C9669.3060802@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Z5TZEt4WjHJ7iuriKttktv4eqpA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:51:52 -0000 --Apple-Mail=_8C793B51-6F09-4659-BA40-05E9CBB12975 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hannes, I think this may be the link you were trying to share. http://www.cbc.ca/m/touch/news/story/1.2844953 I suspect the problem was the profile ID leaking via a ad rather than = anything to do with OAuth as she never logged in. =20 John B. > On Dec 1, 2014, at 1:25 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I fear we have to write another article to clarify what OAuth does and > what it does not do based on the misinformation spread with this = recent > article: > http://www.techopedia.com/definition/26694/oauth >=20 > A quote from that article: > " > Graham Williams, a Vancouver-based technology expert, points to what = is > known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94 = where people > often unwittingly share personal information with third-party = websites. > " >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8C793B51-6F09-4659-BA40-05E9CBB12975 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDExNzUxNDdaMCMGCSqGSIb3DQEJBDEWBBTXSaBFV/xdppLAEBDHeZci 8EYznTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBe8AZky5+bdMvjIQFIO7yy6M+2/GCrWAtmBUoxG/DFaMVmHEvYbWtE nveGYAAIMgCjbYMkOkVPDEnhbawiKd9k9wh1HoTt9LQKbv2/N1Ybcn9btdIFdC1rAYZNDollGolt nLQRwIK0XzNrtV8MfQ70u3IETs/TJ6K5Rjg3P5tMKmrmrTLrFMAFS3c+4Qn8OkVQ/6qIG7omWpWB 8u8vpiyDKPEQS0fwsKeId3eL+yJXAnhNfVUuc/7vDUvabOIgOi+9MBCTKApAhHi1ypBziR2mSkP0 G/omf16UCxKRdQYNUfPtpBXcUTuApRUjhqdWx3kulzkB2OPxu7/xAK/WcNSaAAAAAAAA --Apple-Mail=_8C793B51-6F09-4659-BA40-05E9CBB12975-- From nobody Mon Dec 1 10:34:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10341A6F14 for ; Mon, 1 Dec 2014 10:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI7725LdU--l for ; Mon, 1 Dec 2014 10:34:09 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC141A6F11 for ; Mon, 1 Dec 2014 10:34:08 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB1IY3jf009689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Dec 2014 18:34:04 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB1IY2SH001880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Dec 2014 18:34:03 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB1IY23s002691; Mon, 1 Dec 2014 18:34:02 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Dec 2014 10:34:02 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: Date: Mon, 1 Dec 2014 10:33:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3791F71C-238C-4413-B3EF-04314565DC44@oracle.com> References: <547C9669.3060802@gmx.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ICSbPuJihoGwr80Ht8po0R9rAeU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:34:12 -0000 One thing to think about is that often people are talking in different = ways about the same thing. E.g. in the article, people are talking about = authentication as a service, where as in the IETF we talk about = authentication as a protocol. Mike, Tony, and I ran into this when we named the draft =E2=80=9CUser = Authentication for Clients=E2=80=9D. What we recognized was that at a = protocol level, OAuth is being used to pass session information to a = client. UA4C doesn=E2=80=99t do authentication but passes parameters and = session information. When we talked about UA4C in the OAuth WG we got = caught up (wrongly) in whether OAuth WG even has a mandate that includes = authentication. Yet, =E2=80=9Cauthentication service=E2=80=9D is all = over OAuth (directly and indirectly - e.g. client authentication vs user = authen). Developers use OAuth as a service because it depends on = authentication of all parties (Users, clients, and service providers, = and endpoints). Yet, in naming the draft we had to address the idea that what client = developers want is access to a User authentication =E2=80=9Cservice=E2=80=9D= which is how they view OAuth. The difference between authentication as a =E2=80=9Cservice=E2=80=9D vs. = =E2=80=9Cprotocol=E2=80=9D is subtle but seems important. I=E2=80=99m = not sure if this is the thread that can explain the difference to the = common IETF contributor and developer communities =E2=80=94 otherwise, = I=E2=80=99d be all over it. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 1, 2014, at 8:42 AM, Kathleen Moriarty = wrote: >=20 > Hi Hannes, >=20 > When something is written up and agreed upon, I'd recommend that we > tweet about it in force to get the writeup some attention in an effort > to help prevent this in the future. I could blog about it in the IESG > blogs too if helpful. >=20 > On Mon, Dec 1, 2014 at 11:25 AM, Hannes Tschofenig > wrote: >> Hi all, >>=20 >> I fear we have to write another article to clarify what OAuth does = and >> what it does not do based on the misinformation spread with this = recent >> article: >> http://www.techopedia.com/definition/26694/oauth >>=20 >> A quote from that article: >> " >> Graham Williams, a Vancouver-based technology expert, points to what = is >> known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94= where people >> often unwittingly share personal information with third-party = websites. >> " >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 1 10:58:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482EB1A8954 for ; Mon, 1 Dec 2014 10:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcf8HPpD1U14 for ; Mon, 1 Dec 2014 10:58:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C361A894F for ; Mon, 1 Dec 2014 10:58:12 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mbfyr-1XdATX0ktx-00J1jr; Mon, 01 Dec 2014 19:58:10 +0100 Message-ID: <547CBA40.3080004@gmx.net> Date: Mon, 01 Dec 2014 19:58:08 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <547C9669.3060802@gmx.net> <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> In-Reply-To: <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gAwQbI7FD2JUTBbO1mVrMupI0hMmllIk2" X-Provags-ID: V03:K0:dLRtXylryY4oIrOX2NEfrpdU8AJTV3+a42oJNOZ9UQb5s2Gyuh3 teqV8xAmUPomYZ7MubC9GflHAYYfuJST78sVMV70wdt9Kq6mNp7WYi6zr5d6hkzs8C7ahV5 nuK79PXCF8W1KN3U/UfOWpNI1JMFAstUZJIzLPmss1lIVK5Up5O5mM9J11lepyPcA78kk8U Upv9EmIBAPeSd0ZIklEqw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NIK2XFabtDjH54zyTGV0bmrj-DY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:58:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gAwQbI7FD2JUTBbO1mVrMupI0hMmllIk2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, this is the story. Sorry for including the wrong link. We can find out what the issue was but that wasn't necessarily my point. The problem is that there is unfortunately little understanding about the different layers and responsibilities involved. I think there is something to write about and I will compile a first draft. Ciao Hannes On 12/01/2014 06:51 PM, John Bradley wrote: > Hannes, >=20 > I think this may be the link you were trying to share. > http://www.cbc.ca/m/touch/news/story/1.2844953 >=20 > I suspect the problem was the profile ID leaking via a ad rather than a= nything to do with OAuth > as she never logged in. =20 >=20 > John B. >=20 >=20 >> On Dec 1, 2014, at 1:25 PM, Hannes Tschofenig wrote: >> >> Hi all, >> >> I fear we have to write another article to clarify what OAuth does and= >> what it does not do based on the misinformation spread with this recen= t >> article: >> http://www.techopedia.com/definition/26694/oauth >> >> A quote from that article: >> " >> Graham Williams, a Vancouver-based technology expert, points to what i= s >> known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80=94= where people >> often unwittingly share personal information with third-party websites= =2E >> " >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --gAwQbI7FD2JUTBbO1mVrMupI0hMmllIk2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfLpAAAoJEGhJURNOOiAtLTkH/1qW8TuvYqUrfzOFWWJ99WaZ 6C7HLAJA7IRSDseY8okLQjmhul0emhQ24Ehxy1pEB1q/4dhqwB8eebqFRbKhUuBg ZYLgwYgHl7PxaYXwYYLFrhOqlg2reWEDmyO2h5oZ4U727t6VWuouClSnYFzmEMb+ hAn1sbM1K+1B0BsDMpW/VlSEYQKicTtxiWeV5vFmWhQ87oRDC+81omc35s+ZmweP +5L3XqRswb5cDppJogxKM/1AuAsQgM6htUWWb4OB04p/a4+/a1talT2qSJUqDxSw roMmG+BNkrMUdmj4OpCCpG4wnzhqrmjehx/keNk8hEGgphJrXlW/UzSV3tPSBEM= =s+yI -----END PGP SIGNATURE----- --gAwQbI7FD2JUTBbO1mVrMupI0hMmllIk2-- From nobody Mon Dec 1 12:04:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA0C1ACE0C for ; Tue, 25 Nov 2014 11:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN6O-TvI7sYF for ; Tue, 25 Nov 2014 11:21:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FD01ACE1D for ; Tue, 25 Nov 2014 11:21:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125192101.32607.82639.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:21:01 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LQnHqdJUTwJikmC6n1uO-6gi5dM X-Mailman-Approved-At: Mon, 01 Dec 2014 12:04:48 -0800 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:21:06 -0000 Changed milestone "Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Mon Dec 1 12:04:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730551A6EED for ; Tue, 25 Nov 2014 11:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySq9geajRS8a for ; Tue, 25 Nov 2014 11:21:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8891ACE0C for ; Tue, 25 Nov 2014 11:21:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125192154.30693.47703.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:21:54 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sjq_EVxd7X_KRe0zITD5ylFfQWo X-Mailman-Approved-At: Mon, 01 Dec 2014 12:04:49 -0800 Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:22:01 -0000 Changed milestone "Submit 'OAuth 2.0 Dynamic Client Registration Management Protocol' to the IESG for consideration as an Experimental RFC", set state to active from review, accepting new milestone. Changed milestone "Submit 'Symmetric Proof of Possession (SPOP) for the OAuth Authorization Code Grant' to the IESG for consideration as a Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Mon Dec 1 15:49:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE431A89AF for ; Mon, 1 Dec 2014 15:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl2L-vaKj-Mp for ; Mon, 1 Dec 2014 15:49:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C159E1ACC89 for ; Mon, 1 Dec 2014 15:49:43 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 23:49:20 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0026.003; Mon, 1 Dec 2014 23:49:20 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] draft-ietf-oauth-introspection Thread-Index: AdAMxAKwZxroeEnvQECE1qCS/1bO3AAToa8AACr/M7A= Date: Mon, 1 Dec 2014 23:49:20 +0000 Message-ID: References: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> In-Reply-To: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0412A98A59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(24454002)(199003)(189002)(377454003)(54206007)(77156002)(21056001)(92566001)(92726001)(46102003)(31966008)(50986999)(76176999)(54356999)(4396001)(76576001)(19300405004)(64706001)(54606007)(74316001)(230783001)(20776003)(19580395003)(16236675004)(19580405001)(120916001)(99396003)(15975445006)(40100003)(122556002)(97736003)(95666004)(19617315012)(19625215002)(86362001)(2656002)(106356001)(33656002)(15202345003)(77096004)(101416001)(107046002)(2171001)(87936001)(105586002)(110136001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234973440252E2F6A36D770A67D0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ReYp0XMilPeEl6DFV06hpA9Yr2Y Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:49:50 -0000 --_000_BN3PR0301MB1234973440252E2F6A36D770A67D0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the update, there are still some unclear points 1. Is the metadata (introspection response) being returned from the a= uthorization endpoint or from the token or a combination of both ? 2. "context" there may be no context other than the token, are you ex= pecting the authorization endpoint to always keep a context of how/why the = token was issued ? 3. The specification should clearly state which type of tokens are su= pported and what profiles/bindings are supported, like JWT Bearer, etc. 4. If I have an SAML Bearer assertion, and the SAML assertion is encr= ypted and have no way to know this, it can potentially fail if it can't be = decrypted but as far as I can tell I'm not sending an encrypted token since= this is just a SAML assertion, not sure how one really determines what is = wrong 5. Should be spelled out what "active" is supposed to mean so folks g= et the same results on different endpoints From: Justin Richer [mailto:jricher@mit.edu] Sent: Sunday, November 30, 2014 6:57 PM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection Tony, thanks for the comments. Your timing is great, as I was just today si= tting down to polish the introspection draft into a proper WG document read= y for the last-call tomorrow. I've just posted the updated draft, and I thi= nk that you'll find it addresses your concerns. More direct answers inline: On Nov 30, 2014, at 1:01 PM, Anthony Nadalin > wrote: Comments Intro "about the authentication conext", not sure what this is since there is no = authentication context in Oauth There are several authentication contexts in OAuth: the resource owner at t= he authorization endpoint, the client at the token endpoint, etc. Regardles= s, this is meant to be the context of the authorization decision, text now = reads: "context in which the token was issued" Use of Oauth2, mixed with use of Oauth, pick one All usage changed to "OAuth 2.0" throughout the document, let me know if I = missed any. "allows holder of a token to query" so anything/anyone that has a token can= use this endpoint? Now reads authorized holder of the token and has stronger language and reco= mmendations about requiring authorization on the endpoint to prevent public= token fishing. This was already addressed in the security considerations s= ection, but that has been propagated throughout the specification now. Introspection Endpoint Use of Oauth2, mixed with use of Oauth, pick one See above. Introspection Request The endpoint SHOULD also require some form of authentication", what about s= ome form of authorization ? Why do we have to have another endpoint that we= have to manage and then have a management API draft?] This is now clearer that it needs to be an authorized protected resource. T= his authorization may be carried through a credential mechanism as defined = in OAuth 2.0, through an access token, or through some other mechanism. Token - is this any type of token ? how does the endpoint know that it can = deal with this token type? Clarified that it's either the access_token from the token endpoint or the = refresh_token from the token endpoint. You can use this with other token ty= pes, but that's not defined in this spec which concerns itself with RFC6749= /RFC6750. So endpoint has to try to lookup token to determine if it can maybe find o= ut something about the token? That's the idea, the protected resource is asking an authoritative source (= the authorization server) about a given token. I had always thought it was = obvious that the authorization server would have to be able to know somethi= ng about the token in order to provide an introspection service, but since = that seems to have been unclear to some I've made it explicit in the securi= ty considerations section. Can the one use the authorization code or does one have to get a token firs= t? No, this is for tokens only. I don't see the point of introspecting an auth= orization code - those aren't sent to protected resources, they're sent to = clients, which would in turn just hand it to the token endpoint to get a to= ken. There's nothing else to find out about it. Can I send a encrypted token and expect a proper response ? If the server can decrypt or otherwise understand the token, yes. I've poin= ted out this requirement in the security considerations section. What about a Proof of Possession Token? Yes, I think this fits great with PoP tokens, but those aren't defined well= enough yet to say anything concrete. As the PoP work progresses, we can ha= ve an extension document to determine what needs to be done there. Note tha= t we'll have to do the same thing with the Revocation RFC. Introspection Response What is "active" mean ? Is this up to the server to determine ? It means the token is live, hasn't been revoked, was actually issued by thi= s server, isn't expired, and the protected resource that's asking has the r= ight to know all that information. This is all up to the server to determin= e. If the server can't determine that information for its own tokens, it pr= obably shouldn't be offering this service. "scope OPTIONAL", is this the scope in the token or is this the scope that = the introspection endpoint sources may have ? It's unclear if all these ret= urn values are from the token or from the introspection endpoint sources ? These are the scopes of the token. All return values are, as stated, metada= ta about the token itself that is being queried against. What error codes/conditions are there? Just the 400 (bad request)? The errors are more clearly spelled out. Most of it involves bad client aut= hentication (when client credentials are used), bad authorization (when acc= ess tokens are used to access the introspection endpoint itself), or the li= ke. If the token being introspected isn't good, that's still a 200 response= - the request is fine, but the token being introspected isn't active, whic= h is what's returned. This isn't an error, it's a valid answer to the quest= ion of "what is this token?" that's being asked every time introspection is= called. Can the endpoint return a encrypted response ? That's outside the scope of this document. It returns JSON like the rest of= OAuth. What about PII such as user_id, aud ? This is now covered in the Privacy Considerations section, which wasn't A T= hing when this draft was first written. - Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BN3PR0301MB1234973440252E2F6A36D770A67D0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the update,= there are still some unclear points

 

1.&n= bsp;      Is the metadat= a (introspection response) being returned from the authorization endpoint o= r from the token or a combination of both ?

2.&n= bsp;      “context= ” there may be no context other than the token, are you expecting the= authorization endpoint to always keep a context of how/why the token was i= ssued ?

3.&n= bsp;      The specificat= ion should clearly state which type of tokens are supported and what profil= es/bindings are supported, like JWT Bearer, etc.

4.&n= bsp;      If I have an S= AML Bearer assertion, and the SAML assertion is encrypted and have no way t= o know this, it can potentially fail if it can’t be decrypted but as = far as I can tell I’m not sending an encrypted token since this is just a SAML assertion, not sure how one really determi= nes what is wrong

5.&n= bsp;      Should be spel= led out what “active” is supposed to mean so folks get the same= results on different endpoints

 

 

From: Justin Richer [mailto:jricher@mit.edu] =
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

 

Tony, thanks for the comments. Your timing is great,= as I was just today sitting down to polish the introspection draft into a = proper WG document ready for the last-call tomorrow. I’ve just posted= the updated draft, and I think that you’ll find it addresses your concerns. More direct answers inline:

 

 

On Nov 30, 2014, at 1:01 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:<= o:p>



Comments

 

Intro

“about the authentication conext”, not s= ure what this is since there is no authentication context in Oauth

 

There are several authentication contexts in OAu= th: the resource owner at the authorization endpoint, the client at the tok= en endpoint, etc. Regardless, this is meant to be the context of the authorization decision, text now reads: "contex= t in which the token was issued"



Use of Oauth2, mixed with use of Oauth, pick one

 

All usage changed to “OAuth 2.0” thr= oughout the document, let me know if I missed any.



“allows holder of a token to query” so a= nything/anyone that has a token can use this endpoint?

 

Now reads authorized holder of the token and has= stronger language and recommendations about requiring authorization on the= endpoint to prevent public token fishing. This was already addressed in the security considerations section, but that has= been propagated throughout the specification now. <= /p>



 

Introspection Endpoint

Use of Oauth2, mixed with use of Oauth, pick one

 

 

See above.




Introspection Request

The endpoint SHOULD also require some form of authen= tication”, what about some form of authorization ? Why do we have to = have another endpoint that we have to manage and then have a management API= draft?]

 

This is now clearer that it needs to be an autho= rized protected resource. This authorization may be carried through a crede= ntial mechanism as defined in OAuth 2.0, through an access token, or through some other mechanism. <= /p>



 

Token – is this any type of token ? how does t= he endpoint know that it can deal with this token type?

 

Clarified that it’s either the access_toke= n from the token endpoint or the refresh_token from the token endpoint. You= can use this with other token types, but that’s not defined in this spec which concerns itself with RFC6749/RFC6750. 



So endpoint has to try to lookup token  to dete= rmine if it can maybe find out something about the token?

 

That’s the idea, the protected resource is= asking an authoritative source (the authorization server) about a given to= ken. I had always thought it was obvious that the authorization server would have to be able to know something about the token in order to= provide an introspection service, but since that seems to have been unclea= r to some I’ve made it explicit in the security considerations sectio= n. 



Can the one use the authorization code or does one h= ave to get a token first?

 

No, this is for tokens only. I don’t see t= he point of introspecting an authorization code — those aren’t = sent to protected resources, they’re sent to clients, which would in turn just hand it to the token endpoint to get a token. There’s n= othing else to find out about it.



 Can I send a encrypted token and expect a prop= er response ?

 

If the server can decrypt or otherwise understan= d the token, yes. I’ve pointed out this requirement in the security c= onsiderations section. 



What about a Proof of Possession Token? <= /p>

 

Yes, I think this fits great with PoP tokens, bu= t those aren’t defined well enough yet to say anything concrete. As t= he PoP work progresses, we can have an extension document to determine what needs to be done there. Note that we’ll have to do= the same thing with the Revocation RFC.



 Introspection Response

What is “active” mean ? Is this up to th= e server to determine ?

 

It means the token is live, hasn’t been re= voked, was actually issued by this server, isn’t expired, and the pro= tected resource that’s asking has the right to know all that information. This is all up to the server to determine. If the server can&= #8217;t determine that information for its own tokens, it probably shouldn&= #8217;t be offering this service.



“scope OPTIONAL”, is this the scope in t= he token or is this the scope that the introspection endpoint sources may h= ave ? It’s unclear if all these return values are from the token or f= rom the introspection endpoint sources ?

 

These are the scopes of the token. All return va= lues are, as stated, metadata about the token itself that is being queried = against.



What error codes/conditions are there? Just the 400&= nbsp; (bad request)?

 

The errors are more clearly spelled out. Most of= it involves bad client authentication (when client credentials are used), = bad authorization (when access tokens are used to access the introspection endpoint itself), or the like. If the token be= ing introspected isn’t good, that’s still a 200 response —= ; the request is fine, but the token being introspected isn’t active,= which is what’s returned. This isn’t an error, it’s a va= lid answer to the question of “what is this token?” that’s b= eing asked every time introspection is called.



Can the endpoint return a encrypted response ?<= /o:p>

 

That’s outside the scope of this document.= It returns JSON like the rest of OAuth.



What about PII such as user_id, aud ?

 

This is now covered in the Privacy Consideration= s section, which wasn’t A Thing when this draft was first written.

 

 — Justin



_______________________________________________<= br> OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

 

--_000_BN3PR0301MB1234973440252E2F6A36D770A67D0BN3PR0301MB1234_-- From nobody Mon Dec 1 16:35:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6A1A912F for ; Mon, 1 Dec 2014 16:35:54 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82jV-nOxA9eM for ; Mon, 1 Dec 2014 16:35:51 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121AD1A1AC6 for ; Mon, 1 Dec 2014 16:35:51 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so15454267igb.0 for ; Mon, 01 Dec 2014 16:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=2wg+7rw4TO3ezmm4fux/pIzRxJGoki2WyT/gOSOB3As=; b=cz6PLEFxBnCLmkoQkK1uZxUKDfUBZVokgaaUMfWbCGGN8JH4eTqC7JcenSDhMHg444 NRrBjtOHzVXiH/LhHUHA2ODAs8bMHBoNZUMwB5RZVES4pe/6jMw2ops9LRbX7sDKKPJl Ou2uHwOq3LAZzdwa895XVBU1NjyptUnh0/AecsDp/NQvMSJ1VwHOfkvhrnfndoyNtFN1 nz0C8LFJ/V82ADSqeaV6uL0leRfwv/NO1o8Kg0Zcxltzuejl8OWodGUrjKtTEsoiDFje K4dKtkNw6QwhfT1In+zt7q9UM5KAZF597wGHxUJUVaKEu9waTEG6iW5lnuboLX7Llwbe oq5g== X-Received: by 10.42.146.201 with SMTP id k9mr553018icv.54.1417480550062; Mon, 01 Dec 2014 16:35:50 -0800 (PST) MIME-Version: 1.0 References: <547C9669.3060802@gmx.net> <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> <547CBA40.3080004@gmx.net> From: Nat Sakimura Date: Tue, 02 Dec 2014 00:35:49 +0000 Message-ID: To: Hannes Tschofenig , John Bradley Content-Type: multipart/alternative; boundary=90e6ba613b66a9a39e050930e80b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZhkieQWKVrPoDmfwplTFneDvb3E Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:35:54 -0000 --90e6ba613b66a9a39e050930e80b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The article is mislead in multiple ways. At its heart, it has nothing to do with the OAuth but the problem of explicit consent model, that people are trained to click "accept". Apparently, she did give her authorization to pull her profile to create Zoosk account. She did the on-the-fly provisioning to Zoosk, but this was "without her knowledge" because she clicked "accept" without reading. This is where consent receipt type of idea becomes more helpful. Cheers, Nat On Tue Dec 02 2014 at 3:58:28 Hannes Tschofenig wrote: > Yes, this is the story. Sorry for including the wrong link. > > We can find out what the issue was but that wasn't necessarily my point. > > The problem is that there is unfortunately little understanding about > the different layers and responsibilities involved. I think there is > something to write about and I will compile a first draft. > > Ciao > Hannes > > On 12/01/2014 06:51 PM, John Bradley wrote: > > Hannes, > > > > I think this may be the link you were trying to share. > > http://www.cbc.ca/m/touch/news/story/1.2844953 > > > > I suspect the problem was the profile ID leaking via a ad rather than > anything to do with OAuth > > as she never logged in. > > > > John B. > > > > > >> On Dec 1, 2014, at 1:25 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> > >> Hi all, > >> > >> I fear we have to write another article to clarify what OAuth does and > >> what it does not do based on the misinformation spread with this recen= t > >> article: > >> http://www.techopedia.com/definition/26694/oauth > >> > >> A quote from that article: > >> " > >> Graham Williams, a Vancouver-based technology expert, points to what i= s > >> known as an "open authentication protocol" =E2=80=94 or OAuth =E2=80= =94 where people > >> often unwittingly share personal information with third-party websites= . > >> " > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> 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 > --90e6ba613b66a9a39e050930e80b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The article is mislead in multiple ways. At its heart, it has nothing to do= with the OAuth but the problem of explicit consent model, that people are = trained to click "accept". Apparently, she did give her authoriza= tion to pull her profile to create Zoosk account. She did the on-the-fly pr= ovisioning to Zoosk, but this was "without her knowledge" because= she clicked "accept" without reading. This is where consent rece= ipt type of idea becomes more helpful. =C2=A0

Cheers= ,=C2=A0

Nat

On= Tue Dec 02 2014 at 3:58:28 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Yes, this is the story. Sorry for including the wrong l= ink.

We can find out what the issue was but that wasn't necessarily my point= .

The problem is that there is unfortunately little understanding about
the different layers and responsibilities involved. I think there is
something to write about and I will compile a first draft.

Ciao
Hannes

On 12/01/2014 06:51 PM, John Bradley wrote:
> Hannes,
>
> I think this may be the link you were trying to share.
> http://www.cbc.ca/m/touch/news/story/1.2844953
>
> I suspect the problem was the profile ID leaking via a ad rather than = anything to do with OAuth
> as she never logged in.
>
> John B.
>
>
>> On Dec 1, 2014, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I fear we have to write another article to clarify what OAuth does= and
>> what it does not do based on the misinformation spread with this r= ecent
>> article:
>> http://www.techopedia.com/definition/26694/oauth >>
>> A quote from that article:
>> "
>> Graham Williams, a Vancouver-based technology expert, points to wh= at is
>> known as an "open authentication protocol" =E2=80=94 or = OAuth =E2=80=94 where people
>> often unwittingly share personal information with third-party webs= ites.
>> "
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--90e6ba613b66a9a39e050930e80b-- From nobody Mon Dec 1 16:42:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F51A7004 for ; Mon, 1 Dec 2014 16:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4hgmra4vbtC for ; Mon, 1 Dec 2014 16:42:06 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74ED1A701B for ; Mon, 1 Dec 2014 16:42:05 -0800 (PST) X-AuditID: 1209190d-f793c6d000001ec0-27-547d0adc7e9d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.73.07872.CDA0D745; Mon, 1 Dec 2014 19:42:04 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sB20g3rc028263; Mon, 1 Dec 2014 19:42:04 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB20fxXm008923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2014 19:42:02 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Justin Richer In-Reply-To: Date: Mon, 1 Dec 2014 19:41:58 -0500 Message-Id: <4B1239F5-5DD3-4F1B-8691-75E8B07F3891@mit.edu> References: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsUixCmqrXuHqzbE4P4iIYuTb1+xWWyau43R gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGVsv5BTcGcOU8X8rZ3MDYzbvzJ2MXJySAiY SBxbdZAJwhaTuHBvPVsXIxeHkMBsJoklG9exgySEBDYwSnzo8YVI3GCSeDf/FVgVs8AkRon+ i7OZQap4BQwkluzaBGYLC5hJrFvawgZiswmoSkxf0wK2glMgUeLhhhlgNSwCKhLzp+wHO4MZ qObLgvdMEHOsJO4seQJ1xhNGibONt8GKRAS0JU68X8kMcau8xIcPx9knMArMQnbILCSHzAIb nCSx/+JaJghbW2LZwtdQcQOJp52vWDHF9SXevJsDVS8vsf3tHKi4pcTimTdYIGxbiVt9C6Bq 7CQeTVvEuoCRexWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZwxEny7mB8d1Dp EKMAB6MSD++J8zUhQqyJZcWVuYcYJTmYlER5F34ECvEl5adUZiQWZ8QXleakFh9iVAHa9WjD 6guMUix5+XmpSiK8j0FaeVMSK6tSi/JhyqQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8O7krA0REixKTU+tSMvMKUFIM3FwHmKU4OABGv4NpIa3uCAxtzgzHSJ/ilFRSpxXD5jqhARA EhmleXC9sET5ilEc6C1h3n0g7TzAJAvX/QpoMBPQYIbmSpDBJYkIKakGRt/s3XcEywXTXrwy Ov4370/Uc8O3K/mK33oGB0Wsr1Jn+sNaJNRwWjihVuLtiX27jxk62K7YtfX4sg3zOVfLSJ6Q efuEfZmm0KVpaXl2fKnbnshdkP8415Rrl8KXxqtnN1m0p+hurnuZcnVC6Y/vx47u4v1wMLv9 pvND18yFyoLn6k629VtpTlNiKc5INNRiLipOBAD6ZCCEbwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6bBFvbtVneUV6ES8Mz1Z3TAlb4w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:42:10 -0000 --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526 Content-Type: multipart/alternative; boundary="Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2" --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > 1. Is the metadata (introspection response) being returned from = the authorization endpoint or from the token or a combination of both ? As I said below, ultimately it=92s about the token and what it = represents. If the token was issued through use of the authorization = endpoint, then it=92s likely that there=92s some context from that = authorization endpoint tied to the token that can be returned. > 2. =93context=94 there may be no context other than the token, = are you expecting the authorization endpoint to always keep a context of = how/why the token was issued ? If you=92re asking if stateless tokens can be supported with this, then = yes, that=92s fine. If the token=92s completely on its own (like a = structured token generated as an assertion and used as an OAuth 2.0 = access token) and a server=92s able to unpack that for a client without = access to other pieces of context, then that=92s what it returns. But in = that case, if you=92re issuing stateless tokens, with self-contained = metadata and expirations and no other context to be conveyed beyond = what=92s already inside the token, then you=92d probably just tell your = protected resources how to parse and handle them directly.=20 > 3. The specification should clearly state which type of tokens = are supported and what profiles/bindings are supported, like JWT Bearer, = etc. That=92s opaque to the protected resource for purposes of this protocol, = just like a token is opaque to a client for purposes of 6749/6750 OAuth. = The introspection protocol supports whatever tokens are supported by the = AS, so we don=92t need to list token types, but maybe we can be clearer = about the opaqueness of the token value in this process. Since these are = OAuth tokens and not assertions, no bindings or profiles are needed = beyond this. It=92s a simple query-response and it=92s up to the server = to know how to fulfill this contract.=20 > 4. If I have an SAML Bearer assertion, and the SAML assertion is = encrypted and have no way to know this, it can potentially fail if it = can=92t be decrypted but as far as I can tell I=92m not sending an = encrypted token since this is just a SAML assertion, not sure how one = really determines what is wrong If the AS can=92t decrypt the token then it can=92t introspect it. So it = doesn=92t in this case. And if you=92re issuing encrypted OAuth tokens = with no means to decrypt them back at the AS, then you probably wouldn=92t= offer an introspection service to begin with. This is covered in the = security considerations section already. > 5. Should be spelled out what =93active=94 is supposed to mean = so folks get the same results on different endpoints As I said below, it means to answer =93is this token still good or not?=94= for a protected resource that can=92t answer that on its own, and I = believe the current definition reflects that. Please submit text if the = existing definition is insufficient or unclear to you. =97 Justin > =20 > =20 > From: Justin Richer [mailto:jricher@mit.edu]=20 > Sent: Sunday, November 30, 2014 6:57 PM > To: Anthony Nadalin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection > =20 > Tony, thanks for the comments. Your timing is great, as I was just = today sitting down to polish the introspection draft into a proper WG = document ready for the last-call tomorrow. I=92ve just posted the = updated draft, and I think that you=92ll find it addresses your = concerns. More direct answers inline: > =20 > =20 > On Nov 30, 2014, at 1:01 PM, Anthony Nadalin = wrote: >=20 >=20 > Comments > =20 > Intro > =93about the authentication conext=94, not sure what this is since = there is no authentication context in Oauth > =20 > There are several authentication contexts in OAuth: the resource owner = at the authorization endpoint, the client at the token endpoint, etc. = Regardless, this is meant to be the context of the authorization = decision, text now reads: "context in which the token was issued" >=20 >=20 > Use of Oauth2, mixed with use of Oauth, pick one > =20 > All usage changed to =93OAuth 2.0=94 throughout the document, let me = know if I missed any. >=20 >=20 > =93allows holder of a token to query=94 so anything/anyone that has a = token can use this endpoint? > =20 > Now reads authorized holder of the token and has stronger language and = recommendations about requiring authorization on the endpoint to prevent = public token fishing. This was already addressed in the security = considerations section, but that has been propagated throughout the = specification now.=20 >=20 >=20 > =20 > Introspection Endpoint > Use of Oauth2, mixed with use of Oauth, pick one > =20 > =20 > See above. >=20 >=20 >=20 > Introspection Request > The endpoint SHOULD also require some form of authentication=94, what = about some form of authorization ? Why do we have to have another = endpoint that we have to manage and then have a management API draft?] > =20 > This is now clearer that it needs to be an authorized protected = resource. This authorization may be carried through a credential = mechanism as defined in OAuth 2.0, through an access token, or through = some other mechanism.=20 >=20 >=20 > =20 > Token =96 is this any type of token ? how does the endpoint know that = it can deal with this token type? > =20 > Clarified that it=92s either the access_token from the token endpoint = or the refresh_token from the token endpoint. You can use this with = other token types, but that=92s not defined in this spec which concerns = itself with RFC6749/RFC6750.=20 >=20 >=20 > So endpoint has to try to lookup token to determine if it can maybe = find out something about the token? > =20 > That=92s the idea, the protected resource is asking an authoritative = source (the authorization server) about a given token. I had always = thought it was obvious that the authorization server would have to be = able to know something about the token in order to provide an = introspection service, but since that seems to have been unclear to some = I=92ve made it explicit in the security considerations section.=20 >=20 >=20 > Can the one use the authorization code or does one have to get a token = first? > =20 > No, this is for tokens only. I don=92t see the point of introspecting = an authorization code =97 those aren=92t sent to protected resources, = they=92re sent to clients, which would in turn just hand it to the token = endpoint to get a token. There=92s nothing else to find out about it. >=20 >=20 > Can I send a encrypted token and expect a proper response ? > =20 > If the server can decrypt or otherwise understand the token, yes. I=92ve= pointed out this requirement in the security considerations section.=20 >=20 >=20 > What about a Proof of Possession Token? > =20 > Yes, I think this fits great with PoP tokens, but those aren=92t = defined well enough yet to say anything concrete. As the PoP work = progresses, we can have an extension document to determine what needs to = be done there. Note that we=92ll have to do the same thing with the = Revocation RFC. >=20 >=20 > Introspection Response > What is =93active=94 mean ? Is this up to the server to determine ? > =20 > It means the token is live, hasn=92t been revoked, was actually issued = by this server, isn=92t expired, and the protected resource that=92s = asking has the right to know all that information. This is all up to the = server to determine. If the server can=92t determine that information = for its own tokens, it probably shouldn=92t be offering this service. >=20 >=20 > =93scope OPTIONAL=94, is this the scope in the token or is this the = scope that the introspection endpoint sources may have ? It=92s unclear = if all these return values are from the token or from the introspection = endpoint sources ? > =20 > These are the scopes of the token. All return values are, as stated, = metadata about the token itself that is being queried against. >=20 >=20 > What error codes/conditions are there? Just the 400 (bad request)? > =20 > The errors are more clearly spelled out. Most of it involves bad = client authentication (when client credentials are used), bad = authorization (when access tokens are used to access the introspection = endpoint itself), or the like. If the token being introspected isn=92t = good, that=92s still a 200 response =97 the request is fine, but the = token being introspected isn=92t active, which is what=92s returned. = This isn=92t an error, it=92s a valid answer to the question of =93what = is this token?=94 that=92s being asked every time introspection is = called. >=20 >=20 > Can the endpoint return a encrypted response ? > =20 > That=92s outside the scope of this document. It returns JSON like the = rest of OAuth. >=20 >=20 > What about PII such as user_id, aud ? > =20 > This is now covered in the Privacy Considerations section, which = wasn=92t A Thing when this draft was first written. > =20 > =97 Justin >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

1.       Is the = metadata (introspection response) being returned from the authorization = endpoint or from the token or a combination of both = ?


As I said = below, ultimately it=92s about the token and what it represents. If the = token was issued through use of the authorization endpoint, then it=92s = likely that there=92s some context from that authorization endpoint tied = to the token that can be returned.

2.       =93contex= t=94 there may be no context other than the token, are you expecting the = authorization endpoint to always keep a context of how/why the token was = issued ?


If = you=92re asking if stateless tokens can be supported with this, then = yes, that=92s fine. If the token=92s completely on its own (like a = structured token generated as an assertion and used as an OAuth 2.0 = access token) and a server=92s able to unpack that for a client without = access to other pieces of context, then that=92s what it returns. But in = that case, if you=92re issuing stateless tokens, with self-contained = metadata and expirations and no other context to be conveyed beyond = what=92s already inside the token, then you=92d probably just tell your = protected resources how to parse and handle them = directly. 

3.       The = specification should clearly state which type of tokens are supported = and what profiles/bindings are supported, like JWT Bearer, etc.


That=92s opaque = to the protected resource for purposes of this protocol, just like a = token is opaque to a client for purposes of 6749/6750 OAuth. The = introspection protocol supports whatever tokens are supported by the AS, = so we don=92t need to list token types, but maybe we can be clearer = about the opaqueness of the token value in this process. Since these are = OAuth tokens and not assertions, no bindings or profiles are needed = beyond this. It=92s a simple query-response and it=92s up to the server = to know how to fulfill this contract. 

4.       If I = have an SAML Bearer assertion, and the SAML assertion is encrypted and = have no way to know this, it can potentially fail if it can=92t be = decrypted but as far as I can tell I=92m not sending an encrypted token since this is just a SAML assertion, not sure how one really = determines what is = wrong


If the AS = can=92t decrypt the token then it can=92t introspect it. So it doesn=92t = in this case. And if you=92re issuing encrypted OAuth tokens with no = means to decrypt them back at the AS, then you probably wouldn=92t offer = an introspection service to begin with. This is covered in the security = considerations section already.

5.       Should = be spelled out what =93active=94 is supposed to mean so folks get the = same results on different = endpoints


As I = said below, it means to answer =93is this token still good or not?=94 = for a protected resource that can=92t answer that on its own, and I = believe the current definition reflects that. Please submit text if the = existing definition is insufficient or unclear to = you.

 =97 Justin

 

 

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = draft-ietf-oauth-introspection

 

Tony, thanks for the comments. Your timing is great, = as I was just today sitting down to polish the introspection draft into = a proper WG document ready for the last-call tomorrow. I=92ve just = posted the updated draft, and I think that you=92ll find it addresses your concerns. More direct answers inline:

 

 

On Nov 30, 2014, at 1:01 PM, Anthony Nadalin = <tonynad@microsoft.com>= wrote:



Comments

 

Intro

=93about = the authentication conext=94, not sure what this is since there is no = authentication context in Oauth

 

There are several authentication contexts in OAuth: = the resource owner at the authorization endpoint, the client at the = token endpoint, etc. Regardless, this is meant to be the context of the authorization decision, text now reads: "context = in which the token was issued"



Use of Oauth2, mixed with use of Oauth, pick = one

 

All usage changed to =93OAuth 2.0=94 throughout the = document, let me know if I missed any.



=93allows holder of a token to query=94 so = anything/anyone that has a token can use this endpoint?

 

Now reads authorized holder of the token and has = stronger language and recommendations about requiring authorization on = the endpoint to prevent public token fishing. This was already addressed in the security considerations section, but that = has been propagated throughout the specification = now. 



 

Introspection Endpoint

Use of Oauth2, mixed with use of Oauth, pick = one

 

 

See above.




Introspection Request

The endpoint SHOULD also require some form of = authentication=94, what about some form of authorization ? Why do we = have to have another endpoint that we have to manage and then have a = management API draft?]

 

This is now clearer that it needs to be an authorized = protected resource. This authorization may be carried through a = credential mechanism as defined in OAuth 2.0, through an access token, or through some other = mechanism. 



 

Token =96 is this any type of token ? how does the = endpoint know that it can deal with this token type?

 

Clarified that it=92s either the access_token from = the token endpoint or the refresh_token from the token endpoint. You can = use this with other token types, but that=92s not defined in this spec which concerns itself with = RFC6749/RFC6750. 



So endpoint has to try to lookup token =  to determine if it can maybe find out something about the = token?

 

That=92s the idea, the protected resource is asking = an authoritative source (the authorization server) about a given token. = I had always thought it was obvious that the authorization server would have to be able to know something about the token in order = to provide an introspection service, but since that seems to have been = unclear to some I=92ve made it explicit in the security considerations = section. 



Can the one use the authorization code or = does one have to get a token first?

 

No, this is for tokens only. I don=92t see the point = of introspecting an authorization code =97 those aren=92t sent to = protected resources, they=92re sent to clients, which would in turn just hand it to the token endpoint to get a token. There=92s = nothing else to find out about it.



 Can I send a encrypted token and = expect a proper response ?

 

If the server can decrypt or otherwise understand the = token, yes. I=92ve pointed out this requirement in the security = considerations section. 



What about a Proof of Possession Token? =

 

Yes, I think this fits great with PoP tokens, but = those aren=92t defined well enough yet to say anything concrete. As the = PoP work progresses, we can have an extension document to determine what needs to be done there. Note that we=92ll have to do = the same thing with the Revocation RFC.



 Introspection = Response

What is =93active=94 mean = ? Is this up to the server to determine ?

 

It means the token is live, hasn=92t been revoked, = was actually issued by this server, isn=92t expired, and the protected = resource that=92s asking has the right to know all that information. This is all up to the server to determine. If the server = can=92t determine that information for its own tokens, it probably = shouldn=92t be offering this service.



=93scope OPTIONAL=94, is this the scope in = the token or is this the scope that the introspection endpoint sources = may have ? It=92s unclear if all these return values are from the token = or from the introspection endpoint sources ?

 

These are the scopes of the token. All return values = are, as stated, metadata about the token itself that is being queried = against.



What error codes/conditions are there? Just = the 400  (bad request)?

 

The errors are more clearly spelled out. Most of it = involves bad client authentication (when client credentials are used), = bad authorization (when access tokens are used to access the introspection endpoint itself), or the like. If the token = being introspected isn=92t good, that=92s still a 200 response =97 the = request is fine, but the token being introspected isn=92t active, which = is what=92s returned. This isn=92t an error, it=92s a valid answer to the question of =93what is this token?=94 that=92s being = asked every time introspection is called.



Can the endpoint return a encrypted response = ?

 

That=92s outside the scope of this document. It = returns JSON like the rest of OAuth.



What about PII such as user_id, aud = ?

 

This is now covered in the Privacy Considerations = section, which wasn=92t A Thing when this draft was first = written.

 

 =97 Justin



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

 


= --Apple-Mail=_DBB884AC-34D1-4CEA-ADC1-B3CB701B0BF2-- --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUfQrWAAoJEDPAngkbd+w99AQH/3HFF0g6CisDJu+gLE8jFb8c weVun5j9yygptOOVsvFp1ChHsPn8OiEi5scitCz7hSmELXNkrfAGlC2u1Vq3tpRg W9aA0q8J8xcvkowgyXlkvBx+7NP/UCotNTbdxfN4mF7BGvw85NjP9RfvY3/ZAbkG 8fz3Whx22UNhQhKeCa90iiabrDCPUpFBgiLoWRtdrRpBLKaLFQYn4cPIOrsG3++s pcEtVPr2cCmHyLRM23EETkUaD7IwWdEB/7b2gKWnLO3H9UGQRVcV58AZ2QlsSZxh Ll74vH1FF35GOp2LDMh57oWrr8tONwKPBdCZlv6yWRW0LXw2/v9kNAmpweXd5So= =tTqZ -----END PGP SIGNATURE----- --Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526-- From nobody Mon Dec 1 16:51:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95E1ACDF2 for ; Mon, 1 Dec 2014 16:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqPfeGzrTW_y for ; Mon, 1 Dec 2014 16:51:40 -0800 (PST) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DC81ACDDF for ; Mon, 1 Dec 2014 16:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417481499; bh=L6rJeLD+YU4P6HgQc0td03FlZd123p35rtt8Pj/6VhM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=DsqpfSs8tg/YNqf+gHNj3saK6s/UV6H8Uf+H72eDrdywYzYBjfpVrcWvLh8eAcM5eF8oenMnRoS8BgsPaRtdyODNRFweZbsmko/bDV6x1Ql/8Jf2wX5O46iGZbxPMV/6dqjQxTAtX7ZVyNITTnr2UNQdd8fQAFzAK2RjvBw0tfkjAGVcfAcuwSuvkqlfl+LRHGmSJW6mvxwFTtk33XNm0odvKM5tuK3wOEyvCarlNW2Zd1GcpkM+36yHULGrTRWR7X79oEPep2UujmUVg8/nxbty3VF2Stvkz+qx/Eds1SdsVDsiwrCNch99+6yIQ0V0YRkv7yVo7PhJRMv2mu3qzQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=BpLNswfefqtyjMeIAjNWxABteblbvvYBjZ/ssHPyPmuKz5+BCXj9e9iB6UriebY4kMCLyX6WML+7lG7xUa30F/5cxFRbAlCeiZ2jPG+eXnls5WIbEdMu+rYI0LUecyQ4Pn0vnzXdxTS72FyyFz0fBsp5yXzoEpRxNVIqflyrVgxOtBhN6jii+sh8EpVYzt08ANl3+0xw+6mmnXrlbvDH35q9seXOINXYb0DuxF7wCa5sBil8crB5xuEN0ApcDo+C9KBWXKIOyu3p8bdJKuaE31LczPltBhjj1yVK1SexxdsKD0OOhxa4sfpOfnd1a2Ji+wz0GQ0WjFGXoBTClCvuPA==; Received: from [66.196.81.173] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 00:51:39 -0000 Received: from [98.139.212.243] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 00:51:39 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 00:51:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 147161.58683.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: g6SSMQ8VM1mc.AlI4AoMF0V8r9g4kn8za1f6S2yQjOmhqPbDSyB355OsrM8MHUa hMi0pTGTIa.jYmq4U7cvofjkIx75TdCbKvok3HiPk1oWeALSHxkjzCFJUto.kqQAS3ec47u1R1eS skxyPB_LMbIclguGZZFdZs4YK.nuTOpdmUIu7ni4MRZzjqe3luhN2nyobrLwVvZ7.ehRUtp1cbeg bEXyhlekwpo0PLZXG21_QJzbDcIx4qHBQic9I0LF95Uvryi8DXjtiANBh7MdYSNdKwpbdSo15aEb iE2n3OIp7lh_eMuYPho3nOybHNPm4qxzyEXY3MHBJa4DIkWD86SykyKSHaAIvg_gLZUeW2PKd9PJ aXaUKfmQNkWI81Ou8GrYUaP0hK2jkAMmgrbKcCXpGRG.pQ5BjJfOwog6x2XQ5mQ22cFuROilBRQH CJ1P6NS7VbHaTScANhBsZK.J9KUWS8yAh9vPOKCS.z2HsbGZ0ETrR1eiRTk4OFaX14q2xw6BbWpo- Received: by 76.13.26.159; Tue, 02 Dec 2014 00:51:38 +0000 Date: Tue, 2 Dec 2014 00:51:38 +0000 (UTC) From: Bill Mills To: Nat Sakimura , Hannes Tschofenig , John Bradley Message-ID: <20822968.1652156.1417481498275.JavaMail.yahoo@jws10602.mail.bf1.yahoo.com> In-Reply-To: References: <547C9669.3060802@gmx.net> <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> <547CBA40.3080004@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1652155_1579151967.1417481498273" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WZacOZbM1g7c5KCW87lLwtTgQZY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:51:44 -0000 ------=_Part_1652155_1579151967.1417481498273 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mis-stated perhaps, but it's highlighting a core problem we punt on at the = protocol layer. =C2=A0FB as the example here tries to make teh friction of = using a FB login as low as possible, and so the user consent stuff is diale= d down to the very minimum of acceptable. =C2=A0This is the common pattern,= get a user consent and you're covered legally and then the drive is to mak= e that consent as minimally invasive (read effective) as possible. ------=_Part_1652155_1579151967.1417481498273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Mis-stated perhaps, but it's highlighting a core problem we punt on at the protocol layer.  FB as the example here tries to make teh friction of using a FB login as low as possible, and so the user consent stuff is dialed down to the very minimum of acceptable.  This is the common pattern, get a user consent and you're covered legally and then the drive is to make that consent as minimally invasive (read effective) as possible.
------=_Part_1652155_1579151967.1417481498273-- From nobody Mon Dec 1 17:02:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF801AC42D for ; Mon, 1 Dec 2014 17:02:47 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUDJZ2x0T8KE for ; Mon, 1 Dec 2014 17:02:45 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDAF1AC42A for ; Mon, 1 Dec 2014 17:02:45 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so10659179iga.8 for ; Mon, 01 Dec 2014 17:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=re6Dq6FEHrylVtmwqGUkUAB2R33sUj7EaTDEY6F7b0s=; b=Ico0I766H5/nuoEzjNm4yF3FyzVnFqf3LS03F0j4M9ZaA4AahamFVeXqtIIjtemriD BURFNbbDyzZDWthPqyfq3ezAf/Y6sM5tv36zXAIf83/us0L+xjoj1AMh/sjD862A9pzs zw4wAJRo3RLclklVvYOuj2nNfOTBHahN8cEkhKwskb87KH1yJLBZZnYxeQXAepsp3mi1 5IyhkvJMHgDR3RCA1tZYT4d+caUH691O80YRQvkNk+cecngzXpwBqpIVBs9VHtl1unZU c8Bq47meuYB6jz+NYDzwlEse5byQ77ejpLs41mpxEZJVviPYVjRv2QR90xxHSWI0SUqg cMrw== X-Received: by 10.50.30.227 with SMTP id v3mr779502igh.24.1417482164545; Mon, 01 Dec 2014 17:02:44 -0800 (PST) MIME-Version: 1.0 References: <547C9669.3060802@gmx.net> <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> <547CBA40.3080004@gmx.net> <20822968.1652156.1417481498275.JavaMail.yahoo@jws10602.mail.bf1.yahoo.com> From: Nat Sakimura Date: Tue, 02 Dec 2014 01:02:44 +0000 Message-ID: To: Bill Mills , Hannes Tschofenig , John Bradley Content-Type: multipart/alternative; boundary=047d7ba96ef6e4b1e10509314801 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CwIqbywPHTRZdJorqYLxUqGYKO0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 01:02:47 -0000 --047d7ba96ef6e4b1e10509314801 Content-Type: text/plain; charset=UTF-8 Indeed, and there are commercial incentives for it. I have doubts about the legal effectiveness of such consent but that is the de-facto situation right now. On the longer run, there are initiatives like information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 study group on notice and consent which hopefully would emerge with a better model but that only helps the future and not now. Do you have some suggestions to help the situation in the mean time? On Tue Dec 02 2014 at 9:51:39 Bill Mills wrote: > Mis-stated perhaps, but it's highlighting a core problem we punt on at the > protocol layer. FB as the example here tries to make teh friction of using > a FB login as low as possible, and so the user consent stuff is dialed down > to the very minimum of acceptable. This is the common pattern, get a user > consent and you're covered legally and then the drive is to make that > consent as minimally invasive (read effective) as possible. > --047d7ba96ef6e4b1e10509314801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, and there are commercial incentives for it.=C2=A0
I have doubts = about the legal effectiveness of such consent but that is the de-facto situ= ation right now.=C2=A0
On the longer run, there are initiatives like in= formation sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 study gr= oup on notice and consent which hopefully would emerge with a better model = but that only helps the future and not now.=C2=A0

= Do you have some suggestions to help the situation in the mean time?=C2=A0<= /div>
On Tue Dec 02 2014 at 9:51:39 Bill Mill= s <wmills_92105@yahoo.com&= gt; wrote:
Mis-stated perhaps= , but it's highlighting a core problem we punt on at the protocol layer= .=C2=A0 FB as the example here tries to make teh friction of using a FB log= in as low as possible, and so the user consent stuff is dialed down to the = very minimum of acceptable.=C2=A0 This is the common pattern, get a user co= nsent and you're covered legally and then the drive is to make that con= sent as minimally invasive (read effective) as possible.
--047d7ba96ef6e4b1e10509314801-- From nobody Mon Dec 1 17:05:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702311ACDF9 for ; Mon, 1 Dec 2014 17:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWNFi_2BZu-S for ; Mon, 1 Dec 2014 17:05:13 -0800 (PST) Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (nm32-vm6.bullet.mail.bf1.yahoo.com [72.30.239.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279C21ACDF7 for ; Mon, 1 Dec 2014 17:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417482312; bh=WdbF1ykkikwBE9Hynw6TH0pDzg7ITrqa7NgpIU5kBeE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=HhoOPErWeoYND6ELScmV8fHeDKBetVlXdR9pJnOlv/CtFqCEKDPVFBeOPqsGynDzV9178SVO/5ZTaxFdUS4wqztSkMgs1HS5vyidXjqWCDvNiIDnOIRxASKm0O17EtrBrVKbsUDcN6LppuKu/b9apGr2YswIYaxdL9dD4vU3lACSz/pAbfoyAvKXFv1TsG6ihD6enplcXnTvO/b6d7n6AE7BMdDqtW9NYVq8U4UuTlvTliv0FHKpX4gS80dNLPctE6SZtTh7oL9kt4IZl4tgcWLiflaILPyiAKvh05x9+80e/R6F69LOvP2S/UPFv5YIiDHf711qUfK3zXkhTkh0Zw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=Qm7bFHc3N6Ap9gLFeT3IJO9bRH7JyvlcQc3oDcRY9Hf2f0VPRbcYt3TgDPr1misAB7ceR17w20WilwGxOy1v2xOxOpVl15NTY/KSd/0muCSmkJFNAxqiJhBXeJrheknE2Rj2m6E02Zibybvfn+M8QUHcHeW28fELXzTpXt6XbDt6SZoJiu6EQLcg+QYVF5IFbGo4T0p8VAxUo3dWCA0xESF145vBTa1hryWmIxGuqWinYqd14pIAirh8oydI+YuvarJ/yOjxABddIJtuni5NE25y/84icbL56niQS2rVOrX1WvghaxLVmKPpDC4cnuXfdJxhnfT+F0W0ulTheyAMYg==; Received: from [98.139.215.140] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 01:05:12 -0000 Received: from [98.139.212.192] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 01:05:11 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 01:05:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 855207.24990.bm@omp1001.mail.bf1.yahoo.com X-YMail-OSG: unkC5rgVM1kNsH42dOceWFzsUqkVJ9jgidfbYrnTecKWyQA1TuhP9S6_1Zwg0Cz vsnrnJD8NR9p9VozGam7F0HylqNFMddq_JnZdKvGn9Bx5m6j4Lz6ZZEHh0iaVYOgAKxYZGBc7cli 6FHQ9QCi2lxsi6enx2lNg4uONguTyv4fkrkK8vvnlzMlgQkX2FtQ2c28Cna15lb23Nhs3rvSV_Sy n31zvvkxhd6jhuSRtaREBbPEtAFulGWCXtZ2uX1EIV41uW06tRK1xuiAsV1vuYjguyHqLoL4D5ZW 9OQS1aDUBcI6J2JibH.dtLv4flrkTG0ETaM8bIAhYyqq_iMHO8mGnBt7tffkS84sktyeJL2x43K0 nnLpV3lci_aeQ58t_ini1_dt7NhWUWiqE.RrrqmOyCeonqr0.8yB.Jucw1gyaxrZLZjkLhvHyG9Z AV_n4Zbr24XvPiIbsMuKFP3HGWxceZemNhGuPEwcZJ8OWan__XevbfvMOCvrFKL9Jr2s8F2nD8nQ- Received: by 66.196.80.122; Tue, 02 Dec 2014 01:05:11 +0000 Date: Tue, 2 Dec 2014 01:05:11 +0000 (UTC) From: Bill Mills To: Nat Sakimura , Hannes Tschofenig , John Bradley Message-ID: <891996597.3522529.1417482311114.JavaMail.yahoo@jws10677.mail.bf1.yahoo.com> In-Reply-To: References: <547C9669.3060802@gmx.net> <7B8DD27E-A180-4A13-869E-884F01E2DE36@ve7jtb.com> <547CBA40.3080004@gmx.net> <20822968.1652156.1417481498275.JavaMail.yahoo@jws10602.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3522528_865262420.1417482311109" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/enjTXYzHb9RlT-iBpY5WcuwZI-0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 01:05:16 -0000 ------=_Part_3522528_865262420.1417482311109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the motion here is going to be social/legal and not standards based= . =C2=A0We can preach on this all we want, but in the end folks like the EF= F and major privacy watchdogs will carry the water here.=20 On Monday, December 1, 2014 5:02 PM, Nat Sakimura = wrote: =20 Indeed, and there are commercial incentives for it.=C2=A0 I have doubts about the legal effectiveness of such consent but that is the= de-facto situation right now.=C2=A0On the longer run, there are initiative= s like information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5= study group on notice and consent which hopefully would emerge with a bett= er model but that only helps the future and not now.=C2=A0 Do you have some suggestions to help the situation in the mean time?=C2=A0 On Tue Dec 02 2014 at 9:51:39 Bill Mills wrote: Mis-stated perhaps, but it's highlighting a core problem we punt on at the = protocol layer.=C2=A0 FB as the example here tries to make teh friction of = using a FB login as low as possible, and so the user consent stuff is diale= d down to the very minimum of acceptable.=C2=A0 This is the common pattern,= get a user consent and you're covered legally and then the drive is to mak= e that consent as minimally invasive (read effective) as possible. ------=_Part_3522528_865262420.1417482311109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the motion here is going to be social= /legal and not standards based.  We can preach on this all we want, bu= t in the end folks like the EFF and major privacy watchdogs will carry the = water here.


On Monday, December 1, 2014 5:02= PM, Nat Sakimura <sakimura@gmail.com> wrote:

Indeed,= and there are commercial incentives for it. 
I have= doubts about the legal effectiveness of such consent but that is the de-fa= cto situation right now. 
On the longer run, there are initiatives= like information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 = study group on notice and consent which hopefully would emerge with a bette= r model but that only helps the future and not now. 

Do you have some suggestions to help the situation i= n the mean time? 

On Tue Dec 02 2014 at 9:51:39 Bill Mills <wmills_92105@yahoo.com> wrote:<= br clear=3D"none">
Mis-stated perhaps, but it's highlighting a core problem we punt o= n at the protocol layer.  FB as the example here tries to make teh fri= ction of using a FB login as low as possible, and so the user consent stuff= is dialed down to the very minimum of acceptable.  This is the common= pattern, get a user consent and you're covered legally and then the drive = is to make that consent as minimally invasive (read effective) as possible.=


------=_Part_3522528_865262420.1417482311109-- From nobody Tue Dec 2 03:23:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72C81A1A88 for ; Tue, 2 Dec 2014 03:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPStFw_i5I9W for ; Tue, 2 Dec 2014 03:23:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198821A1A87 for ; Tue, 2 Dec 2014 03:23:23 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LskKv-1Y1zmq0HqD-012K1n for ; Tue, 02 Dec 2014 12:23:21 +0100 Message-ID: <547DA128.9090606@gmx.net> Date: Tue, 02 Dec 2014 12:23:20 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GTSDuKUP4lOfvwrT0Nm1n26oDrffHFMmu" X-Provags-ID: V03:K0:xDvZa1mRNSae7TYBghp+Neb5OiTiiRmWyhnkwdHuFD6LKLvCnaZ lFTloPNIFayT3QMgGBvrQQOR/36EShtwMGcx2e6HZzE7R6stf9OUF97SmYkBFZwAsKGotfb 0wjQdyaEYQmWnmh1CHgow4+tcl51cKEH6Lnwe4aQYam16h6T1BdjFd4J0Mo22N/2Mc7Og0+ h6HQdTC3pgxVBwqLxo1Ow== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3Iz8RVkIKxpo7nZuO7PLH6IT75U Subject: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:23:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GTSDuKUP4lOfvwrT0Nm1n26oDrffHFMmu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itsel= f. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. Ciao Hannes --GTSDuKUP4lOfvwrT0Nm1n26oDrffHFMmu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfaEoAAoJEGhJURNOOiAt+tMH/0kwzXCFlw6ubLcLtHjJ7ns5 am/OpdXS89oOsywhYV+6ySI0J8LT1WjFkBLAIRWmtttfEQ/cVyPE3r3Zc0wX2Ltb AF+qdwHu1Bubm3eihxUt0T59BIfcglXxlEv6xZnC22eomr/xQGWNfbymagPgieJH 0r9arcncbYUubvQXUCYMLeWtb9dF5DsmXcmKEZdYQEvzMjnzSFva+HH/tO1mUYFd 4DIl7DpfbeUeruHNFhIXHcX8Ci3RdaymSyOnQnWlRzWIAijK27SFwYlx9zk3i4b6 VXaHqUCv4KPRlr0YmllVZvckMVw7emcn5IZBcMNyE/uCtQpDVBoMo1UlOmB6X/w= =nory -----END PGP SIGNATURE----- --GTSDuKUP4lOfvwrT0Nm1n26oDrffHFMmu-- From nobody Tue Dec 2 03:30:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100051A1AA5 for ; Tue, 2 Dec 2014 03:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW6BzqSbOr-f for ; Tue, 2 Dec 2014 03:30:42 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B2C1A1AA0 for ; Tue, 2 Dec 2014 03:30:42 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id b13so16757990wgh.32 for ; Tue, 02 Dec 2014 03:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7K1DtPssSb8aW8//LEoRgLZmIjegaLRyAL6kXL9ZjGc=; b=TSWGiyOujBuEYboAAARLWsk26vt0MkigTUmMtRirNgmgPEhSJWm1OKw9blJaqY0Ofo oj3z0AUWQ1sk/0atjKTonCwfXUzpVmU764kHaMwHVgBase0C1JThHXhRVq7dUHm8ZzgI vWCaesWoxaSNUA9K5vTAtyzAwi2irG6InsJLxWKIzIE/vfR2GvHc/c3PtHpAEaDqMYtx 77Gt2gCFEEM/qCJAmOnry21MA7VKGWS4qMGVr+s+a9S/4B8l+AMwgdQ69W6QAh3ucLwy z54eu9CjX7ILATAqiop3xNcX819blDXU+MOPHzgVeJTIiE93yky/Eof1VFw+9CphpMXa bTXA== X-Received: by 10.194.238.3 with SMTP id vg3mr63841589wjc.69.1417519839857; Tue, 02 Dec 2014 03:30:39 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id td9sm32375192wic.15.2014.12.02.03.30.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 03:30:39 -0800 (PST) Message-ID: <547DA2DE.4050400@gmail.com> Date: Tue, 02 Dec 2014 11:30:38 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <547DA128.9090606@gmx.net> In-Reply-To: <547DA128.9090606@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JQMRT9umXmR8tDNC7GLVrW51poc Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:30:45 -0000 Hi Hannes On 02/12/14 11:23, Hannes Tschofenig wrote: > Hi Justin, > > I have a few remarks regarding version -01 of the token introspection > document. > > * Terminology > > The token introspection protocol is a client-server protocol but the > term "client" already has a meaning in OAuth. Here the client of the > token introspection protocol is actually the resource server. I believe > it would make sense to clarify this issue in the terminology section or > in the introduction. Maybe add a figure (which you could copy from > Figure 4 of > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > Maybe you want to call these two parties, the introspection client and > the introspection server. > > * Scope > > I think the document needs to be very clear that is only applicable to > bearer tokens (and not to PoP tokens). This issue was raised at the last > IETF meeting as well. > Interesting, I was reading the doc yesterday and thought it was good it was not talking about specific access token types :-) I wonder why a pop token can not be introspected in the interoperable way as per the text for the resource server to tale the authorization decision ? Thanks, Sergey > * Meta-Information > > You have replicated a lot of the claims defined in > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > and I am wondering why you have decided to not just re-use the entire > registry from JWT? > > If you want to create a separate registry (which I wouldn't recommend) > then you have to put text into the IANA consideration section. > > When you write: > > " > The endpoint MAY allow other parameters to provide further context to > the query. > " > > You could instead write that the token introspection MUST ignore any > parameters from the request message it does not understand. > > Of course, there is the question whether any of those would be security > critical and hence ignoring them would cause problems?! > > * Security > > The requirement for authenticating the party issuing the introspection > request to the token introspection endpoint is justified in the security > and the privacy consideration section. The security threat is that an > attacker could use the endpoint to testing for tokens. The privacy > threat is that a resource server learns about the content of the token, > which may contain personal data. I see the former as more dangerous than > the latter since a legitimate resource server is supposed to learn about > the authorization information in the token. An attacker who had gotten > hold of tokens will not only learn about the content of the token but he > will also be able to use it to get access to the protected resource itself. > > In any case, to me this sounds like mutual authentication should be > mandatory to implement. This is currently not the case. On top of that > there is single technique mandatory-to-implement outlined either (in > case someone wants to use it). That's in general not very helpful from > an interoperability point of view. Yet another thing to agree on between > the AS and the RS. > > * SHOULDs > > This is my usual comment that any SHOULD statement should give the > reader enough information about the trade-off decision he has to make. > When should he implement something and when should he skip it? > > * Minor items > > You write: > > " > These include using > structured token formats such as JWT [JWT] or SAML [[ Editor's Note: > Which SAML document should we reference here? ]] and proprietary > inter-service communication mechanisms (such as shared databases and > protected enterprise service buses) that convey token information. > " > > Just reference the JWT since that's what we standardize. > > * 'Active' claim > > you write: > " > active REQUIRED. Boolean indicator of whether or not the presented > token is currently active. The authorization server determines > whether and when a given token is in an active state. > " > > Wouldn't it make more sense to return an error rather than saying that > this token is not active. > > * Capitalization > > Reading through the text I see bearer token/Bearer Token, Client/client, > etc. issue. > > * AS <-> RS relationship > > You write: > " > Since > OAuth 2.0 [RFC6749] defines no direct relationship between the > authorization server and the protected resource, only that they must > have an agreement on the tokens themselves, there have been many > different approaches to bridging this gap. > " > > I am not sure what you mean by "defines no relationship" between the AS > and the RS. Of course, there is a relationship. The AS issues tokens for > access for a specific RS. The RS needs to understand the tokens or if it > does not understand them it needs to know which AS to interact with to > learn about the content. > > In a nutshell, I am not sure what you want to say with this paragraph > particularly since you state that they have to have an agreement about > the tokens. > > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Dec 2 03:53:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A591A1AE2 for ; Tue, 2 Dec 2014 03:53:35 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJQCQyQcPXW6 for ; Tue, 2 Dec 2014 03:53:32 -0800 (PST) Received: from BLU004-OMC1S35.hotmail.com (blu004-omc1s35.hotmail.com [65.55.116.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913F91A1ACC for ; Tue, 2 Dec 2014 03:53:31 -0800 (PST) Received: from BLU406-EAS121 ([65.55.116.8]) by BLU004-OMC1S35.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 03:53:30 -0800 X-TMN: [cV2VlOExzkHR2l5LaL3GJj8OtHoHplcV] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Client-ID: 460 X-Mailer: BlackBerry Email (10.2.1.3442) Date: Tue, 2 Dec 2014 18:53:27 +0700 From: Panca Agus Ananda To: oauth@ietf.org X-OriginalArrivalTime: 02 Dec 2014 11:53:30.0735 (UTC) FILETIME=[9784BFF0:01D00E26] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/d6NlE2X2_9guBMn1TFQH0Phx9mQ Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:53:35 -0000 =E2=80=8E Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. =C2=A0 Pesan Asli =C2=A0 Dari: oauth-request@ietf.org Terkirim: Selasa, 2 Desember 2014 18.30 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest, Vol 74, Issue 10 Send OAuth mailing list submissions to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/lis= tinfo/oauth or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oauth-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: =C2=A0=C2=A0 1. Re: OAuth in the news again.... (Bill Mills) =C2=A0=C2=A0 2. Re: OAuth in the news again.... (Nat Sakimura) =C2=A0=C2=A0 3. Re: OAuth in the news again.... (Bill Mills) =C2=A0=C2=A0 4. Review of draft-ietf-oauth-introspection-01 (Hannes Tschofe= nig) =C2=A0=C2=A0 5. Re: Review of draft-ietf-oauth-introspection-01 (Sergey Ber= yozkin) ---------------------------------------------------------------------- Message: 1 Date: Tue, 2 Dec 2014 00:51:38 +0000 (UTC) From: Bill Mills To: Nat Sakimura ,=C2=A0 Hannes Tschofenig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2= =A0 John Bradley Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... Message-ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <20822968.1652156.1417481498275.= JavaMail.yahoo@jws10602.mail.bf1.yahoo.com> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 Content-Type: text/plain; charset=3D"utf-8" Mis-stated perhaps, but it's highlighting a core problem we punt on at the = protocol layer. ?FB as the example here tries to make teh friction of using= a FB login as low as possible, and so the user consent stuff is dialed dow= n to the very minimum of acceptable. ?This is the common pattern, get a use= r consent and you're covered legally and then the drive is to make that con= sent as minimally invasive (read effective) as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 02 Dec 2014 01:02:44 +0000 From: Nat Sakimura To: Bill Mills , Hannes Tschofenig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2= =A0 John Bradley Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... Message-ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: text/plain; charset=3D"utf-8" Indeed, and there are commercial incentives for it. I have doubts about the legal effectiveness of such consent but that is the de-facto situation right now. On the longer run, there are initiatives like information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 study group on notice and consent which hopefully would emerge with a better model but that only helps the future and not now. Do you have some suggestions to help the situation in the mean time? On Tue Dec 02 2014 at 9:51:39 Bill Mills wrote: > Mis-stated perhaps, but it's highlighting a core problem we punt on at the > protocol layer.=C2=A0 FB as the example here tries to make teh friction o= f using > a FB login as low as possible, and so the user consent stuff is dialed do= wn > to the very minimum of acceptable.=C2=A0 This is the common pattern, get = a user > consent and you're covered legally and then the drive is to make that > consent as minimally invasive (read effective) as possible. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 2 Dec 2014 01:05:11 +0000 (UTC) From: Bill Mills To: Nat Sakimura ,=C2=A0 Hannes Tschofenig =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2= =A0 John Bradley Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth in the news again.... Message-ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <891996597.3522529.1417482311114= .JavaMail.yahoo@jws10677.mail.bf1.yahoo.com> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 Content-Type: text/plain; charset=3D"utf-8" I think the motion here is going to be social/legal and not standards based= . ?We can preach on this all we want, but in the end folks like the EFF and= major privacy watchdogs will carry the water here.=20 =C2=A0=C2=A0=C2=A0=C2=A0 On Monday, December 1, 2014 5:02 PM, Nat Sakimura = wrote: =C2=A0=C2=A0=20 =C2=A0Indeed, and there are commercial incentives for it.? I have doubts about the legal effectiveness of such consent but that is the= de-facto situation right now.?On the longer run, there are initiatives lik= e information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 stud= y group on notice and consent which hopefully would emerge with a better mo= del but that only helps the future and not now.? Do you have some suggestions to help the situation in the mean time?? On Tue Dec 02 2014 at 9:51:39 Bill Mills wrote: Mis-stated perhaps, but it's highlighting a core problem we punt on at the = protocol layer.? FB as the example here tries to make teh friction of using= a FB login as low as possible, and so the user consent stuff is dialed dow= n to the very minimum of acceptable.? This is the common pattern, get a use= r consent and you're covered legally and then the drive is to make that con= sent as minimally invasive (read effective) as possible. =C2=A0=C2=A0=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 02 Dec 2014 12:23:20 +0100 From: Hannes Tschofenig To: "oauth@ietf.org" Subject: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: <547DA128.9090606@gmx.net> Content-Type: text/plain; charset=3D"utf-8" Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? * Minor items You write: " These include using =C2=A0=C2=A0 structured token formats such as JWT [JWT] or SAML [[ Editor's= Note: =C2=A0=C2=A0 Which SAML document should we reference here? ]] and proprieta= ry =C2=A0=C2=A0 inter-service communication mechanisms (such as shared databas= es and =C2=A0=C2=A0 protected enterprise service buses) that convey token informat= ion. " Just reference the JWT since that's what we standardize. * 'Active' claim you write: " =C2=A0=C2=A0 active=C2=A0 REQUIRED.=C2=A0 Boolean indicator of whether or n= ot the presented =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 token is currently active.=C2=A0 The authori= zation server determines =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether and when a given token is in an acti= ve state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. * AS <-> RS relationship You write: " =C2=A0=C2=A0 Since =C2=A0=C2=A0 OAuth 2.0 [RFC6749] defines no direct relationship between the =C2=A0=C2=A0 authorization server and the protected resource, only that the= y must =C2=A0=C2=A0 have an agreement on the tokens themselves, there have been ma= ny =C2=A0=C2=A0 different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. Ciao Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 5 Date: Tue, 02 Dec 2014 11:30:38 +0000 From: Sergey Beryozkin To: oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: <547DA2DE.4050400@gmail.com> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed Hi Hannes On 02/12/14 11:23, Hannes Tschofenig wrote: > Hi Justin, > > I have a few remarks regarding version -01 of the token introspection > document. > > * Terminology > > The token introspection protocol is a client-server protocol but the > term "client" already has a meaning in OAuth. Here the client of the > token introspection protocol is actually the resource server. I believe > it would make sense to clarify this issue in the terminology section or > in the introduction. Maybe add a figure (which you could copy from > Figure 4 of > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > Maybe you want to call these two parties, the introspection client and > the introspection server. > > * Scope > > I think the document needs to be very clear that is only applicable to > bearer tokens (and not to PoP tokens). This issue was raised at the last > IETF meeting as well. > Interesting, I was reading the doc yesterday and thought it was good it=20 was not talking about specific access token types :-) I wonder why a pop token can not be introspected in the interoperable=20 way as per the text for the resource server to tale the authorization=20 decision ? Thanks, Sergey > * Meta-Information > > You have replicated a lot of the claims defined in > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > and I am wondering why you have decided to not just re-use the entire > registry from JWT? > > If you want to create a separate registry (which I wouldn't recommend) > then you have to put text into the IANA consideration section. > > When you write: > > " > The endpoint MAY allow other parameters to provide further context to > the query. > " > > You could instead write that the token introspection MUST ignore any > parameters from the request message it does not understand. > > Of course, there is the question whether any of those would be security > critical and hence ignoring them would cause problems?! > > * Security > > The requirement for authenticating the party issuing the introspection > request to the token introspection endpoint is justified in the security > and the privacy consideration section. The security threat is that an > attacker could use the endpoint to testing for tokens. The privacy > threat is that a resource server learns about the content of the token, > which may contain personal data. I see the former as more dangerous than > the latter since a legitimate resource server is supposed to learn about > the authorization information in the token. An attacker who had gotten > hold of tokens will not only learn about the content of the token but he > will also be able to use it to get access to the protected resource itsel= f. > > In any case, to me this sounds like mutual authentication should be > mandatory to implement. This is currently not the case. On top of that > there is single technique mandatory-to-implement outlined either (in > case someone wants to use it). That's in general not very helpful from > an interoperability point of view. Yet another thing to agree on between > the AS and the RS. > > * SHOULDs > > This is my usual comment that any SHOULD statement should give the > reader enough information about the trade-off decision he has to make. > When should he implement something and when should he skip it? > > * Minor items > > You write: > > " > These include using >=C2=A0=C2=A0=C2=A0=C2=A0 structured token formats such as JWT [JWT] or SAM= L [[ Editor's Note: >=C2=A0=C2=A0=C2=A0=C2=A0 Which SAML document should we reference here? ]] = and proprietary >=C2=A0=C2=A0=C2=A0=C2=A0 inter-service communication mechanisms (such as s= hared databases and >=C2=A0=C2=A0=C2=A0=C2=A0 protected enterprise service buses) that convey t= oken information. > " > > Just reference the JWT since that's what we standardize. > > * 'Active' claim > > you write: > " >=C2=A0=C2=A0=C2=A0=C2=A0 active=C2=A0 REQUIRED.=C2=A0 Boolean indicator of= whether or not the presented >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 token is currently active.=C2= =A0 The authorization server determines >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether and when a given token = is in an active state. > " > > Wouldn't it make more sense to return an error rather than saying that > this token is not active. > > * Capitalization > > Reading through the text I see bearer token/Bearer Token, Client/client, > etc. issue. > > * AS <-> RS relationship > > You write: > " >=C2=A0=C2=A0=C2=A0=C2=A0 Since >=C2=A0=C2=A0=C2=A0=C2=A0 OAuth 2.0 [RFC6749] defines no direct relationshi= p between the >=C2=A0=C2=A0=C2=A0=C2=A0 authorization server and the protected resource, = only that they must >=C2=A0=C2=A0=C2=A0=C2=A0 have an agreement on the tokens themselves, there= have been many >=C2=A0=C2=A0=C2=A0=C2=A0 different approaches to bridging this gap. > " > > I am not sure what you mean by "defines no relationship" between the AS > and the RS. Of course, there is a relationship. The AS issues tokens for > access for a specific RS. The RS needs to understand the tokens or if it > does not understand them it needs to know which AS to interact with to > learn about the content. > > In a nutshell, I am not sure what you want to say with this paragraph > particularly since you state that they have to have an agreement about > the tokens. > > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 74, Issue 10 ************************************* From nobody Tue Dec 2 04:02:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245B1A1AE6 for ; Tue, 2 Dec 2014 04:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAPU0jjj5ihT for ; Tue, 2 Dec 2014 04:02:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED9F1A1ACC for ; Tue, 2 Dec 2014 04:02:54 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlV4F-1YU0zL0Zrb-00bNcD; Tue, 02 Dec 2014 13:02:52 +0100 Message-ID: <547DAA6B.2020602@gmx.net> Date: Tue, 02 Dec 2014 13:02:51 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sergey Beryozkin , oauth@ietf.org References: <547DA128.9090606@gmx.net> <547DA2DE.4050400@gmail.com> In-Reply-To: <547DA2DE.4050400@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dhgTmrWuPG1xfiBwi0Aspj4Gc340U3afj" X-Provags-ID: V03:K0:VDb2iV6qJ6LIpzhVsEc1VlxD7EPxVphHsByg+WSOzis/rvV9Gzu cfZKxbuQTIC8NdqY5I/yG9sTKCtHKHLlsEhK9IRqz2DAnc1pSvKrisGX+/wJGOE7ykIrlZ4 pzzG+z3rvPYvkgWemBPB9EviGWSSP+YvuZZ7xWTRvIFxrdsXy8vzg2/KIXRCGVbi2b2MOZK Pvzt8aHDm1u8r9JL2qPcQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wfambEiMdPuw8W4PQQfJ_77PbsI Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:02:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dhgTmrWuPG1xfiBwi0Aspj4Gc340U3afj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sergey, On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: >> >> * Scope >> >> I think the document needs to be very clear that is only applicable to= >> bearer tokens (and not to PoP tokens). This issue was raised at the la= st >> IETF meeting as well. >> > Interesting, I was reading the doc yesterday and thought it was good it= > was not talking about specific access token types :-) >=20 > I wonder why a pop token can not be introspected in the interoperable > way as per the text for the resource server to tale the authorization > decision ? >=20 The problem is that the AS needs to have the same context as the RS. In the bearer token case, the RS really only needs to pass the the access token along but in the PoP case one could imagine a couple of different solutions. A possible solution is that the AS sends the RS the necessary key so that the RS is able to verify the MAC or digital signature covering the request. The story would again be different if the PoP solution involves TLS. Yet another solution would be to also forward the entire request to the AS (which I wouldn't do). This is not specified in the current version of token introspection and, from the responses Justin gave at the last IETF meeting, he does not want to wait till the PoP work is finished to actually work out the details. Finally, from a security point of view it would be extremely important that the AS only provides a key to the RS if the RS is (a) authenticated and (b) the audience field from the token matches the RS since otherwise the PoP security degrades to a bearer token. Ciao Hannes > Thanks, Sergey --dhgTmrWuPG1xfiBwi0Aspj4Gc340U3afj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfaprAAoJEGhJURNOOiAtnKIH/itBfOQDqDkURKXdyb30yj4e AmaI5z1JfCOl4Vgldc/WSiHqdkEfJURLDwgYpqB6q2kVY+oZcrjlB7py4quRBaDL o8YC36gVsNMUwXeZTYuvUqe0sZgMOIYPH/oU3Po15qmQJyqjbSD7JmVeqOiIkmZc KOA1lERqUzlg+G9QAswM6lMMURDwK4OEUqq+3ovwliRCe2ZO04OAEQf1zKDBzET+ GtuR4w56slHKwz+bQYa++Lc95kwZRTCpUWiG6bKuRaNT9rBLqgLRQHhp7mva0J78 XA23gS92l9cEdhRYc4d2aohMVnZciadAO4+mT12psoAkIUdKi/FkmIHxHG7TISw= =x8Gr -----END PGP SIGNATURE----- --dhgTmrWuPG1xfiBwi0Aspj4Gc340U3afj-- From nobody Tue Dec 2 04:39:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC781A1B12 for ; Tue, 2 Dec 2014 04:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhMEWiiT1O8u for ; Tue, 2 Dec 2014 04:39:20 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED0B1A1A65 for ; Tue, 2 Dec 2014 04:39:19 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so20800052wiw.4 for ; Tue, 02 Dec 2014 04:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZyMzeaSqvEH3nVCVExCyQodRXFoNu1G33kz0YsTuwLk=; b=x3uTini7+s1Z+1CfLcCW5XTIYJZjmHmD/Q90hFLpBgO1afcP4lE8Xu2LSFqY3eNzKg JNEZEWconNW7avLDgakT6UxlYkttDku8QU+o643ECA26XTwQB1ItfXeV07TLqcyOSDgf ykgE8iUV6NDt0Wj6wBPAENR76SnNY93s0Cx3ugRhyI8G4kF6+I8GOZ6f3HZKBKV4j4oe Taxs4OsqR3xmlcNFrP7VDQkStTt7+rCz+6HyIawQ0nYqYlh6f36SHRtzW6EHFHm/1qk/ Sff0Pr5tVjIXPdx3UwRtwIZZR0VFfwPfY9u9Yb4kJCO8Mq1lUfyFEH1nlvsh0jr1Use/ GIUA== X-Received: by 10.180.95.8 with SMTP id dg8mr19259312wib.33.1417523958517; Tue, 02 Dec 2014 04:39:18 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id s9sm32607353wiz.12.2014.12.02.04.39.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 04:39:17 -0800 (PST) Message-ID: <547DB2F4.2040407@gmail.com> Date: Tue, 02 Dec 2014 12:39:16 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hannes Tschofenig , oauth@ietf.org References: <547DA128.9090606@gmx.net> <547DA2DE.4050400@gmail.com> <547DAA6B.2020602@gmx.net> In-Reply-To: <547DAA6B.2020602@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UxNVLHPwnF-WBKyA5dNnAVzB66c Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:39:22 -0000 Hi Hannes Thanks for the clarifications, comments below... On 02/12/14 12:02, Hannes Tschofenig wrote: > Hi Sergey, > > On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: >>> >>> * Scope >>> >>> I think the document needs to be very clear that is only applicable to >>> bearer tokens (and not to PoP tokens). This issue was raised at the last >>> IETF meeting as well. >>> >> Interesting, I was reading the doc yesterday and thought it was good it >> was not talking about specific access token types :-) >> >> I wonder why a pop token can not be introspected in the interoperable >> way as per the text for the resource server to tale the authorization >> decision ? >> > > The problem is that the AS needs to have the same context as the RS. In > the bearer token case, the RS really only needs to pass the the access > token along but in the PoP case one could imagine a couple of different > solutions. > > A possible solution is that the AS sends the RS the necessary key so > that the RS is able to verify the MAC or digital signature covering the > request. > > The story would again be different if the PoP solution involves TLS. > > Yet another solution would be to also forward the entire request to the > AS (which I wouldn't do). > > This is not specified in the current version of token introspection and, > from the responses Justin gave at the last IETF meeting, he does not > want to wait till the PoP work is finished to actually work out the > details. > > Finally, from a security point of view it would be extremely important > that the AS only provides a key to the RS if the RS is (a) authenticated > and (b) the audience field from the token matches the RS since otherwise > the PoP security degrades to a bearer token. I see the draft specifying an optional resource_id hint (which I read being an actual request URI) which is the primary signing material in the pop case, the extra parameters like the nonce/timestamp can be forwarded along. I agree it does not make sense to forward the actual body but that is probably going to be a very rare case where a body hash is also provided. Explicitly disallowing the support for the pop tokens in the introspection text might the interoperability reach of either pop tokens or token introspections in cases where a given RS integrates with a 3rd party AS. May be it is a Security Considerations draft issue which would make it more open for pop tokens Thanks, Sergey > > Ciao > Hannes > >> Thanks, Sergey > From nobody Tue Dec 2 05:31:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA88B1A1B49 for ; Tue, 2 Dec 2014 05:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39T6sa5FTnZC for ; Tue, 2 Dec 2014 05:31:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C981A8967 for ; Tue, 2 Dec 2014 05:31:35 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LbMF8-1YKMes0Gh0-00kstr; Tue, 02 Dec 2014 14:31:32 +0100 Message-ID: <547DBF33.90005@gmx.net> Date: Tue, 02 Dec 2014 14:31:31 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sergey Beryozkin , oauth@ietf.org References: <547DA128.9090606@gmx.net> <547DA2DE.4050400@gmail.com> <547DAA6B.2020602@gmx.net> <547DB2F4.2040407@gmail.com> In-Reply-To: <547DB2F4.2040407@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5JrVLKAratT30V1ovB988Hp131cocqU5h" X-Provags-ID: V03:K0:7SWzMvHhp/C2hWLNJNHgqoF81zBfkyGcRMNroYYZCLPjkBLm04P HJuCNUzWUOZwyrsxBfTROoCqqL/8FH5oW+vqtxuXPbqu0syEtJdBwcCKqvBAvp3F4zRGlkP uQ3sx4dWbHaNTv82m76hY9q0vcYf45GoeRJW9vmWm9RjAeQwDgaLGkjGt+YoFEwZxFkXoIl uOFvGmqONb3NGW4JTYx9Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Mejv5LDyGljhOU5ufNLvJ3mZ03w Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 13:31:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5JrVLKAratT30V1ovB988Hp131cocqU5h Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sergey, comments below. On 12/02/2014 01:39 PM, Sergey Beryozkin wrote: > Hi Hannes >=20 > Thanks for the clarifications, comments below... > On 02/12/14 12:02, Hannes Tschofenig wrote: >> Hi Sergey, >> >> On 12/02/2014 12:30 PM, Sergey Beryozkin wrote: >>>> >>>> * Scope >>>> >>>> I think the document needs to be very clear that is only applicable = to >>>> bearer tokens (and not to PoP tokens). This issue was raised at the >>>> last >>>> IETF meeting as well. >>>> >>> Interesting, I was reading the doc yesterday and thought it was good = it >>> was not talking about specific access token types :-) >>> >>> I wonder why a pop token can not be introspected in the interoperable= >>> way as per the text for the resource server to tale the authorization= >>> decision ? >>> >> >> The problem is that the AS needs to have the same context as the RS. I= n >> the bearer token case, the RS really only needs to pass the the access= >> token along but in the PoP case one could imagine a couple of differen= t >> solutions. >> >> A possible solution is that the AS sends the RS the necessary key so >> that the RS is able to verify the MAC or digital signature covering th= e >> request. >> >> The story would again be different if the PoP solution involves TLS. >> >> Yet another solution would be to also forward the entire request to th= e >> AS (which I wouldn't do). >> >> This is not specified in the current version of token introspection an= d, >> from the responses Justin gave at the last IETF meeting, he does not >> want to wait till the PoP work is finished to actually work out the >> details. >> >> Finally, from a security point of view it would be extremely important= >> that the AS only provides a key to the RS if the RS is (a) authenticat= ed >> and (b) the audience field from the token matches the RS since otherwi= se >> the PoP security degrades to a bearer token. >=20 > I see the draft specifying an optional resource_id hint (which I read > being an actual request URI) which is the primary signing material in > the pop case, the extra parameters like the nonce/timestamp can be > forwarded along. Of course we haven't worked out the details for the HTTP signing yet. Hence, it would be a bit premature to make that conclusion. >=20 > I agree it does not make sense to forward the actual body but that is > probably going to be a very rare case where a body hash is also provide= d. Maybe. I see a lot of value in protecting the body of the message as well but I would do it with the help of TLS and then use a channel binding mechanism. >=20 > Explicitly disallowing the support for the pop tokens in the > introspection text might the interoperability reach of either pop token= s > or token introspections in cases where a given RS integrates with a 3rd= > party AS. May be it is a Security Considerations draft issue which woul= d > make it more open for pop tokens Ultimately, we are really only talking about a document management issue here. I assume that we want to have support for introspection with PoP tokens as well and we might just end up dumping the text into the HTTP signing draft (as an extension to the token introspection doc). Ciao Hannes >=20 > Thanks, Sergey >=20 >> >> Ciao >> Hannes >> >>> Thanks, Sergey >> >=20 >=20 --5JrVLKAratT30V1ovB988Hp131cocqU5h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfb8zAAoJEGhJURNOOiAt6XkH/2JTkZ9e7QmLpxTFHCksuYsM QaB2lfnRzTzDKeRYN0XcRZvHn0s+V+lKmzj4gBaRqiZtDOKGKhvtfrvED0fhx/2m 5LOqb96Idnb0l9/k1ZXYuhnBwoKXlq50FGtq1TGkPivJPvF8X+r/vOqBkkRRKp35 4uAOpG2fme9EgErhDLVp0PJSdnaSBWDNYmMLwY20qV3BWmOH9yU+dvSy+HE16Fy0 6KGLYj961Vov4lsPa0FxkJWP/oZUs53HBBOHH+WNignyiY9krGeRONalsGQyHVsx FKzaRbkiTmrivrN4PqFfyF8FNoFvfdC5rqsGZoB7gp4H2Kj28rmZxumt4XqHN2M= =G63E -----END PGP SIGNATURE----- --5JrVLKAratT30V1ovB988Hp131cocqU5h-- From nobody Tue Dec 2 06:06:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0B71A1B78 for ; Tue, 2 Dec 2014 06:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6aE-QW3VqXX for ; Tue, 2 Dec 2014 06:05:50 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9F1A1B68 for ; Tue, 2 Dec 2014 06:05:49 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-49-547dc73c83ec Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 5A.3E.03486.C37CD745; Tue, 2 Dec 2014 09:05:48 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB2E5mMX027729; Tue, 2 Dec 2014 09:05:48 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB2E5kQK008430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Dec 2014 09:05:47 -0500 Message-ID: <547DC736.5070609@mit.edu> Date: Tue, 02 Dec 2014 09:05:42 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <547DA128.9090606@gmx.net> In-Reply-To: <547DA128.9090606@gmx.net> Content-Type: multipart/alternative; boundary="------------090906010009090407030406" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hRV1rU5Xhti8HmaucXSnfdYLU6+fcXm wOSxeNN+No8lS34yBTBFcdmkpOZklqUW6dslcGUc+fWRueDEIsaKfWd5Ghhf13cxcnBICJhI zJ6X0cXICWSKSVy4t56ti5GLQ0hgMZPEomWbWSCcDYwSl3dtYodwbjFJzPh8nAmkhVdATeLr hJvsIDaLgKrEh1MvweJsQPb0NS1gtqhAlMSdS/2sEPWCEidnPmEBsUUEYiUu/T0BFhcWcJa4 MfMMC8hFQkAzu4/YgYQ5BdQlGid/YwOxmQXCJLavPc8+gZF/FpJJs5CkZgF1MwtYS3zbXQQR lpfY/nYOM4StLbGq9ywTsvgCRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFuqZ6uZkleqkppZsY QUHN7qK0g/HnQaVDjAIcjEo8vCfO14QIsSaWFVfmHmKU5GBSEuXdc6A2RIgvKT+lMiOxOCO+ qDQntfgQowQHs5II7y9joBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgTvjaNAjYJFqempFWmZOSUIaSYOTpDhPEDD74DU8BYXJOYWZ6ZD5E8xKkqJ814HSQiAJDJK 8+B6YUnnFaM40CvCvEzHgKp4gAkLrvsV0GAmoMFnG8AGlyQipKQaGGUsHmy6EmTr+pzxx3HR qeYyh0/wh4rku+3Zlfqsv/Db4lr2b8ny717kLpvKZtxosUyTR9Lycm3vjotueSv2qr/n4Xsf xhHZuKlg5q3yQwGBAv7/eyX9ptVfOmVyv/SyWnbCtqZ9zfMutjB9mXyWf5L0jTvFdYdbveXZ 5r7w6rifqhH/+3yDpBJLcUaioRZzUXEiAPwKRKgVAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cLVIQF1iEGNZ1Tsmy-rQkRC7CVo Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:06:00 -0000 This is a multi-part message in MIME format. --------------090906010009090407030406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: > Hi Justin, > > I have a few remarks regarding version -01 of the token introspection > document. > > * Terminology > > The token introspection protocol is a client-server protocol but the > term "client" already has a meaning in OAuth. Here the client of the > token introspection protocol is actually the resource server. I believe > it would make sense to clarify this issue in the terminology section or > in the introduction. Maybe add a figure (which you could copy from > Figure 4 of > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > Maybe you want to call these two parties, the introspection client and > the introspection server. I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it. > * Scope > > I think the document needs to be very clear that is only applicable to > bearer tokens (and not to PoP tokens). This issue was raised at the last > IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is. > > * Meta-Information > > You have replicated a lot of the claims defined in > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > and I am wondering why you have decided to not just re-use the entire > registry from JWT? > > If you want to create a separate registry (which I wouldn't recommend) > then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that. > When you write: > > " > The endpoint MAY allow other parameters to provide further context to > the query. > " > > You could instead write that the token introspection MUST ignore any > parameters from the request message it does not understand. Noted, will add. > Of course, there is the question whether any of those would be security > critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wouldn't ignore them. > * Security > > The requirement for authenticating the party issuing the introspection > request to the token introspection endpoint is justified in the security > and the privacy consideration section. The security threat is that an > attacker could use the endpoint to testing for tokens. The privacy > threat is that a resource server learns about the content of the token, > which may contain personal data. I see the former as more dangerous than > the latter since a legitimate resource server is supposed to learn about > the authorization information in the token. An attacker who had gotten > hold of tokens will not only learn about the content of the token but he > will also be able to use it to get access to the protected resource itself. > > In any case, to me this sounds like mutual authentication should be > mandatory to implement. This is currently not the case. On top of that > there is single technique mandatory-to-implement outlined either (in > case someone wants to use it). That's in general not very helpful from > an interoperability point of view. Yet another thing to agree on between > the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token. > * SHOULDs > > This is my usual comment that any SHOULD statement should give the > reader enough information about the trade-off decision he has to make. > When should he implement something and when should he skip it? Noted, thanks. > * Minor items > > You write: > > " > These include using > structured token formats such as JWT [JWT] or SAML [[ Editor's Note: > Which SAML document should we reference here? ]] and proprietary > inter-service communication mechanisms (such as shared databases and > protected enterprise service buses) that convey token information. > " > > Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. > * 'Active' claim > > you write: > " > active REQUIRED. Boolean indicator of whether or not the presented > token is currently active. The authorization server determines > whether and when a given token is in an active state. > " > > Wouldn't it make more sense to return an error rather than saying that > this token is not active. It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. > * Capitalization > > Reading through the text I see bearer token/Bearer Token, Client/client, > etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more. > * AS <-> RS relationship > > You write: > " > Since > OAuth 2.0 [RFC6749] defines no direct relationship between the > authorization server and the protected resource, only that they must > have an agreement on the tokens themselves, there have been many > different approaches to bridging this gap. > " > > I am not sure what you mean by "defines no relationship" between the AS > and the RS. Of course, there is a relationship. The AS issues tokens for > access for a specific RS. The RS needs to understand the tokens or if it > does not understand them it needs to know which AS to interact with to > learn about the content. > > In a nutshell, I am not sure what you want to say with this paragraph > particularly since you state that they have to have an agreement about > the tokens. What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. -- Justin > > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090906010009090407030406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hannes, thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:
Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is.


* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Noted, will add.

Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific, in which case it wouldn't ignore them. 

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

Noted, thanks. 

* Minor items

You write:

"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   Which SAML document should we reference here? ]] and proprietary
   inter-service communication mechanisms (such as shared databases and
   protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

I'm fine with that, didn't want to offend the SAML cabal but we can cut it.

* 'Active' claim

you write:
"
   active  REQUIRED.  Boolean indicator of whether or not the presented
      token is currently active.  The authorization server determines
      whether and when a given token is in an active state.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. 

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more.

* AS <-> RS relationship

You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.

What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says:

   The methods used by the resource
   server to validate the access token (as well as any error responses)
   are beyond the scope of this specification but generally involve an
   interaction or coordination between the resource server and the
   authorization server.
This spec provides one mechanism for this validation. So we could reference this directly if that's helpful.

  -- Justin



Ciao
Hannes




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

--------------090906010009090407030406-- From nobody Tue Dec 2 06:07:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566301A1B78 for ; Tue, 2 Dec 2014 06:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0J4-GvCGkSU for ; Tue, 2 Dec 2014 06:07:40 -0800 (PST) Received: from BLU004-OMC1S37.hotmail.com (blu004-omc1s37.hotmail.com [65.55.116.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779C51A1B3D for ; Tue, 2 Dec 2014 06:07:40 -0800 (PST) Received: from BLU406-EAS165 ([65.55.116.9]) by BLU004-OMC1S37.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 06:07:39 -0800 X-TMN: [7c7kftPJcRpkOeo50d9zbLLtUgKpbYTo] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_bc89e612-4e34-4520-9303-50a369411c46_" MIME-Version: 1.0 X-Client-ID: 476 X-Mailer: BlackBerry Email (10.2.1.3442) Date: Tue, 2 Dec 2014 21:07:37 +0700 From: Panca Agus Ananda To: X-OriginalArrivalTime: 02 Dec 2014 14:07:39.0549 (UTC) FILETIME=[54FC4CD0:01D00E39] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TMlYm9SLb-dQV8DRE3-kaH-SfTQ Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:07:45 -0000 --_bc89e612-4e34-4520-9303-50a369411c46_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 1. Panca.blogspot.com Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Selasa=2C 2 Desember 2014 21.06 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 74=2C Issue 12 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Review of draft-ietf-oauth-introspection-01 (Hannes Tschofenig) 2. Re: Review of draft-ietf-oauth-introspection-01 (Justin Richer) ---------------------------------------------------------------------- Message: 1 Date: Tue=2C 02 Dec 2014 14:31:31 +0100 From: Hannes Tschofenig To: Sergey Beryozkin =2C oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: <547DBF33.90005@gmx.net> Content-Type: text/plain=3B charset=3D"windows-1252" Hi Sergey=2C comments below. On 12/02/2014 01:39 PM=2C Sergey Beryozkin wrote: > Hi Hannes > > Thanks for the clarifications=2C comments below... > On 02/12/14 12:02=2C Hannes Tschofenig wrote: >> Hi Sergey=2C >> >> On 12/02/2014 12:30 PM=2C Sergey Beryozkin wrote: >>>> >>>> * Scope >>>> >>>> I think the document needs to be very clear that is only applicable to >>>> bearer tokens (and not to PoP tokens). This issue was raised at the >>>> last >>>> IETF meeting as well. >>>> >>> Interesting=2C I was reading the doc yesterday and thought it was good = it >>> was not talking about specific access token types :-) >>> >>> I wonder why a pop token can not be introspected in the interoperable >>> way as per the text for the resource server to tale the authorization >>> decision ? >>> >> >> The problem is that the AS needs to have the same context as the RS. In >> the bearer token case=2C the RS really only needs to pass the the access >> token along but in the PoP case one could imagine a couple of different >> solutions. >> >> A possible solution is that the AS sends the RS the necessary key so >> that the RS is able to verify the MAC or digital signature covering the >> request. >> >> The story would again be different if the PoP solution involves TLS. >> >> Yet another solution would be to also forward the entire request to the >> AS (which I wouldn't do). >> >> This is not specified in the current version of token introspection and= =2C >> from the responses Justin gave at the last IETF meeting=2C he does not >> want to wait till the PoP work is finished to actually work out the >> details. >> >> Finally=2C from a security point of view it would be extremely important >> that the AS only provides a key to the RS if the RS is (a) authenticated >> and (b) the audience field from the token matches the RS since otherwise >> the PoP security degrades to a bearer token. > > I see the draft specifying an optional resource_id hint (which I read > being an actual request URI) which is the primary signing material in > the pop case=2C the extra parameters like the nonce/timestamp can be > forwarded along. Of course we haven't worked out the details for the HTTP signing yet. Hence=2C it would be a bit premature to make that conclusion. > > I agree it does not make sense to forward the actual body but that is > probably going to be a very rare case where a body hash is also provided. Maybe. I see a lot of value in protecting the body of the message as well but I would do it with the help of TLS and then use a channel binding mechanism. > > Explicitly disallowing the support for the pop tokens in the > introspection text might the interoperability reach of either pop tokens > or token introspections in cases where a given RS integrates with a 3rd > party AS. May be it is a Security Considerations draft issue which would > make it more open for pop tokens Ultimately=2C we are really only talking about a document management issue here. I assume that we want to have support for introspection with PoP tokens as well and we might just end up dumping the text into the HTTP signing draft (as an extension to the token introspection doc). Ciao Hannes > > Thanks=2C Sergey > >> >> Ciao >> Hannes >> >>> Thanks=2C Sergey >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 2 Date: Tue=2C 02 Dec 2014 09:05:42 -0500 From: Justin Richer To: Hannes Tschofenig =2C "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: <547DC736.5070609@mit.edu> Content-Type: text/plain=3B charset=3D"iso-8859-1"=3B Format=3D"flowed" Hannes=2C thanks for the review. Comments inline. On 12/2/2014 6:23 AM=2C Hannes Tschofenig wrote: > Hi Justin=2C > > I have a few remarks regarding version -01 of the token introspection > document. > > * Terminology > > The token introspection protocol is a client-server protocol but the > term "client" already has a meaning in OAuth. Here the client of the > token introspection protocol is actually the resource server. I believe > it would make sense to clarify this issue in the terminology section or > in the introduction. Maybe add a figure (which you could copy from > Figure 4 of > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > Maybe you want to call these two parties=2C the introspection client and > the introspection server. I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout=2C but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it. > * Scope > > I think the document needs to be very clear that is only applicable to > bearer tokens (and not to PoP tokens). This issue was raised at the last > IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for bearer tokens=2C since that's the only OAuth token type that's defined publicly right now=2C and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for=2C and if that can be clearer=2C please suggest better text. However=2C I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response=2C which is effectively the public portion of the PoP token. Just like a bearer token=2C this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread=2C we'll have to make a similar extension for Revocation=2C so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now=2C as-is. > > * Meta-Information > > You have replicated a lot of the claims defined in > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > and I am wondering why you have decided to not just re-use the entire > registry from JWT? > > If you want to create a separate registry (which I wouldn't recommend) > then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics=2C at least on the wire=2C and add additional fields. It probably makes sense to just inherit the JWT registry=2C so we can do that. > When you write: > > " > The endpoint MAY allow other parameters to provide further context to > the query. > " > > You could instead write that the token introspection MUST ignore any > parameters from the request message it does not understand. Noted=2C will add. > Of course=2C there is the question whether any of those would be security > critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific=2C in which case it wouldn't ignore them. > * Security > > The requirement for authenticating the party issuing the introspection > request to the token introspection endpoint is justified in the security > and the privacy consideration section. The security threat is that an > attacker could use the endpoint to testing for tokens. The privacy > threat is that a resource server learns about the content of the token=2C > which may contain personal data. I see the former as more dangerous than > the latter since a legitimate resource server is supposed to learn about > the authorization information in the token. An attacker who had gotten > hold of tokens will not only learn about the content of the token but he > will also be able to use it to get access to the protected resource itsel= f. > > In any case=2C to me this sounds like mutual authentication should be > mandatory to implement. This is currently not the case. On top of that > there is single technique mandatory-to-implement outlined either (in > case someone wants to use it). That's in general not very helpful from > an interoperability point of view. Yet another thing to agree on between > the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST=2C since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI=2C since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint=2C or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form=2C I'd suggest that we make it the OAuth bearer token. > * SHOULDs > > This is my usual comment that any SHOULD statement should give the > reader enough information about the trade-off decision he has to make. > When should he implement something and when should he skip it? Noted=2C thanks. > * Minor items > > You write: > > " > These include using > structured token formats such as JWT [JWT] or SAML [[ Editor's Note: > Which SAML document should we reference here? ]] and proprietary > inter-service communication mechanisms (such as shared databases and > protected enterprise service buses) that convey token information. > " > > Just reference the JWT since that's what we standardize. I'm fine with that=2C didn't want to offend the SAML cabal but we can cut i= t. > * 'Active' claim > > you write: > " > active REQUIRED. Boolean indicator of whether or not the presented > token is currently active. The authorization server determines > whether and when a given token is in an active state. > " > > Wouldn't it make more sense to return an error rather than saying that > this token is not active. It's not an error=2C really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response=2C but to which code? The request isn't Forbidden=2C or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it)=2C or Unauthorized=2C or even a Bad Request. So my logic is that the response is "OK"=2C but the content of the response tells you the metadata about the token=2C which is that it's not active. > * Capitalization > > Reading through the text I see bearer token/Bearer Token=2C Client/client= =2C > etc. issue. Thanks=2C still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up=2C will do more. > * AS <-> RS relationship > > You write: > " > Since > OAuth 2.0 [RFC6749] defines no direct relationship between the > authorization server and the protected resource=2C only that they mus= t > have an agreement on the tokens themselves=2C there have been many > different approaches to bridging this gap. > " > > I am not sure what you mean by "defines no relationship" between the AS > and the RS. Of course=2C there is a relationship. The AS issues tokens fo= r > access for a specific RS. The RS needs to understand the tokens or if it > does not understand them it needs to know which AS to interact with to > learn about the content. > > In a nutshell=2C I am not sure what you want to say with this paragraph > particularly since you state that they have to have an agreement about > the tokens. What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically=2C it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. -- Justin > > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 74=2C Issue 12 ************************************* --_bc89e612-4e34-4520-9303-50a369411c46_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
  1. Panca.bl= ogspot.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Selasa=2C 2 Desember 2014 21.06
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 74=2C Issue 12

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Review of draft-ietf-oauth-introspection-01
 =3B =3B =3B =3B =3B (Hannes Tschofenig)
 =3B =3B 2. Re: Review of draft-ietf-oauth-introspection-01 (Justin= Richer)


----------------------------------------------------------------------

Message: 1
Date: Tue=2C 02 Dec 2014 14:31:31 +=3B0100
From: Hannes Tschofenig <=3Bhannes.tschofenig@gmx.net>=3B
To: Sergey Beryozkin <=3Bsberyozkin@gmail.com>=3B=2C oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <=3B547DBF33.90005@gmx.net>=3B
Content-Type: text/plain=3B charset=3D"=3Bwindows-1252"=3B

Hi Sergey=2C

comments below.


On 12/02/2014 01:39 PM=2C Sergey Beryozkin wrote:
>=3B Hi Hannes
>=3B
>=3B Thanks for the clarifications=2C comments below...
>=3B On 02/12/14 12:02=2C Hannes Tschofenig wrote:
>=3B>=3B Hi Sergey=2C
>=3B>=3B
>=3B>=3B On 12/02/2014 12:30 PM=2C Sergey Beryozkin wrote:
>=3B>=3B>=3B>=3B
>=3B>=3B>=3B>=3B * Scope
>=3B>=3B>=3B>=3B
>=3B>=3B>=3B>=3B I think the document needs to be very clear that i= s only applicable to
>=3B>=3B>=3B>=3B bearer tokens (and not to PoP tokens). This issue = was raised at the
>=3B>=3B>=3B>=3B last
>=3B>=3B>=3B>=3B IETF meeting as well.
>=3B>=3B>=3B>=3B
>=3B>=3B>=3B Interesting=2C I was reading the doc yesterday and thoug= ht it was good it
>=3B>=3B>=3B was not talking about specific access token types :-) >=3B>=3B>=3B
>=3B>=3B>=3B I wonder why a pop token can not be introspected in the = interoperable
>=3B>=3B>=3B way as per the text for the resource server to tale the = authorization
>=3B>=3B>=3B decision ?
>=3B>=3B>=3B
>=3B>=3B
>=3B>=3B The problem is that the AS needs to have the same context as t= he RS. In
>=3B>=3B the bearer token case=2C the RS really only needs to pass the = the access
>=3B>=3B token along but in the PoP case one could imagine a couple of = different
>=3B>=3B solutions.
>=3B>=3B
>=3B>=3B A possible solution is that the AS sends the RS the necessary = key so
>=3B>=3B that the RS is able to verify the MAC or digital signature cov= ering the
>=3B>=3B request.
>=3B>=3B
>=3B>=3B The story would again be different if the PoP solution involve= s TLS.
>=3B>=3B
>=3B>=3B Yet another solution would be to also forward the entire reque= st to the
>=3B>=3B AS (which I wouldn't do).
>=3B>=3B
>=3B>=3B This is not specified in the current version of token introspe= ction and=2C
>=3B>=3B from the responses Justin gave at the last IETF meeting=2C he = does not
>=3B>=3B want to wait till the PoP work is finished to actually work ou= t the
>=3B>=3B details.
>=3B>=3B
>=3B>=3B Finally=2C from a security point of view it would be extremely= important
>=3B>=3B that the AS only provides a key to the RS if the RS is (a) aut= henticated
>=3B>=3B and (b) the audience field from the token matches the RS since= otherwise
>=3B>=3B the PoP security degrades to a bearer token.
>=3B
>=3B I see the draft specifying an optional resource_id hint (which I rea= d
>=3B being an actual request URI) which is the primary signing material i= n
>=3B the pop case=2C the extra parameters like the nonce/timestamp can be=
>=3B forwarded along.

Of course we haven't worked out the details for the HTTP signing yet.
Hence=2C it would be a bit premature to make that conclusion.

>=3B
>=3B I agree it does not make sense to forward the actual body but that i= s
>=3B probably going to be a very rare case where a body hash is also prov= ided.

Maybe. I see a lot of value in protecting the body of the message as
well but I would do it with the help of TLS and then use a channel
binding mechanism.

>=3B
>=3B Explicitly disallowing the support for the pop tokens in the
>=3B introspection text might the interoperability reach of either pop to= kens
>=3B or token introspections in cases where a given RS integrates with a = 3rd
>=3B party AS. May be it is a Security Considerations draft issue which w= ould
>=3B make it more open for pop tokens

Ultimately=2C we are really only talking about a document management issue<= br> here. I assume that we want to have support for introspection with PoP
tokens as well and we might just end up dumping the text into the HTTP
signing draft (as an extension to the token introspection doc).

Ciao
Hannes

>=3B
>=3B Thanks=2C Sergey
>=3B
>=3B>=3B
>=3B>=3B Ciao
>=3B>=3B Hannes
>=3B>=3B
>=3B>=3B>=3B Thanks=2C Sergey
>=3B>=3B
>=3B
>=3B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 513 bytes
Desc: OpenPGP digital signature
URL: <=3Bhttp://www.ietf.org/mail-archive/web/oa= uth/attachments/20141202/8dc9d121/attachment.asc>=3B

------------------------------

Message: 2
Date: Tue=2C 02 Dec 2014 09:05:42 -0500
From: Justin Richer <=3Bjricher@mit.edu>=3B
To: Hannes Tschofenig <=3Bhannes.tschofenig@gmx.net>=3B=2C "=3Boaut= h@ietf.org"=3B
 =3B =3B =3B =3B =3B =3B =3B <=3Boauth@ietf.o= rg>=3B
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <=3B547DC736.5070609@mit.edu>=3B
Content-Type: text/plain=3B charset=3D"=3Biso-8859-1"=3B=3B Format= =3D"=3Bflowed"=3B

Hannes=2C thanks for the review. Comments inline.

On 12/2/2014 6:23 AM=2C Hannes Tschofenig wrote:
>=3B Hi Justin=2C
>=3B
>=3B I have a few remarks regarding version -01 of the token introspectio= n
>=3B document.
>=3B
>=3B * Terminology
>=3B
>=3B The token introspection protocol is a client-server protocol but the=
>=3B term "=3Bclient"=3B already has a meaning in OAuth. Here the= client of the
>=3B token introspection protocol is actually the resource server. I beli= eve
>=3B it would make sense to clarify this issue in the terminology section= or
>=3B in the introduction. Maybe add a figure (which you could copy from >=3B Figure 4 of
>=3B http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt= .
>=3B
>=3B Maybe you want to call these two parties=2C the introspection client= and
>=3B the introspection server.

I tried to avoid the word "=3Bclient"=3B for this very reason. The = draft used
to say "=3Bclient or protected resource"=3B throughout=2C but in a = few years of
deployment experience it's become clear that it's pretty much just
protected resources that need to do introspection so I changed that text throughout. I don't think that "=3Bintrospection client"=3B will he= lp here
because the party already has a name from OAuth and we should inherit it.
>=3B * Scope
>=3B
>=3B I think the document needs to be very clear that is only applicable = to
>=3B bearer tokens (and not to PoP tokens). This issue was raised at the = last
>=3B IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism
for bearer tokens=2C since that's the only OAuth token type that's defined =
publicly right now=2C and that the details for PoP will have to be
specified in another spec -- that's exactly what Appendix C is there
for=2C and if that can be clearer=2C please suggest better text.

However=2C I think it's very clear how PoP tokens would work. You send the =
value returned as the "=3Baccess_token"=3B in the token endpoint re= sponse=2C
which is effectively the public portion of the PoP token. Just like a
bearer token=2C this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an
as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread=2C <= br> we'll have to make a similar extension for Revocation=2C so I still don't <= br> think it makes sense to hold up this work and wait for PoP to be
finished because it's useful now=2C as-is.

>=3B
>=3B * Meta-Information
>=3B
>=3B You have replicated a lot of the claims defined in
>=3B https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >=3B and I am wondering why you have decided to not just re-use the entir= e
>=3B registry from JWT?
>=3B
>=3B If you want to create a separate registry (which I wouldn't recommen= d)
>=3B then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics=2C at least on the
wire=2C and add additional fields. It probably makes sense to just inherit =
the JWT registry=2C so we can do that.

>=3B When you write:
>=3B
>=3B "=3B
>=3B The endpoint MAY allow other parameters to provide further context t= o
>=3B the query.
>=3B "=3B
>=3B
>=3B You could instead write that the token introspection MUST ignore any=
>=3B parameters from the request message it does not understand.

Noted=2C will add.

>=3B Of course=2C there is the question whether any of those would be sec= urity
>=3B critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific=2C in which case it <= br> wouldn't ignore them.

>=3B * Security
>=3B
>=3B The requirement for authenticating the party issuing the introspecti= on
>=3B request to the token introspection endpoint is justified in the secu= rity
>=3B and the privacy consideration section. The security threat is that a= n
>=3B attacker could use the endpoint to testing for tokens. The privacy >=3B threat is that a resource server learns about the content of the tok= en=2C
>=3B which may contain personal data. I see the former as more dangerous = than
>=3B the latter since a legitimate resource server is supposed to learn a= bout
>=3B the authorization information in the token. An attacker who had gott= en
>=3B hold of tokens will not only learn about the content of the token bu= t he
>=3B will also be able to use it to get access to the protected resource = itself.
>=3B
>=3B In any case=2C to me this sounds like mutual authentication should b= e
>=3B mandatory to implement. This is currently not the case. On top of th= at
>=3B there is single technique mandatory-to-implement outlined either (in=
>=3B case someone wants to use it). That's in general not very helpful fr= om
>=3B an interoperability point of view. Yet another thing to agree on bet= ween
>=3B the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want
to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST=2C since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on
this?). I'm less comfortable with making one particular mechanism MTI=2C since I know of implementations that use either a special set of
credentials passed just like client credentials to the token endpoint=2C or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form=2C I'd suggest that we make it the OAuth
bearer token.

>=3B * SHOULDs
>=3B
>=3B This is my usual comment that any SHOULD statement should give the >=3B reader enough information about the trade-off decision he has to mak= e.
>=3B When should he implement something and when should he skip it?

Noted=2C thanks.

>=3B * Minor items
>=3B
>=3B You write:
>=3B
>=3B "=3B
>=3B These include using
>=3B =3B =3B =3B =3B structured token formats such as JWT= [JWT] or SAML [[ Editor's Note:
>=3B =3B =3B =3B =3B Which SAML document should we refere= nce here? ]] and proprietary
>=3B =3B =3B =3B =3B inter-service communication mechanis= ms (such as shared databases and
>=3B =3B =3B =3B =3B protected enterprise service buses) = that convey token information.
>=3B "=3B
>=3B
>=3B Just reference the JWT since that's what we standardize.

I'm fine with that=2C didn't want to offend the SAML cabal but we can cut i= t.

>=3B * 'Active' claim
>=3B
>=3B you write:
>=3B "=3B
>=3B =3B =3B =3B =3B active =3B REQUIRED. =3B Boo= lean indicator of whether or not the presented
>=3B =3B =3B =3B =3B =3B =3B =3B token is cur= rently active. =3B The authorization server determines
>=3B =3B =3B =3B =3B =3B =3B =3B whether and = when a given token is in an active state.
>=3B "=3B
>=3B
>=3B Wouldn't it make more sense to return an error rather than saying th= at
>=3B this token is not active.

It's not an error=2C really. It's a valid request and valid response
saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response=2C but to which code? The request isn't Forbidden=2C or Not Found (the token could have been
found but it's been deactivated or just not available to the RS that's
asking for it)=2C or Unauthorized=2C or even a Bad Request. So my logic is =
that the response is "=3BOK"=3B=2C but the content of the response = tells you the
metadata about the token=2C which is that it's not active.

>=3B * Capitalization
>=3B
>=3B Reading through the text I see bearer token/Bearer Token=2C Client/c= lient=2C
>=3B etc. issue.

Thanks=2C still breaking old Bad Habits of capitalizing Terms In The
Document. Tried to clean it up=2C will do more.

>=3B * AS <=3B->=3B RS relationship
>=3B
>=3B You write:
>=3B "=3B
>=3B =3B =3B =3B =3B Since
>=3B =3B =3B =3B =3B OAuth 2.0 [RFC6749] defines no direc= t relationship between the
>=3B =3B =3B =3B =3B authorization server and the protect= ed resource=2C only that they must
>=3B =3B =3B =3B =3B have an agreement on the tokens them= selves=2C there have been many
>=3B =3B =3B =3B =3B different approaches to bridging thi= s gap.
>=3B "=3B
>=3B
>=3B I am not sure what you mean by "=3Bdefines no relationship"= =3B between the AS
>=3B and the RS. Of course=2C there is a relationship. The AS issues toke= ns for
>=3B access for a specific RS. The RS needs to understand the tokens or i= f it
>=3B does not understand them it needs to know which AS to interact with = to
>=3B learn about the content.
>=3B
>=3B In a nutshell=2C I am not sure what you want to say with this paragr= aph
>=3B particularly since you state that they have to have an agreement abo= ut
>=3B the tokens.

What I was trying to point out is that it doesn't define the nature of
the relationship between the two components. Specifically=2C it says:

 =3B =3B =3B The methods used by the resource
 =3B =3B =3B server to validate the access token (as well as an= y error responses)
 =3B =3B =3B are beyond the scope of this specification but gen= erally involve an
 =3B =3B =3B interaction or coordination between the resource s= erver and the
 =3B =3B =3B authorization server.

This spec provides one mechanism for this validation. So we could
reference this directly if that's helpful.

 =3B =3B -- Justin

>=3B
>=3B
>=3B Ciao
>=3B Hannes
>=3B
>=3B
>=3B
>=3B _______________________________________________
>=3B OAuth mailing list
>=3B OAuth@ietf.org
>=3B https://www.= ietf.org/mailman/listinfo/oauth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141202/72a4ff34/attachment.html>=3B

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest=2C Vol 74=2C Issue 12
*************************************
--_bc89e612-4e34-4520-9303-50a369411c46_-- From nobody Tue Dec 2 07:09:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3671ACE19 for ; Tue, 2 Dec 2014 07:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOVkyfdJn8Vy for ; Tue, 2 Dec 2014 07:08:43 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40531ACE2F for ; Tue, 2 Dec 2014 07:07:57 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so17030050wgh.24 for ; Tue, 02 Dec 2014 07:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+gvO8zWuMn3SELz/1H83b2kMBwWKLZXC5m2Lji6TPQA=; b=ZS5IZkb2y0rr3I/0yWg1oN/nyYKh9CVxVjS+BuKAGvsDPP/cpNH/5CfoTXIvOzpYBg U13a5jeRlti2vr24zly1CUcHODko2u8tlfo4ttRLV6x8hduOyvhch6/5XhDjhFDZoojr dNaCDKctQtQztW1loVQ77K1JSWMT4OAaqfuEV/gBjwfRmmE6LZFvg/L6lObvuiLNxCMO zp3N8llNOPhPudEROHBfweDP33mpYJaPLIFhYNGtVCaxiHW5r5Eu90hqgH7G6VrJgjVy FeREq/tkDG7AkHe2HD325z8/D+sdAZnrqKZqleLStfM5Txl3os5VaEOyQF1lOr5PJN4l ZqUg== X-Received: by 10.194.193.2 with SMTP id hk2mr99696416wjc.40.1417532876544; Tue, 02 Dec 2014 07:07:56 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id j2sm32275389wjs.28.2014.12.02.07.07.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 07:07:55 -0800 (PST) Message-ID: <547DD5CA.60002@gmail.com> Date: Tue, 02 Dec 2014 15:07:54 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> In-Reply-To: <547DC736.5070609@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lHOk6BNdFOoDiFRGpcEAZHSP2EQ Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:08:52 -0000 Hi Justin Please see a comment below On 02/12/14 14:05, Justin Richer wrote: > Hannes, thanks for the review. Comments inline. > > On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >> Hi Justin, >> >> I have a few remarks regarding version -01 of the token introspection >> document. >> >> * Terminology >> >> The token introspection protocol is a client-server protocol but the >> term "client" already has a meaning in OAuth. Here the client of the >> token introspection protocol is actually the resource server. I believe >> it would make sense to clarify this issue in the terminology section or >> in the introduction. Maybe add a figure (which you could copy from >> Figure 4 of >> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. >> >> Maybe you want to call these two parties, the introspection client and >> the introspection server. > > I tried to avoid the word "client" for this very reason. The draft used > to say "client or protected resource" throughout, but in a few years of > deployment experience it's become clear that it's pretty much just > protected resources that need to do introspection so I changed that text > throughout. I don't think that "introspection client" will help here > because the party already has a name from OAuth and we should inherit it. > >> * Scope >> >> I think the document needs to be very clear that is only applicable to >> bearer tokens (and not to PoP tokens). This issue was raised at the last >> IETF meeting as well. > > I think the document should be clear that it *specifies* the mechanism > for bearer tokens, since that's the only OAuth token type that's defined > publicly right now, and that the details for PoP will have to be > specified in another spec -- that's exactly what Appendix C is there > for, and if that can be clearer, please suggest better text. > > However, I think it's very clear how PoP tokens would work. You send the > value returned as the "access_token" in the token endpoint response, > which is effectively the public portion of the PoP token. Just like a > bearer token, this value is passed as-is from the client to the RS and > would be passed as-is from the RS to the AS during introspection. The AS > can then use that to look up the key and return it in an > as-yet-unspecified field so that the RS can validate the request. The RS > wouldn't send the signature or signed portion of the request for the AS > to validate -- that's a bad idea. But these are all details that we can > work out in the PoP-flavored extension. For me, as a non-security expert but as an implementer, the idea of spreading the token validation across multiple nodes (AS + RS), and with getting AS sending the secret key to RS, does not appear to be very sound either, it might be the right idea but the one which would likely more difficult to do right - with AS having to orchestrate a secure key delivery to RS while partially validating the token too. And there will be yet another specification/extension. I suggested it might limit the interoperability reach of this draft and of the pop token idea - I'm sorry - most likely I'm wrong but... The signature, the RS request URI, these are all the public parameters that AS can act upon. Sending the key to RS should be supported by capable OAuth2 RS implementations but IMHO the RS delegating the signature validation to AS also works... Just my 2c Sergey > As I noted in the other thread, > we'll have to make a similar extension for Revocation, so I still don't > think it makes sense to hold up this work and wait for PoP to be > finished because it's useful now, as-is. > >> >> * Meta-Information >> >> You have replicated a lot of the claims defined in >> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >> and I am wondering why you have decided to not just re-use the entire >> registry from JWT? >> >> If you want to create a separate registry (which I wouldn't recommend) >> then you have to put text into the IANA consideration section. > > The idea was to inherit JWT's syntax and semantics, at least on the > wire, and add additional fields. It probably makes sense to just inherit > the JWT registry, so we can do that. > >> When you write: >> >> " >> The endpoint MAY allow other parameters to provide further context to >> the query. >> " >> >> You could instead write that the token introspection MUST ignore any >> parameters from the request message it does not understand. > > Noted, will add. > >> Of course, there is the question whether any of those would be security >> critical and hence ignoring them would cause problems?! > > Anything security critical would be provider-specific, in which case it > wouldn't ignore them. > >> * Security >> >> The requirement for authenticating the party issuing the introspection >> request to the token introspection endpoint is justified in the security >> and the privacy consideration section. The security threat is that an >> attacker could use the endpoint to testing for tokens. The privacy >> threat is that a resource server learns about the content of the token, >> which may contain personal data. I see the former as more dangerous than >> the latter since a legitimate resource server is supposed to learn about >> the authorization information in the token. An attacker who had gotten >> hold of tokens will not only learn about the content of the token but he >> will also be able to use it to get access to the protected resource itself. >> >> In any case, to me this sounds like mutual authentication should be >> mandatory to implement. This is currently not the case. On top of that >> there is single technique mandatory-to-implement outlined either (in >> case someone wants to use it). That's in general not very helpful from >> an interoperability point of view. Yet another thing to agree on between >> the AS and the RS. > > I had similar thoughts when putting draft -01 together but didn't want > to make a normative change like that without the WG input. I'm fine with > strengthening this to a MUST, since as far as I'm aware that's how it > works in all existing implementations (can anyone else comment on > this?). I'm less comfortable with making one particular mechanism MTI, > since I know of implementations that use either a special set of > credentials passed just like client credentials to the token endpoint, > or an OAuth token specifically for the introspection endpoint. If we do > standardize on one MTI form, I'd suggest that we make it the OAuth > bearer token. > >> * SHOULDs >> >> This is my usual comment that any SHOULD statement should give the >> reader enough information about the trade-off decision he has to make. >> When should he implement something and when should he skip it? > > Noted, thanks. > >> * Minor items >> >> You write: >> >> " >> These include using >> structured token formats such as JWT [JWT] or SAML [[ Editor's Note: >> Which SAML document should we reference here? ]] and proprietary >> inter-service communication mechanisms (such as shared databases and >> protected enterprise service buses) that convey token information. >> " >> >> Just reference the JWT since that's what we standardize. > > I'm fine with that, didn't want to offend the SAML cabal but we can cut it. > >> * 'Active' claim >> >> you write: >> " >> active REQUIRED. Boolean indicator of whether or not the presented >> token is currently active. The authorization server determines >> whether and when a given token is in an active state. >> " >> >> Wouldn't it make more sense to return an error rather than saying that >> this token is not active. > > It's not an error, really. It's a valid request and valid response > saying that token isn't any good. It would be easy enough to change the > returned error code on the {active:false} response, but to which code? > The request isn't Forbidden, or Not Found (the token could have been > found but it's been deactivated or just not available to the RS that's > asking for it), or Unauthorized, or even a Bad Request. So my logic is > that the response is "OK", but the content of the response tells you the > metadata about the token, which is that it's not active. > >> * Capitalization >> >> Reading through the text I see bearer token/Bearer Token, Client/client, >> etc. issue. > > Thanks, still breaking old Bad Habits of capitalizing Terms In The > Document. Tried to clean it up, will do more. > >> * AS <-> RS relationship >> >> You write: >> " >> Since >> OAuth 2.0 [RFC6749] defines no direct relationship between the >> authorization server and the protected resource, only that they must >> have an agreement on the tokens themselves, there have been many >> different approaches to bridging this gap. >> " >> >> I am not sure what you mean by "defines no relationship" between the AS >> and the RS. Of course, there is a relationship. The AS issues tokens for >> access for a specific RS. The RS needs to understand the tokens or if it >> does not understand them it needs to know which AS to interact with to >> learn about the content. >> >> In a nutshell, I am not sure what you want to say with this paragraph >> particularly since you state that they have to have an agreement about >> the tokens. > > What I was trying to point out is that it doesn't define the nature of > the relationship between the two components. Specifically, it says: > > The methods used by the resource > server to validate the access token (as well as any error responses) > are beyond the scope of this specification but generally involve an > interaction or coordination between the resource server and the > authorization server. > > This spec provides one mechanism for this validation. So we could > reference this directly if that's helpful. > > -- Justin > >> >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> 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 nobody Tue Dec 2 07:26:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9745B1A1B3D; Tue, 2 Dec 2014 07:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkL8A-LHKccn; Tue, 2 Dec 2014 07:26:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA321ACE1A; Tue, 2 Dec 2014 07:25:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202152538.24869.296.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 07:25:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/prSOAOEv32oH6vdPTOCeaQlULc8 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:26:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-21.txt Pages : 38 Date : 2014-12-02 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 2 07:36:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24091A1BD1 for ; Tue, 2 Dec 2014 07:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmmbmj80wnej for ; Tue, 2 Dec 2014 07:36:52 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE11A026F for ; Tue, 2 Dec 2014 07:36:52 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 094DB72E254; Tue, 2 Dec 2014 10:36:49 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id EBFB972E250; Tue, 2 Dec 2014 10:36:48 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 10:36:48 -0500 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgAARYQCAAAhDAA== Date: Tue, 2 Dec 2014 15:36:47 +0000 Message-ID: <10B6E185-E0B8-4FE2-890C-24ADB519E6E0@mitre.org> References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <547DD5CA.60002@gmail.com> In-Reply-To: <547DD5CA.60002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <3ACB9003010E9E4082BB97B2DE35EB78@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LqrL3r7bLPp2yHea3Y2rJtXLPOU Cc: oauth Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:36:56 -0000 >> However, I think it's very clear how PoP tokens would work. You send the >> value returned as the "access_token" in the token endpoint response, >> which is effectively the public portion of the PoP token. Just like a >> bearer token, this value is passed as-is from the client to the RS and >> would be passed as-is from the RS to the AS during introspection. The AS >> can then use that to look up the key and return it in an >> as-yet-unspecified field so that the RS can validate the request. The RS >> wouldn't send the signature or signed portion of the request for the AS >> to validate -- that's a bad idea. But these are all details that we can >> work out in the PoP-flavored extension. > For me, as a non-security expert but as an implementer, the idea of sprea= ding the token validation across multiple nodes (AS + RS), and with getting= AS sending the secret key to RS, does not appear to be very sound either, = it might be the right idea but the one which would likely more difficult to= do right - with AS having to orchestrate a secure key delivery to RS while= partially validating the token too. >=20 > And there will be yet another specification/extension. >=20 > I suggested it might limit the interoperability reach of this draft and o= f the pop token idea - I'm sorry - most likely I'm wrong but... >=20 > The signature, the RS request URI, these are all the public parameters th= at AS can act upon. Sending the key to RS should be supported by capable OA= uth2 RS implementations but IMHO the RS delegating the signature validation= to AS also works... >=20 > Just my 2c Secure key delivery is pretty straight forward -- you can just pass the key= in a JWK over TLS in response to an authorized request. For asymmetric key= s, this would even just be the public key used to validate the signature, s= o there's not really any security leakage. Symmetric keys are trickier, but= that's a well known tradeoff. I think that in practice you'd lose too much of the context of the request = to the RS in order to make a meaningful decision at the AS. I would rather = token introspection be limited to "what can you tell me about this token" a= nd not the larger, stickier question of "what should I do with this request= ". But I think that you're right in that if we solve the former, we have a = stepping stone for solving the latter. I don't, however, want us to get cau= ght up in an ocean-boiling exercise when we've got one solidly useful puddl= e we can do something about. As such, I punted all mention of PoP to the appendix and I personally think= it should stay there as a note of some kind, saying that it's out of scope= but not out of reach. -- Justin On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin wrote: > Hi Justin >=20 > Please see a comment below >=20 > On 02/12/14 14:05, Justin Richer wrote: >> Hannes, thanks for the review. Comments inline. >>=20 >> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >>> Hi Justin, >>>=20 >>> I have a few remarks regarding version -01 of the token introspection >>> document. >>>=20 >>> * Terminology >>>=20 >>> The token introspection protocol is a client-server protocol but the >>> term "client" already has a meaning in OAuth. Here the client of the >>> token introspection protocol is actually the resource server. I believe >>> it would make sense to clarify this issue in the terminology section or >>> in the introduction. Maybe add a figure (which you could copy from >>> Figure 4 of >>> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. >>>=20 >>> Maybe you want to call these two parties, the introspection client and >>> the introspection server. >>=20 >> I tried to avoid the word "client" for this very reason. The draft used >> to say "client or protected resource" throughout, but in a few years of >> deployment experience it's become clear that it's pretty much just >> protected resources that need to do introspection so I changed that text >> throughout. I don't think that "introspection client" will help here >> because the party already has a name from OAuth and we should inherit it= . >>=20 >>> * Scope >>>=20 >>> I think the document needs to be very clear that is only applicable to >>> bearer tokens (and not to PoP tokens). This issue was raised at the las= t >>> IETF meeting as well. >>=20 >> I think the document should be clear that it *specifies* the mechanism >> for bearer tokens, since that's the only OAuth token type that's defined >> publicly right now, and that the details for PoP will have to be >> specified in another spec -- that's exactly what Appendix C is there >> for, and if that can be clearer, please suggest better text. >>=20 >> However, I think it's very clear how PoP tokens would work. You send the >> value returned as the "access_token" in the token endpoint response, >> which is effectively the public portion of the PoP token. Just like a >> bearer token, this value is passed as-is from the client to the RS and >> would be passed as-is from the RS to the AS during introspection. The AS >> can then use that to look up the key and return it in an >> as-yet-unspecified field so that the RS can validate the request. The RS >> wouldn't send the signature or signed portion of the request for the AS >> to validate -- that's a bad idea. But these are all details that we can >> work out in the PoP-flavored extension. > For me, as a non-security expert but as an implementer, the idea of sprea= ding the token validation across multiple nodes (AS + RS), and with getting= AS sending the secret key to RS, does not appear to be very sound either, = it might be the right idea but the one which would likely more difficult to= do right - with AS having to orchestrate a secure key delivery to RS while= partially validating the token too. >=20 > And there will be yet another specification/extension. >=20 > I suggested it might limit the interoperability reach of this draft and o= f the pop token idea - I'm sorry - most likely I'm wrong but... >=20 > The signature, the RS request URI, these are all the public parameters th= at AS can act upon. Sending the key to RS should be supported by capable OA= uth2 RS implementations but IMHO the RS delegating the signature validation= to AS also works... >=20 > Just my 2c >=20 > Sergey >=20 >=20 >> As I noted in the other thread, >> we'll have to make a similar extension for Revocation, so I still don't >> think it makes sense to hold up this work and wait for PoP to be >> finished because it's useful now, as-is. >>=20 >>>=20 >>> * Meta-Information >>>=20 >>> You have replicated a lot of the claims defined in >>> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >>> and I am wondering why you have decided to not just re-use the entire >>> registry from JWT? >>>=20 >>> If you want to create a separate registry (which I wouldn't recommend) >>> then you have to put text into the IANA consideration section. >>=20 >> The idea was to inherit JWT's syntax and semantics, at least on the >> wire, and add additional fields. It probably makes sense to just inherit >> the JWT registry, so we can do that. >>=20 >>> When you write: >>>=20 >>> " >>> The endpoint MAY allow other parameters to provide further context to >>> the query. >>> " >>>=20 >>> You could instead write that the token introspection MUST ignore any >>> parameters from the request message it does not understand. >>=20 >> Noted, will add. >>=20 >>> Of course, there is the question whether any of those would be security >>> critical and hence ignoring them would cause problems?! >>=20 >> Anything security critical would be provider-specific, in which case it >> wouldn't ignore them. >>=20 >>> * Security >>>=20 >>> The requirement for authenticating the party issuing the introspection >>> request to the token introspection endpoint is justified in the securit= y >>> and the privacy consideration section. The security threat is that an >>> attacker could use the endpoint to testing for tokens. The privacy >>> threat is that a resource server learns about the content of the token, >>> which may contain personal data. I see the former as more dangerous tha= n >>> the latter since a legitimate resource server is supposed to learn abou= t >>> the authorization information in the token. An attacker who had gotten >>> hold of tokens will not only learn about the content of the token but h= e >>> will also be able to use it to get access to the protected resource its= elf. >>>=20 >>> In any case, to me this sounds like mutual authentication should be >>> mandatory to implement. This is currently not the case. On top of that >>> there is single technique mandatory-to-implement outlined either (in >>> case someone wants to use it). That's in general not very helpful from >>> an interoperability point of view. Yet another thing to agree on betwee= n >>> the AS and the RS. >>=20 >> I had similar thoughts when putting draft -01 together but didn't want >> to make a normative change like that without the WG input. I'm fine with >> strengthening this to a MUST, since as far as I'm aware that's how it >> works in all existing implementations (can anyone else comment on >> this?). I'm less comfortable with making one particular mechanism MTI, >> since I know of implementations that use either a special set of >> credentials passed just like client credentials to the token endpoint, >> or an OAuth token specifically for the introspection endpoint. If we do >> standardize on one MTI form, I'd suggest that we make it the OAuth >> bearer token. >>=20 >>> * SHOULDs >>>=20 >>> This is my usual comment that any SHOULD statement should give the >>> reader enough information about the trade-off decision he has to make. >>> When should he implement something and when should he skip it? >>=20 >> Noted, thanks. >>=20 >>> * Minor items >>>=20 >>> You write: >>>=20 >>> " >>> These include using >>> structured token formats such as JWT [JWT] or SAML [[ Editor's Note: >>> Which SAML document should we reference here? ]] and proprietary >>> inter-service communication mechanisms (such as shared databases and >>> protected enterprise service buses) that convey token information. >>> " >>>=20 >>> Just reference the JWT since that's what we standardize. >>=20 >> I'm fine with that, didn't want to offend the SAML cabal but we can cut = it. >>=20 >>> * 'Active' claim >>>=20 >>> you write: >>> " >>> active REQUIRED. Boolean indicator of whether or not the presented >>> token is currently active. The authorization server determines >>> whether and when a given token is in an active state. >>> " >>>=20 >>> Wouldn't it make more sense to return an error rather than saying that >>> this token is not active. >>=20 >> It's not an error, really. It's a valid request and valid response >> saying that token isn't any good. It would be easy enough to change the >> returned error code on the {active:false} response, but to which code? >> The request isn't Forbidden, or Not Found (the token could have been >> found but it's been deactivated or just not available to the RS that's >> asking for it), or Unauthorized, or even a Bad Request. So my logic is >> that the response is "OK", but the content of the response tells you the >> metadata about the token, which is that it's not active. >>=20 >>> * Capitalization >>>=20 >>> Reading through the text I see bearer token/Bearer Token, Client/client= , >>> etc. issue. >>=20 >> Thanks, still breaking old Bad Habits of capitalizing Terms In The >> Document. Tried to clean it up, will do more. >>=20 >>> * AS <-> RS relationship >>>=20 >>> You write: >>> " >>> Since >>> OAuth 2.0 [RFC6749] defines no direct relationship between the >>> authorization server and the protected resource, only that they must >>> have an agreement on the tokens themselves, there have been many >>> different approaches to bridging this gap. >>> " >>>=20 >>> I am not sure what you mean by "defines no relationship" between the AS >>> and the RS. Of course, there is a relationship. The AS issues tokens fo= r >>> access for a specific RS. The RS needs to understand the tokens or if i= t >>> does not understand them it needs to know which AS to interact with to >>> learn about the content. >>>=20 >>> In a nutshell, I am not sure what you want to say with this paragraph >>> particularly since you state that they have to have an agreement about >>> the tokens. >>=20 >> What I was trying to point out is that it doesn't define the nature of >> the relationship between the two components. Specifically, it says: >>=20 >> The methods used by the resource >> server to validate the access token (as well as any error responses) >> are beyond the scope of this specification but generally involve an >> interaction or coordination between the resource server and the >> authorization server. >>=20 >> This spec provides one mechanism for this validation. So we could >> reference this directly if that's helpful. >>=20 >> -- Justin >>=20 >>>=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=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 From nobody Tue Dec 2 07:45:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519971A026F for ; Tue, 2 Dec 2014 07:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc0EbbvPyMmR for ; Tue, 2 Dec 2014 07:45:07 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912321ACE01 for ; Tue, 2 Dec 2014 07:44:27 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id a1so9120492wgh.19 for ; Tue, 02 Dec 2014 07:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=By9Ysa4sKtet+uK+z4TpAVez8nOx2xaZ+krno3nAHgk=; b=FaaTARG+hh8gwOVTMC6gcf+4uStFugXc9wdjj3JvoLK2+N9RCWwXmp4S7Xs4yVPOyR INfW698hWPByOjp6/IQ5vyqllVaRWwpbJjjCvlrqWMIqV0LBdvfsdiRW2ck2MqRvwxAU iPg2PInbiCo2bI2wrh4rpatk7ZGLogCyCF9fMrJdP28yRSf0O8dtZZyPYjHp1oRM2wBA 9kai8K5FjMEdhBBgwMGGBmU0F15n3ktk1+PgeZQ5fyFBinWAS/6KipyQL16sV17OlRCX MuH3FrN9bnz/aGwLl0YCm6NTkaNEqx7cwWNxgxJOmthPUjXmqf/prmpTR8pHGygd8N0v 8HIQ== X-Received: by 10.180.82.227 with SMTP id l3mr67477027wiy.0.1417535066219; Tue, 02 Dec 2014 07:44:26 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id h8sm33243992wiy.17.2014.12.02.07.44.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 07:44:25 -0800 (PST) Message-ID: <547DDE58.5070601@gmail.com> Date: Tue, 02 Dec 2014 15:44:24 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <547DD5CA.60002@gmail.com> <10B6E185-E0B8-4FE2-890C-24ADB519E6E0@mitre.org> In-Reply-To: <10B6E185-E0B8-4FE2-890C-24ADB519E6E0@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/V1mnaHnUmpQoNC7DrZyRbz6WC1Y Cc: oauth Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:45:15 -0000 Hi Justin, On 02/12/14 15:36, Richer, Justin P. wrote: >>> However, I think it's very clear how PoP tokens would work. You send the >>> value returned as the "access_token" in the token endpoint response, >>> which is effectively the public portion of the PoP token. Just like a >>> bearer token, this value is passed as-is from the client to the RS and >>> would be passed as-is from the RS to the AS during introspection. The AS >>> can then use that to look up the key and return it in an >>> as-yet-unspecified field so that the RS can validate the request. The RS >>> wouldn't send the signature or signed portion of the request for the AS >>> to validate -- that's a bad idea. But these are all details that we can >>> work out in the PoP-flavored extension. >> For me, as a non-security expert but as an implementer, the idea of spreading the token validation across multiple nodes (AS + RS), and with getting AS sending the secret key to RS, does not appear to be very sound either, it might be the right idea but the one which would likely more difficult to do right - with AS having to orchestrate a secure key delivery to RS while partially validating the token too. >> >> And there will be yet another specification/extension. >> >> I suggested it might limit the interoperability reach of this draft and of the pop token idea - I'm sorry - most likely I'm wrong but... >> >> The signature, the RS request URI, these are all the public parameters that AS can act upon. Sending the key to RS should be supported by capable OAuth2 RS implementations but IMHO the RS delegating the signature validation to AS also works... >> >> Just my 2c > > Secure key delivery is pretty straight forward -- you can just pass the key in a JWK over TLS in response to an authorized request. For asymmetric keys, this would even just be the public key used to validate the signature, so there's not really any security leakage. Symmetric keys are trickier, but that's a well known tradeoff. > > I think that in practice you'd lose too much of the context of the request to the RS in order to make a meaningful decision at the AS. I would rather token introspection be limited to "what can you tell me about this token" and not the larger, stickier question of "what should I do with this request". But I think that you're right in that if we solve the former, we have a stepping stone for solving the latter. I don't, however, want us to get caught up in an ocean-boiling exercise when we've got one solidly useful puddle we can do something about. > Your language is very rich :-) > As such, I punted all mention of PoP to the appendix and I personally think it should stay there as a note of some kind, saying that it's out of scope but not out of reach. > +1, it is a good compromise. Thanks for the clarifications, Sergey > -- Justin > > > > > On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin wrote: > >> Hi Justin >> >> Please see a comment below >> >> On 02/12/14 14:05, Justin Richer wrote: >>> Hannes, thanks for the review. Comments inline. >>> >>> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >>>> Hi Justin, >>>> >>>> I have a few remarks regarding version -01 of the token introspection >>>> document. >>>> >>>> * Terminology >>>> >>>> The token introspection protocol is a client-server protocol but the >>>> term "client" already has a meaning in OAuth. Here the client of the >>>> token introspection protocol is actually the resource server. I believe >>>> it would make sense to clarify this issue in the terminology section or >>>> in the introduction. Maybe add a figure (which you could copy from >>>> Figure 4 of >>>> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. >>>> >>>> Maybe you want to call these two parties, the introspection client and >>>> the introspection server. >>> >>> I tried to avoid the word "client" for this very reason. The draft used >>> to say "client or protected resource" throughout, but in a few years of >>> deployment experience it's become clear that it's pretty much just >>> protected resources that need to do introspection so I changed that text >>> throughout. I don't think that "introspection client" will help here >>> because the party already has a name from OAuth and we should inherit it. >>> >>>> * Scope >>>> >>>> I think the document needs to be very clear that is only applicable to >>>> bearer tokens (and not to PoP tokens). This issue was raised at the last >>>> IETF meeting as well. >>> >>> I think the document should be clear that it *specifies* the mechanism >>> for bearer tokens, since that's the only OAuth token type that's defined >>> publicly right now, and that the details for PoP will have to be >>> specified in another spec -- that's exactly what Appendix C is there >>> for, and if that can be clearer, please suggest better text. >>> >>> However, I think it's very clear how PoP tokens would work. You send the >>> value returned as the "access_token" in the token endpoint response, >>> which is effectively the public portion of the PoP token. Just like a >>> bearer token, this value is passed as-is from the client to the RS and >>> would be passed as-is from the RS to the AS during introspection. The AS >>> can then use that to look up the key and return it in an >>> as-yet-unspecified field so that the RS can validate the request. The RS >>> wouldn't send the signature or signed portion of the request for the AS >>> to validate -- that's a bad idea. But these are all details that we can >>> work out in the PoP-flavored extension. >> For me, as a non-security expert but as an implementer, the idea of spreading the token validation across multiple nodes (AS + RS), and with getting AS sending the secret key to RS, does not appear to be very sound either, it might be the right idea but the one which would likely more difficult to do right - with AS having to orchestrate a secure key delivery to RS while partially validating the token too. >> >> And there will be yet another specification/extension. >> >> I suggested it might limit the interoperability reach of this draft and of the pop token idea - I'm sorry - most likely I'm wrong but... >> >> The signature, the RS request URI, these are all the public parameters that AS can act upon. Sending the key to RS should be supported by capable OAuth2 RS implementations but IMHO the RS delegating the signature validation to AS also works... >> >> Just my 2c >> >> Sergey >> >> >>> As I noted in the other thread, >>> we'll have to make a similar extension for Revocation, so I still don't >>> think it makes sense to hold up this work and wait for PoP to be >>> finished because it's useful now, as-is. >>> >>>> >>>> * Meta-Information >>>> >>>> You have replicated a lot of the claims defined in >>>> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >>>> and I am wondering why you have decided to not just re-use the entire >>>> registry from JWT? >>>> >>>> If you want to create a separate registry (which I wouldn't recommend) >>>> then you have to put text into the IANA consideration section. >>> >>> The idea was to inherit JWT's syntax and semantics, at least on the >>> wire, and add additional fields. It probably makes sense to just inherit >>> the JWT registry, so we can do that. >>> >>>> When you write: >>>> >>>> " >>>> The endpoint MAY allow other parameters to provide further context to >>>> the query. >>>> " >>>> >>>> You could instead write that the token introspection MUST ignore any >>>> parameters from the request message it does not understand. >>> >>> Noted, will add. >>> >>>> Of course, there is the question whether any of those would be security >>>> critical and hence ignoring them would cause problems?! >>> >>> Anything security critical would be provider-specific, in which case it >>> wouldn't ignore them. >>> >>>> * Security >>>> >>>> The requirement for authenticating the party issuing the introspection >>>> request to the token introspection endpoint is justified in the security >>>> and the privacy consideration section. The security threat is that an >>>> attacker could use the endpoint to testing for tokens. The privacy >>>> threat is that a resource server learns about the content of the token, >>>> which may contain personal data. I see the former as more dangerous than >>>> the latter since a legitimate resource server is supposed to learn about >>>> the authorization information in the token. An attacker who had gotten >>>> hold of tokens will not only learn about the content of the token but he >>>> will also be able to use it to get access to the protected resource itself. >>>> >>>> In any case, to me this sounds like mutual authentication should be >>>> mandatory to implement. This is currently not the case. On top of that >>>> there is single technique mandatory-to-implement outlined either (in >>>> case someone wants to use it). That's in general not very helpful from >>>> an interoperability point of view. Yet another thing to agree on between >>>> the AS and the RS. >>> >>> I had similar thoughts when putting draft -01 together but didn't want >>> to make a normative change like that without the WG input. I'm fine with >>> strengthening this to a MUST, since as far as I'm aware that's how it >>> works in all existing implementations (can anyone else comment on >>> this?). I'm less comfortable with making one particular mechanism MTI, >>> since I know of implementations that use either a special set of >>> credentials passed just like client credentials to the token endpoint, >>> or an OAuth token specifically for the introspection endpoint. If we do >>> standardize on one MTI form, I'd suggest that we make it the OAuth >>> bearer token. >>> >>>> * SHOULDs >>>> >>>> This is my usual comment that any SHOULD statement should give the >>>> reader enough information about the trade-off decision he has to make. >>>> When should he implement something and when should he skip it? >>> >>> Noted, thanks. >>> >>>> * Minor items >>>> >>>> You write: >>>> >>>> " >>>> These include using >>>> structured token formats such as JWT [JWT] or SAML [[ Editor's Note: >>>> Which SAML document should we reference here? ]] and proprietary >>>> inter-service communication mechanisms (such as shared databases and >>>> protected enterprise service buses) that convey token information. >>>> " >>>> >>>> Just reference the JWT since that's what we standardize. >>> >>> I'm fine with that, didn't want to offend the SAML cabal but we can cut it. >>> >>>> * 'Active' claim >>>> >>>> you write: >>>> " >>>> active REQUIRED. Boolean indicator of whether or not the presented >>>> token is currently active. The authorization server determines >>>> whether and when a given token is in an active state. >>>> " >>>> >>>> Wouldn't it make more sense to return an error rather than saying that >>>> this token is not active. >>> >>> It's not an error, really. It's a valid request and valid response >>> saying that token isn't any good. It would be easy enough to change the >>> returned error code on the {active:false} response, but to which code? >>> The request isn't Forbidden, or Not Found (the token could have been >>> found but it's been deactivated or just not available to the RS that's >>> asking for it), or Unauthorized, or even a Bad Request. So my logic is >>> that the response is "OK", but the content of the response tells you the >>> metadata about the token, which is that it's not active. >>> >>>> * Capitalization >>>> >>>> Reading through the text I see bearer token/Bearer Token, Client/client, >>>> etc. issue. >>> >>> Thanks, still breaking old Bad Habits of capitalizing Terms In The >>> Document. Tried to clean it up, will do more. >>> >>>> * AS <-> RS relationship >>>> >>>> You write: >>>> " >>>> Since >>>> OAuth 2.0 [RFC6749] defines no direct relationship between the >>>> authorization server and the protected resource, only that they must >>>> have an agreement on the tokens themselves, there have been many >>>> different approaches to bridging this gap. >>>> " >>>> >>>> I am not sure what you mean by "defines no relationship" between the AS >>>> and the RS. Of course, there is a relationship. The AS issues tokens for >>>> access for a specific RS. The RS needs to understand the tokens or if it >>>> does not understand them it needs to know which AS to interact with to >>>> learn about the content. >>>> >>>> In a nutshell, I am not sure what you want to say with this paragraph >>>> particularly since you state that they have to have an agreement about >>>> the tokens. >>> >>> What I was trying to point out is that it doesn't define the nature of >>> the relationship between the two components. Specifically, it says: >>> >>> The methods used by the resource >>> server to validate the access token (as well as any error responses) >>> are beyond the scope of this specification but generally involve an >>> interaction or coordination between the resource server and the >>> authorization server. >>> >>> This spec provides one mechanism for this validation. So we could >>> reference this directly if that's helpful. >>> >>> -- Justin >>> >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 nobody Tue Dec 2 07:46:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613291A3BA2 for ; Tue, 2 Dec 2014 07:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmQlCE8CzpuA for ; Tue, 2 Dec 2014 07:46:28 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 628B01A1B06 for ; Tue, 2 Dec 2014 07:46:28 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 18DB672E261; Tue, 2 Dec 2014 10:46:28 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 0DBBB72E260; Tue, 2 Dec 2014 10:46:28 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 10:46:27 -0500 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgAARYQCAAAhDAIAAAfAAgAAAwQA= Date: Tue, 2 Dec 2014 15:46:26 +0000 Message-ID: <8C0040BF-55EC-4A9D-9D3E-F7EB9A79001F@mitre.org> References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <547DD5CA.60002@gmail.com> <10B6E185-E0B8-4FE2-890C-24ADB519E6E0@mitre.org> <547DDE58.5070601@gmail.com> In-Reply-To: <547DDE58.5070601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/j7n_7Tt8ShIrBVfF6qt--3Z7Q_c Cc: oauth Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:46:32 -0000 If you're not torturing the metaphors, you're not really trying. :) And, in case it wasn't clear before, I am very open to better text in Appen= dix C if anyone wants to suggest something. -- Justin On Dec 2, 2014, at 10:44 AM, Sergey Beryozkin wrote: > Hi Justin, > On 02/12/14 15:36, Richer, Justin P. wrote: >>>> However, I think it's very clear how PoP tokens would work. You send t= he >>>> value returned as the "access_token" in the token endpoint response, >>>> which is effectively the public portion of the PoP token. Just like a >>>> bearer token, this value is passed as-is from the client to the RS and >>>> would be passed as-is from the RS to the AS during introspection. The = AS >>>> can then use that to look up the key and return it in an >>>> as-yet-unspecified field so that the RS can validate the request. The = RS >>>> wouldn't send the signature or signed portion of the request for the A= S >>>> to validate -- that's a bad idea. But these are all details that we ca= n >>>> work out in the PoP-flavored extension. >>> For me, as a non-security expert but as an implementer, the idea of spr= eading the token validation across multiple nodes (AS + RS), and with getti= ng AS sending the secret key to RS, does not appear to be very sound either= , it might be the right idea but the one which would likely more difficult = to do right - with AS having to orchestrate a secure key delivery to RS whi= le partially validating the token too. >>>=20 >>> And there will be yet another specification/extension. >>>=20 >>> I suggested it might limit the interoperability reach of this draft and= of the pop token idea - I'm sorry - most likely I'm wrong but... >>>=20 >>> The signature, the RS request URI, these are all the public parameters = that AS can act upon. Sending the key to RS should be supported by capable = OAuth2 RS implementations but IMHO the RS delegating the signature validati= on to AS also works... >>>=20 >>> Just my 2c >>=20 >> Secure key delivery is pretty straight forward -- you can just pass the = key in a JWK over TLS in response to an authorized request. For asymmetric = keys, this would even just be the public key used to validate the signature= , so there's not really any security leakage. Symmetric keys are trickier, = but that's a well known tradeoff. >>=20 >> I think that in practice you'd lose too much of the context of the reque= st to the RS in order to make a meaningful decision at the AS. I would rath= er token introspection be limited to "what can you tell me about this token= " and not the larger, stickier question of "what should I do with this requ= est". But I think that you're right in that if we solve the former, we have= a stepping stone for solving the latter. I don't, however, want us to get = caught up in an ocean-boiling exercise when we've got one solidly useful pu= ddle we can do something about. >>=20 > Your language is very rich :-) >=20 >> As such, I punted all mention of PoP to the appendix and I personally th= ink it should stay there as a note of some kind, saying that it's out of sc= ope but not out of reach. >>=20 > +1, it is a good compromise. >=20 > Thanks for the clarifications, > Sergey >> -- Justin >>=20 >>=20 >>=20 >>=20 >> On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin wro= te: >>=20 >>> Hi Justin >>>=20 >>> Please see a comment below >>>=20 >>> On 02/12/14 14:05, Justin Richer wrote: >>>> Hannes, thanks for the review. Comments inline. >>>>=20 >>>> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >>>>> Hi Justin, >>>>>=20 >>>>> I have a few remarks regarding version -01 of the token introspection >>>>> document. >>>>>=20 >>>>> * Terminology >>>>>=20 >>>>> The token introspection protocol is a client-server protocol but the >>>>> term "client" already has a meaning in OAuth. Here the client of the >>>>> token introspection protocol is actually the resource server. I belie= ve >>>>> it would make sense to clarify this issue in the terminology section = or >>>>> in the introduction. Maybe add a figure (which you could copy from >>>>> Figure 4 of >>>>> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. >>>>>=20 >>>>> Maybe you want to call these two parties, the introspection client an= d >>>>> the introspection server. >>>>=20 >>>> I tried to avoid the word "client" for this very reason. The draft use= d >>>> to say "client or protected resource" throughout, but in a few years o= f >>>> deployment experience it's become clear that it's pretty much just >>>> protected resources that need to do introspection so I changed that te= xt >>>> throughout. I don't think that "introspection client" will help here >>>> because the party already has a name from OAuth and we should inherit = it. >>>>=20 >>>>> * Scope >>>>>=20 >>>>> I think the document needs to be very clear that is only applicable t= o >>>>> bearer tokens (and not to PoP tokens). This issue was raised at the l= ast >>>>> IETF meeting as well. >>>>=20 >>>> I think the document should be clear that it *specifies* the mechanism >>>> for bearer tokens, since that's the only OAuth token type that's defin= ed >>>> publicly right now, and that the details for PoP will have to be >>>> specified in another spec -- that's exactly what Appendix C is there >>>> for, and if that can be clearer, please suggest better text. >>>>=20 >>>> However, I think it's very clear how PoP tokens would work. You send t= he >>>> value returned as the "access_token" in the token endpoint response, >>>> which is effectively the public portion of the PoP token. Just like a >>>> bearer token, this value is passed as-is from the client to the RS and >>>> would be passed as-is from the RS to the AS during introspection. The = AS >>>> can then use that to look up the key and return it in an >>>> as-yet-unspecified field so that the RS can validate the request. The = RS >>>> wouldn't send the signature or signed portion of the request for the A= S >>>> to validate -- that's a bad idea. But these are all details that we ca= n >>>> work out in the PoP-flavored extension. >>> For me, as a non-security expert but as an implementer, the idea of spr= eading the token validation across multiple nodes (AS + RS), and with getti= ng AS sending the secret key to RS, does not appear to be very sound either= , it might be the right idea but the one which would likely more difficult = to do right - with AS having to orchestrate a secure key delivery to RS whi= le partially validating the token too. >>>=20 >>> And there will be yet another specification/extension. >>>=20 >>> I suggested it might limit the interoperability reach of this draft and= of the pop token idea - I'm sorry - most likely I'm wrong but... >>>=20 >>> The signature, the RS request URI, these are all the public parameters = that AS can act upon. Sending the key to RS should be supported by capable = OAuth2 RS implementations but IMHO the RS delegating the signature validati= on to AS also works... >>>=20 >>> Just my 2c >>>=20 >>> Sergey >>>=20 >>>=20 >>>> As I noted in the other thread, >>>> we'll have to make a similar extension for Revocation, so I still don'= t >>>> think it makes sense to hold up this work and wait for PoP to be >>>> finished because it's useful now, as-is. >>>>=20 >>>>>=20 >>>>> * Meta-Information >>>>>=20 >>>>> You have replicated a lot of the claims defined in >>>>> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 >>>>> and I am wondering why you have decided to not just re-use the entire >>>>> registry from JWT? >>>>>=20 >>>>> If you want to create a separate registry (which I wouldn't recommend= ) >>>>> then you have to put text into the IANA consideration section. >>>>=20 >>>> The idea was to inherit JWT's syntax and semantics, at least on the >>>> wire, and add additional fields. It probably makes sense to just inher= it >>>> the JWT registry, so we can do that. >>>>=20 >>>>> When you write: >>>>>=20 >>>>> " >>>>> The endpoint MAY allow other parameters to provide further context to >>>>> the query. >>>>> " >>>>>=20 >>>>> You could instead write that the token introspection MUST ignore any >>>>> parameters from the request message it does not understand. >>>>=20 >>>> Noted, will add. >>>>=20 >>>>> Of course, there is the question whether any of those would be securi= ty >>>>> critical and hence ignoring them would cause problems?! >>>>=20 >>>> Anything security critical would be provider-specific, in which case i= t >>>> wouldn't ignore them. >>>>=20 >>>>> * Security >>>>>=20 >>>>> The requirement for authenticating the party issuing the introspectio= n >>>>> request to the token introspection endpoint is justified in the secur= ity >>>>> and the privacy consideration section. The security threat is that an >>>>> attacker could use the endpoint to testing for tokens. The privacy >>>>> threat is that a resource server learns about the content of the toke= n, >>>>> which may contain personal data. I see the former as more dangerous t= han >>>>> the latter since a legitimate resource server is supposed to learn ab= out >>>>> the authorization information in the token. An attacker who had gotte= n >>>>> hold of tokens will not only learn about the content of the token but= he >>>>> will also be able to use it to get access to the protected resource i= tself. >>>>>=20 >>>>> In any case, to me this sounds like mutual authentication should be >>>>> mandatory to implement. This is currently not the case. On top of tha= t >>>>> there is single technique mandatory-to-implement outlined either (in >>>>> case someone wants to use it). That's in general not very helpful fro= m >>>>> an interoperability point of view. Yet another thing to agree on betw= een >>>>> the AS and the RS. >>>>=20 >>>> I had similar thoughts when putting draft -01 together but didn't want >>>> to make a normative change like that without the WG input. I'm fine wi= th >>>> strengthening this to a MUST, since as far as I'm aware that's how it >>>> works in all existing implementations (can anyone else comment on >>>> this?). I'm less comfortable with making one particular mechanism MTI, >>>> since I know of implementations that use either a special set of >>>> credentials passed just like client credentials to the token endpoint, >>>> or an OAuth token specifically for the introspection endpoint. If we d= o >>>> standardize on one MTI form, I'd suggest that we make it the OAuth >>>> bearer token. >>>>=20 >>>>> * SHOULDs >>>>>=20 >>>>> This is my usual comment that any SHOULD statement should give the >>>>> reader enough information about the trade-off decision he has to make= . >>>>> When should he implement something and when should he skip it? >>>>=20 >>>> Noted, thanks. >>>>=20 >>>>> * Minor items >>>>>=20 >>>>> You write: >>>>>=20 >>>>> " >>>>> These include using >>>>> structured token formats such as JWT [JWT] or SAML [[ Editor's Not= e: >>>>> Which SAML document should we reference here? ]] and proprietary >>>>> inter-service communication mechanisms (such as shared databases a= nd >>>>> protected enterprise service buses) that convey token information. >>>>> " >>>>>=20 >>>>> Just reference the JWT since that's what we standardize. >>>>=20 >>>> I'm fine with that, didn't want to offend the SAML cabal but we can cu= t it. >>>>=20 >>>>> * 'Active' claim >>>>>=20 >>>>> you write: >>>>> " >>>>> active REQUIRED. Boolean indicator of whether or not the present= ed >>>>> token is currently active. The authorization server determines >>>>> whether and when a given token is in an active state. >>>>> " >>>>>=20 >>>>> Wouldn't it make more sense to return an error rather than saying tha= t >>>>> this token is not active. >>>>=20 >>>> It's not an error, really. It's a valid request and valid response >>>> saying that token isn't any good. It would be easy enough to change th= e >>>> returned error code on the {active:false} response, but to which code? >>>> The request isn't Forbidden, or Not Found (the token could have been >>>> found but it's been deactivated or just not available to the RS that's >>>> asking for it), or Unauthorized, or even a Bad Request. So my logic is >>>> that the response is "OK", but the content of the response tells you t= he >>>> metadata about the token, which is that it's not active. >>>>=20 >>>>> * Capitalization >>>>>=20 >>>>> Reading through the text I see bearer token/Bearer Token, Client/clie= nt, >>>>> etc. issue. >>>>=20 >>>> Thanks, still breaking old Bad Habits of capitalizing Terms In The >>>> Document. Tried to clean it up, will do more. >>>>=20 >>>>> * AS <-> RS relationship >>>>>=20 >>>>> You write: >>>>> " >>>>> Since >>>>> OAuth 2.0 [RFC6749] defines no direct relationship between the >>>>> authorization server and the protected resource, only that they mu= st >>>>> have an agreement on the tokens themselves, there have been many >>>>> different approaches to bridging this gap. >>>>> " >>>>>=20 >>>>> I am not sure what you mean by "defines no relationship" between the = AS >>>>> and the RS. Of course, there is a relationship. The AS issues tokens = for >>>>> access for a specific RS. The RS needs to understand the tokens or if= it >>>>> does not understand them it needs to know which AS to interact with t= o >>>>> learn about the content. >>>>>=20 >>>>> In a nutshell, I am not sure what you want to say with this paragraph >>>>> particularly since you state that they have to have an agreement abou= t >>>>> the tokens. >>>>=20 >>>> What I was trying to point out is that it doesn't define the nature of >>>> the relationship between the two components. Specifically, it says: >>>>=20 >>>> The methods used by the resource >>>> server to validate the access token (as well as any error responses= ) >>>> are beyond the scope of this specification but generally involve an >>>> interaction or coordination between the resource server and the >>>> authorization server. >>>>=20 >>>> This spec provides one mechanism for this validation. So we could >>>> reference this directly if that's helpful. >>>>=20 >>>> -- Justin >>>>=20 >>>>>=20 >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=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 >>=20 From nobody Tue Dec 2 08:09:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849C61A1BBC for ; Tue, 2 Dec 2014 08:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8G_e2b5FFBX for ; Tue, 2 Dec 2014 08:08:58 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CBA1A0173 for ; Tue, 2 Dec 2014 08:08:58 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so1227197lbj.8 for ; Tue, 02 Dec 2014 08:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=kfzgb+s7QC/lNuV+JRGbPTUTmLp86KhrH6jlr0hug0Y=; b=YjHjkR8l/f2vn6tDPaz0adJlyjxKknbiCz630yKZX/mfcCsGBjFq4hzOmdCOs43h0i T4ZgzRzU9TJChOS9BuYmDxkkxUMQk2StRcQqJS21To0+B1sVfk/0PTSGfc3XgX0Ze8wf 3fhdvo8j9Wwe80IPigALfcQRgE+mq3neJzziCD8gwv185osw5uUAby/yR7YGQqtH7X1c HevAWuhK4Dq3cBVZDDrr4BgDTdrHcWM5bJKad3TW8fRQV8MwVcS3rzDGaB/91774eV53 +QCj9tLuCo1NOi41rbnKmwHffX9HjolidRA2qkgeEe1LZo1Y2Gj2+WtM2VW9Xaj5U3+e GwiQ== X-Received: by 10.152.238.1 with SMTP id vg1mr22541388lac.83.1417536536580; Tue, 02 Dec 2014 08:08:56 -0800 (PST) MIME-Version: 1.0 From: Thomas Broyer Date: Tue, 02 Dec 2014 16:08:55 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1134930eb8186305093df125 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/V316eNNZ9vztGQWW4f8IiLg9dt0 Subject: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:09:03 -0000 --001a1134930eb8186305093df125 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Here are some notes about draft-ietf-oauth-introspection-01. Background: I have implemented and deployed -00 (actually that was some version of the individual draft, before it got adopted by the WG), currently with only a couple "clients" (out of 20 or so OAuth 2.0 clients currently, only a couple expose resources themselves and thus need the introspection endpoint; we otherwise have many resources exposed by the same piece of software as the AS so they use internal means of validating the token without the need for the introspection endpoint). resource_id OPTIONAL. A service-specific string identifying the resource that the token is being used for. This value allows the protected resource to convey to the authorization server the context in which the token is being used at the protected resource, allowing the authorization server to tailor its response accordingly if desired. I think it should be noted somewhere that it's totally OK for the introspection endpoint to tailor the response to the resource server making the request too, independently of whether there's a resource_id or not. With "tailoring the response" meaning that it could return active:false even if the token is active but the AS doesn't want the RS to know about it (because, for example, it knows that the token doesn't grant any scope that the RS accepts, and therefore couldn't be used at the RS), or limiting the returned list of scopes to the ones the AS knows the RS handles. As far as resource_id is concerned, I really think an example would make things clearer (what kind of value could be used in a real scenario, etc. = =E2=80=93 there's been a mail earlier today assuming it would be a URL, which I assume to mean the URL of the resource that received the token and needs to introspect it to allow access or not; my interpretation of the draft initially was that it would rather be identifiers as can be seen for scopes, or a resource-set ID < https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03> ) The methods of managing and validating these authentication credentials are out of scope of this specification, though it is RECOMMENDED that these credentials be distinct from those used at an authorization server's token endpoint. and later in the Security Considerations section: The authorization server SHOULD issue credentials to any protected resources that need to access the introspection endpoint, SHOULD require protected resources to be specifically authorized to call the introspection endpoint, and SHOULD NOT allow a single piece of software acting as both a client and a protected resource to re- use the same credentials between the token endpoint and the introspection endpoint. Could you expand on the RECOMMENDED and SHOULD NOT here? What would be the problem with using the same credentials? What's the trade-off? The response MAY be cached by the protected resource, and the authorization server SHOULD communicate appropriate cache controls using applicable HTTP headers. Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf.org/html/rfc7231), it's not clear to me how cache headers would really help, given that the requests to the introspection endpoint are mostly using the POST method ("optionally" a GET method, and the Security Considerations section somehow discourages it). You'd want to check with the HTTPWG but maybe this text should define what the cache-key would be (it would at least include the token and resource_id if provided, maybe also the token_type_hint), and that the response SHOULD NOT have Cache-Control:public or even s-maxage (for the same reason that it should be protected by authentication). I'd actually rather say that the RS may cache the response (we're talking about an "application-level cache" here, not an HTTP cache), and probably should do it for a small amount of time; and possibly (not sure how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) if it somehow detects that the RS doesn't use a (application-level) cache (e.g. asks many times for the same token in a very short time frame). This is the kind of things I could very well add to my implementation later on if we ever see a very high number of requests on our introspection endpoint (because looking up a key-value store using the token as key is much faster than validating the token =E2=80=93 our tokens are base64url-encoded JSON structures contai= ning an ID and a salt, and we store the ID and a hash in our datastore; validating a token thus involves decoding base64url, parsing JSON and computing a hash, in addition to looking it up in the datastore and validating "iat" and "exp"). If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and its credentials are invalid, the authorization server responds with an HTTP 400 (Bad Request) as described in section 5.2 of OAuth 2.0 [RFC6749 ]. Either I don't understand what "OAuth 2.0 client credentials" actually means, or that section should mention HTTP 401 (Unauthorized). (we use HTTP Basic auth FWIW so, per the HTTP spec, we return a 401 for bad credentials). If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint and the token used for authorization does not contain sufficient privileges or is otherwise invalid for this request, the authorization server responds with an HTTP 400 code as described in section 3 of OAuth 2.0 Bearer Token Usage [RFC6750 ]. Same here; unless you use the "Form-Encoded Body Parameter" or "URL Query Parameter" means of sending a Bearer token, the status code would be a 401. BTW, if an introspection endpoint MAY support those means of authenticating a RS, then it should be more clearly stated in the draft that it is allowed and left at the discretion of the implementation. As an implementer, unless I'm told that I could use access_token in the request body, I would assume only the Authorization header is accepted. --001a1134930eb8186305093df125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

Here are some notes about draft-ietf-oauth-introspec= tion-01.
Background: I have implemented and deployed -00 (actuall= y that was some version of the individual draft, before it got adopted by t= he WG), currently with only a couple "clients" (out of 20 or so O= Auth 2.0 clients currently, only a couple expose resources themselves and t= hus need the introspection endpoint; we otherwise have many resources expos= ed by the same piece of software as the AS so they use internal means of va= lidating the token without the need for the introspection endpoint).
<= div>
   resource_id =
 OPTIONAL.  A service-specific string identifying the
      resource that the token is being used for.  This value allows the

      protected resource to =
convey to the authorization server the
      context in which the token is being used at the protected
      resource, allowing the authorization server to tailor its response
      accordingly if desired.

I think it should be noted somewhere that it's totally OK fo= r the introspection endpoint to tailor the response to the resource server = making the request too, independently of whether there's a resource_id = or not. With "tailoring the response" meaning that it could retur= n active:false even if the token is active but the AS doesn't want the = RS to know about it (because, for example, it knows that the token doesn= 9;t grant any scope that the RS accepts, and therefore couldn't be used= at the RS), or limiting the returned list of scopes to the ones the AS kno= ws the RS handles.

As far as resource_id is concer= ned, I really think an example would make things clearer (what kind of valu= e could be used in a real scenario, etc. =E2=80=93 there's been a mail = earlier today assuming it would be a URL, which I assume to mean the URL of= the resource that received the token and needs to introspect it to allow a= ccess or not; my interpretation of the draft initially was that it would ra= ther be identifiers as can be seen for scopes, or a resource-set ID <h= ttps://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03> )

   The met=
hods of managing and
   validating these authentication credentials are out of scope of this
   specification, though it is RECOMMENDED that these credentials be
   distinct from those used at an authorization server's token endpoint=
.

and later in the Security Considerations s= ection:

 =
  The authorization server SHOULD issue credentials to any
   protected resources that need to access the introspection endpoint,
   SHOULD require protected resources to be specifically authorized to
   call the introspection endpoint, and SHOULD NOT allow a single piece
   of software acting as both a client and a protected resource to re-
   use the same credentials between the token endpoint and the
   introspection endpoint.

Could you expand = on the RECOMMENDED and SHOULD NOT here?
What would be the problem= with using the same credentials? What's the trade-off?

<= /div>
   The response MAY be c=
ached by the protected resource, and the
   authorization server SHOULD communicate appropriate cache controls
   using applicable HTTP headers.

Reading through https://tools.ietf.org/html/rfc7234 (and=C2=A0https://tools.ietf.org/html/rfc= 7231), it's not clear to me how cache headers would really help, gi= ven that the requests to the introspection endpoint are mostly using the PO= ST method ("optionally" a GET method, and the Security Considerat= ions section somehow discourages it).
You'd want to check= with the HTTPWG but maybe this text should define what the cache-key would= be (it would at least include the token and resource_id if provided, maybe= also the token_type_hint), and that the response SHOULD NOT have Cache-Con= trol:public=C2=A0or even s-maxage=C2=A0(for the same reason that it should = be protected by authentication).
I'd actually rather say that= the RS may cache the response (we're talking about an "applicatio= n-level cache" here, not an HTTP cache), and probably should do it for= a small amount of time; and possibly (not sure how well that would fit her= e) hint that the AS could very well return an HTTP 429 (Too Many Requests) = <https://tools.ietf.org/= html/rfc6585> if it somehow detects that the RS doesn't use a (a= pplication-level) cache (e.g. asks many times for the same token in a very = short time frame). This is the kind of things I could very well add to my i= mplementation later on if we ever see a very high number of requests on our= introspection endpoint (because looking up a key-value store using the tok= en as key is much faster than validating the token =E2=80=93 our tokens are= base64url-encoded JSON structures containing an ID and a salt, and we stor= e the ID and a hash in our datastore; validating a token thus involves deco= ding base64url, parsing JSON and computing a hash, in addition to looking i= t up in the datastore and validating "iat" and "exp").<= /div>

   If the=
 protected resource uses OAuth 2.0 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 400 (Bad
   Request) as described in section 5.2 of OAuth 2.0 [RFC6749].

Eit= her I don't understand what "OAuth 2.0 client credentials" ac= tually means, or that section should mention HTTP 401 (Unauthorized).
=
(we use HTTP Basic auth FWIW so, per the HTTP spec, we return a 401 fo= r bad credentials).

   If the protected resource uses an OAuth 2.0 bearer token to=
 authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 400 code as described in section 3 of OAuth 2.0 Bearer=
 Token
   Usage [RFC6750]=
.

Same here; unless you use the "Form-E= ncoded Body Parameter" or "URL Query Parameter" means of sen= ding a Bearer token, the status code would be a 401.
BTW, if an i= ntrospection endpoint MAY support those means of authenticating a RS, then = it should be more clearly stated in the draft that it is allowed and left a= t the discretion of the implementation. As an implementer, unless I'm t= old that I could use access_token in the request body, I would assume only = the Authorization header is accepted.
--001a1134930eb8186305093df125-- From nobody Tue Dec 2 09:26:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EC81A1AC2 for ; Tue, 2 Dec 2014 09:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbIUYBJvIPfP for ; Tue, 2 Dec 2014 09:26:29 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id ED29B1A1AA7 for ; Tue, 2 Dec 2014 09:26:28 -0800 (PST) Received: (qmail 10999 invoked by uid 0); 2 Dec 2014 17:26:26 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Dec 2014 17:26:26 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by CMOut01 with id NhRA1p00q2is6CS01hRD6A; Tue, 02 Dec 2014 10:25:20 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=VhNdJee_-yMA:10 a=A92cGCtB03wA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=48vgC7mUAAAA:8 a=I-C8zVDJWD_yYzYPffwA:9 a=LWx-tz-gColGHLNp:21 a=2Z_ZDOFO0-MVnVUL:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=oCt1YX_fvOoVosvtS9wA:9 a=IA1iPV8e2arQF41Y:21 a=12fB01cbRMvOb_SE:21 a=zziI6axrhR7o2urV:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=U8n+DLZJAXNNLDj1m4pZyISKoplAsf9KwYe196jRKc4=; b=lbynRbe1KRbFsAje5IyKG1RRDdJ9xBdDHAYkqfV9AVeLaDN6dlL3FFu2GRAbjGBuike+0M91vH+I9+V0L+EN/gKRyfWc9svE3pLzuSheZoJoV5tG2L7zJXQ/+en5MBDu; Received: from [72.194.76.57] (port=52907 helo=HPLaptop) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XvrCI-0003wn-0o; Tue, 02 Dec 2014 10:25:10 -0700 From: "Donald Coffin" To: "'Justin Richer'" , "'Hannes Tschofenig'" , References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> In-Reply-To: <547DC736.5070609@mit.edu> Date: Tue, 2 Dec 2014 09:25:14 -0800 Organization: REMI Networks Message-ID: <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01D00E11.E27D9BE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKGGpy4MgmEfHmE8Q3UIvvG5HsInALnUkxomvk4bsA= Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 72.194.76.57 authed with donald.coffin@reminetworks.com} Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PrtBJBImNjWsiNEt7HZEcoJZWsM Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:26:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0092_01D00E11.E27D9BE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Justin, I believe you will find the answer to which HTTP Status code the AS should return if the token is INACTIVE in Section 3.1 Error Codes of "The OAuth 2.0 Framework: Bearer Token Usage" [RFC6750] which states: 3.1. Error Codes When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code. invalid_token The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource. If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information. For example: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mit.edu] Sent: Tuesday, December 2, 2014 6:06 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted, will add. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wouldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted, thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_0092_01D00E11.E27D9BE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Justin,

 

I believe you will find the answer to which HTTP Status code the AS = should return if the token is INACTIVE in Section 3.1 Error Codes of = “The OAuth 2.0 Framework: Bearer Token Usage” [RFC6750] = which states:

 

3.1.  Error Codes

When a request fails, the resource server responds using the = appropriate HTTP status code (typically, 400, 401, 403, or 405) and = includes one of the following error codes in the = response:

 

invalid_request

The request is missing a required parameter, includes an unsupported = parameter or parameter value, repeats the same parameter, uses more than = one method for including an access token, or is otherwise malformed. The = resource server SHOULD respond with the HTTP 400 (Bad Request) status = code.

 

invalid_token

The access token provided is expired, revoked, malformed, or invalid = for other reasons. The resource SHOULD respond with the HTTP 401 = (Unauthorized) status code. The client MAY request a new access token = and retry the protected resource request.

 

insufficient_scope

The request requires higher privileges than provided by the access = token. The resource server SHOULD respond with the HTTP 403 (Forbidden) = status code and MAY include the scope attribute with the scope necessary = to access the protected resource.

 

If the request lacks any authentication information (e.g., the client = was unaware that authentication is necessary or attempted using an = unsupported authentication method), the resource server SHOULD NOT = include an error code or other error = information.

 

For example:

  HTTP/1.1 401 Unauthorized  WWW-Authenticate: Bearer = realm=3D"example"

 

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA  92688-3836

 

Phone:    =   (949) 636-8571

Email:    =    donald.coffin@reminetworks= .com

 

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Tuesday, = December 2, 2014 6:06 AM
To: Hannes Tschofenig; = oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of = draft-ietf-oauth-introspection-01

 

Hannes, = thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, = Hannes Tschofenig wrote:

Hi =
Justin,
 
I have a few =
remarks regarding version -01 of the token =
introspection
document.
&n=
bsp;
* =
Terminology
 
The token =
introspection protocol is a client-server protocol but =
the
term "client" already has a meaning =
in OAuth. Here the client of the
token =
introspection protocol is actually the resource server. I =
believe
it would make sense to clarify this issue =
in the terminology section or
in the introduction. =
Maybe add a figure (which you could copy =
from
Figure 4 of
=
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.=

 
Maybe you want to call =
these two parties, the introspection client and
the =
introspection server.


I tried to avoid the word "client" for = this very reason. The draft used to say "client or protected = resource" throughout, but in a few years of deployment experience = it's become clear that it's pretty much just protected resources that = need to do introspection so I changed that text throughout. I don't = think that "introspection client" will help here because the = party already has a name from OAuth and we should inherit = it.


* =
Scope
 
I think the =
document needs to be very clear that is only applicable =
to
bearer tokens (and not to PoP tokens). This =
issue was raised at the last
IETF meeting as =
well.


I think the = document should be clear that it *specifies* the mechanism for bearer = tokens, since that's the only OAuth token type that's defined publicly = right now, and that the details for PoP will have to be specified in = another spec -- that's exactly what Appendix C is there for, and if that = can be clearer, please suggest better text.

However, I think it's = very clear how PoP tokens would work. You send the value returned as the = "access_token" in the token endpoint response, which is = effectively the public portion of the PoP token. Just like a bearer = token, this value is passed as-is from the client to the RS and would be = passed as-is from the RS to the AS during introspection. The AS can then = use that to look up the key and return it in an as-yet-unspecified field = so that the RS can validate the request. The RS wouldn't send the = signature or signed portion of the request for the AS to validate -- = that's a bad idea. But these are all details that we can work out in the = PoP-flavored extension. As I noted in the other thread, we'll have to = make a similar extension for Revocation, so I still don't think it makes = sense to hold up this work and wait for PoP to be finished because it's = useful now, as-is.


 
 
* =
Meta-Information
 
You =
have replicated a lot of the claims defined in
h=
ttps://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use =
the entire
registry from =
JWT?
 
If you want to =
create a separate registry (which I wouldn't =
recommend)
then you have to put text into the IANA =
consideration section.


The idea was to inherit JWT's syntax and = semantics, at least on the wire, and add additional fields. It probably = makes sense to just inherit the JWT registry, so we can do = that.


When you =
write:
 
"=

The endpoint MAY allow other parameters to provide further =
context to
the =
query.
"
 =

You could instead write that the token introspection MUST =
ignore any
parameters from the request message it =
does not understand.


Noted, will = add.


Of course, there is =
the question whether any of those would be =
security
critical and hence ignoring them would =
cause problems?!


Anything security critical would be = provider-specific, in which case it wouldn't ignore them. = 


* =
Security
 
The =
requirement for authenticating the party issuing the =
introspection
request to the token introspection =
endpoint is justified in the security
and the =
privacy consideration section. The security threat is that =
an
attacker could use the endpoint to testing for =
tokens. The privacy
threat is that a resource =
server learns about the content of the token,
which =
may contain personal data. I see the former as more dangerous =
than
the latter since a legitimate resource server =
is supposed to learn about
the authorization =
information in the token. An attacker who had =
gotten
hold of tokens will not only learn about the =
content of the token but he
will also be able to =
use it to get access to the protected resource =
itself.
 
In any case, to =
me this sounds like mutual authentication should =
be
mandatory to implement. This is currently not =
the case. On top of that
there is single technique =
mandatory-to-implement outlined either (in
case =
someone wants to use it). That's in general not very helpful =
from
an interoperability point of view. Yet another =
thing to agree on between
the AS and the =
RS.


I had similar = thoughts when putting draft -01 together but didn't want to make a = normative change like that without the WG input. I'm fine with = strengthening this to a MUST, since as far as I'm aware that's how it = works in all existing implementations (can anyone else comment on = this?). I'm less comfortable with making one particular mechanism MTI, = since I know of implementations that use either a special set of = credentials passed just like client credentials to the token endpoint, = or an OAuth token specifically for the introspection endpoint. If we do = standardize on one MTI form, I'd suggest that we make it the OAuth = bearer token.


* =
SHOULDs
 
This is my =
usual comment that any SHOULD statement should give =
the
reader enough information about the trade-off =
decision he has to make.
When should he implement =
something and when should he skip it?


Noted, thanks. = 


* Minor =
items
 
You =
write:
 
"=

These include using
   =
structured token formats such as JWT [JWT] or SAML [[ Editor's =
Note:
   Which SAML document should we =
reference here? ]] and proprietary
   =
inter-service communication mechanisms (such as shared databases =
and
   protected enterprise service =
buses) that convey token =
information.
"
 =

Just reference the JWT since that's what we =
standardize.


I'm = fine with that, didn't want to offend the SAML cabal but we can cut = it.


* 'Active' =
claim
 
you =
write:
"
   =
active  REQUIRED.  Boolean indicator of whether or not the =
presented
      token is =
currently active.  The authorization server =
determines
      whether =
and when a given token is in an active =
state.
"
 =

Wouldn't it make more sense to return an error rather than =
saying that
this token is not =
active.


It's not = an error, really. It's a valid request and valid response saying that = token isn't any good. It would be easy enough to change the returned = error code on the {active:false} response, but to which code? The = request isn't Forbidden, or Not Found (the token could have been found = but it's been deactivated or just not available to the RS that's asking = for it), or Unauthorized, or even a Bad Request. So my logic is that the = response is "OK", but the content of the response tells you = the metadata about the token, which is that it's not active. = 


* =
Capitalization
 
Reading =
through the text I see bearer token/Bearer Token, =
Client/client,
etc. =
issue.


Thanks, = still breaking old Bad Habits of capitalizing Terms In The Document. = Tried to clean it up, will do = more.


* AS <-> RS =
relationship
 
You =
write:
"
   =
Since
   OAuth 2.0 [RFC6749] defines no =
direct relationship between the
   =
authorization server and the protected resource, only that they =
must
   have an agreement on the tokens =
themselves, there have been many
   =
different approaches to bridging this =
gap.
"
 
I am not sure what you mean by "defines no =
relationship" between the AS
and the RS. Of =
course, there is a relationship. The AS issues tokens =
for
access for a specific RS. The RS needs to =
understand the tokens or if it
does not understand =
them it needs to know which AS to interact with =
to
learn about the =
content.
 
In a nutshell, =
I am not sure what you want to say with this =
paragraph
particularly since you state that they =
have to have an agreement about
the =
tokens.


What I was trying to point out is = that it doesn't define the nature of the relationship between the two = components. Specifically, it says:

   The =
methods used by the resource
   server to =
validate the access token (as well as any error =
responses)
   are beyond the scope of =
this specification but generally involve =
an
   interaction or coordination between =
the resource server and the
   =
authorization server.

This spec = provides one mechanism for this validation. So we could reference this = directly if that's helpful.

  -- = Justin


 
 
 
Ciao<=
/o:p>
Hannes
 



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

 

------=_NextPart_000_0092_01D00E11.E27D9BE0-- From nobody Tue Dec 2 09:34:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B671A1DE2 for ; Tue, 2 Dec 2014 09:34:11 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gznaHLl6uhPM for ; Tue, 2 Dec 2014 09:34:03 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84301A1BF8 for ; Tue, 2 Dec 2014 09:34:02 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so10899123lbi.18 for ; Tue, 02 Dec 2014 09:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=6xubfpdyA5bMEr0LiBJ1Imw7VoPoMyRsrxzYrxeB1k4=; b=D86rBwx0FxxRnfTJCdMEsSGAEjc9vKdVuz6WhAwlvPGGRB5UzEM17CAr/y+TVVHpnw UkVfuBEPgYSMlXVztKumkx5+HZiyD88jP3Ir1qBHJz3JkCTRFppPqZyZdGcuQ2JhNkHG q6zm8efsH5HG2TSv8foR8n2deZy7gbhgRhUMkLB/b2OWxY5UHI9mqlYKw+vq29nyUx0v EpTLrzgSh11GRVa7nlmbhjmTg4B7eaNLyPItUnQtN0jIz4UoHfwIyjMZPKfRha9cA2RG i9B/FhzCaO5+WOQawpLh7Pe1oyJALQnpz9pouQ/HD92UlG2W29w0Aug7JFDJWyoKDVfw Y2Uw== X-Received: by 10.152.115.230 with SMTP id jr6mr479858lab.2.1417541632371; Tue, 02 Dec 2014 09:33:52 -0800 (PST) MIME-Version: 1.0 References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> From: Thomas Broyer Date: Tue, 02 Dec 2014 17:33:51 +0000 Message-ID: To: Donald Coffin , Justin Richer , Hannes Tschofenig , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c3674273b3a205093f21d7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wj415Kk3xvVxKvEM6i5nHhOg5Zk Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:34:11 -0000 --001a11c3674273b3a205093f21d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So what? The request is OK (no missing parameter, etc.) so a 400 is not appropriate (it could still be used, but you couldn't tell what went wrong without *also* having some well-defined error response document format; and an "invalid_token" error code wouldn't work if you're also using token authentication passed in the form-encoded body =E2=87=92 too much confusion= , not worth it). 401 or 403 are obviously not appropriate either. I'm +1000 on keeping the 200 OK response with {"active":false} JSON response. On Tue Dec 02 2014 at 18:27:03 Donald Coffin wrote: > Hi Justin, > > > > I believe you will find the answer to which HTTP Status code the AS shoul= d > return if the token is INACTIVE in Section 3.1 Error Codes of =E2=80=9CTh= e OAuth > 2.0 Framework: Bearer Token Usage=E2=80=9D [RFC6750] which states: > > > > 3.1. Error Codes > > When a request fails, the resource server responds using the appropriate > HTTP status code (typically, 400, 401, 403, or 405) and includes one of t= he > following error codes in the response: > > > > *invalid_request* > > The request is missing a required parameter, includes an unsupported > parameter or parameter value, repeats the same parameter, uses more than > one method for including an access token, or is otherwise malformed. The > resource server SHOULD respond with the HTTP 400 (Bad Request) status cod= e. > > > > *invalid_token* > > The access token provided is expired, revoked, malformed, or invalid for > other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorize= d) > status code. The client MAY request a new access token and retry the > protected resource request. > > > > *insufficient_scope* > > The request requires higher privileges than provided by the access token. > The resource server SHOULD respond with the HTTP 403 (Forbidden) status > code and MAY include the scope attribute with the scope necessary to acce= ss > the protected resource. > > > > If the request lacks any authentication information (e.g., the client was > unaware that authentication is necessary or attempted using an unsupporte= d > authentication method), the resource server SHOULD NOT include an error > code or other error information. > > > > For example: > > HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example" > > > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 22751 El Prado Suite 6216 > > Rancho Santa Margarita, CA 92688-3836 > > > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > > > *From:* Justin Richer [mailto:jricher@mit.edu] > *Sent:* Tuesday, December 2, 2014 6:06 AM > *To:* Hannes Tschofenig; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > > > > Hannes, thanks for the review. Comments inline. > > On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: > > Hi Justin, > > > > I have a few remarks regarding version -01 of the token introspection > > document. > > > > * Terminology > > > > The token introspection protocol is a client-server protocol but the > > term "client" already has a meaning in OAuth. Here the client of the > > token introspection protocol is actually the resource server. I believe > > it would make sense to clarify this issue in the terminology section or > > in the introduction. Maybe add a figure (which you could copy from > > Figure 4 of > > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > > > Maybe you want to call these two parties, the introspection client and > > the introspection server. > > > I tried to avoid the word "client" for this very reason. The draft used t= o > say "client or protected resource" throughout, but in a few years of > deployment experience it's become clear that it's pretty much just > protected resources that need to do introspection so I changed that text > throughout. I don't think that "introspection client" will help here > because the party already has a name from OAuth and we should inherit it. > > > * Scope > > > > I think the document needs to be very clear that is only applicable to > > bearer tokens (and not to PoP tokens). This issue was raised at the last > > IETF meeting as well. > > > I think the document should be clear that it *specifies* the mechanism fo= r > bearer tokens, since that's the only OAuth token type that's defined > publicly right now, and that the details for PoP will have to be specifie= d > in another spec -- that's exactly what Appendix C is there for, and if th= at > can be clearer, please suggest better text. > > However, I think it's very clear how PoP tokens would work. You send the > value returned as the "access_token" in the token endpoint response, whic= h > is effectively the public portion of the PoP token. Just like a bearer > token, this value is passed as-is from the client to the RS and would be > passed as-is from the RS to the AS during introspection. The AS can then > use that to look up the key and return it in an as-yet-unspecified field = so > that the RS can validate the request. The RS wouldn't send the signature = or > signed portion of the request for the AS to validate -- that's a bad idea= . > But these are all details that we can work out in the PoP-flavored > extension. As I noted in the other thread, we'll have to make a similar > extension for Revocation, so I still don't think it makes sense to hold u= p > this work and wait for PoP to be finished because it's useful now, as-is. > > > > > > > * Meta-Information > > > > You have replicated a lot of the claims defined in > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > > and I am wondering why you have decided to not just re-use the entire > > registry from JWT? > > > > If you want to create a separate registry (which I wouldn't recommend) > > then you have to put text into the IANA consideration section. > > > The idea was to inherit JWT's syntax and semantics, at least on the wire, > and add additional fields. It probably makes sense to just inherit the JW= T > registry, so we can do that. > > > When you write: > > > > " > > The endpoint MAY allow other parameters to provide further context to > > the query. > > " > > > > You could instead write that the token introspection MUST ignore any > > parameters from the request message it does not understand. > > > Noted, will add. > > > Of course, there is the question whether any of those would be security > > critical and hence ignoring them would cause problems?! > > > Anything security critical would be provider-specific, in which case it > wouldn't ignore them. > > > * Security > > > > The requirement for authenticating the party issuing the introspection > > request to the token introspection endpoint is justified in the security > > and the privacy consideration section. The security threat is that an > > attacker could use the endpoint to testing for tokens. The privacy > > threat is that a resource server learns about the content of the token, > > which may contain personal data. I see the former as more dangerous than > > the latter since a legitimate resource server is supposed to learn about > > the authorization information in the token. An attacker who had gotten > > hold of tokens will not only learn about the content of the token but he > > will also be able to use it to get access to the protected resource itsel= f. > > > > In any case, to me this sounds like mutual authentication should be > > mandatory to implement. This is currently not the case. On top of that > > there is single technique mandatory-to-implement outlined either (in > > case someone wants to use it). That's in general not very helpful from > > an interoperability point of view. Yet another thing to agree on between > > the AS and the RS. > > > I had similar thoughts when putting draft -01 together but didn't want to > make a normative change like that without the WG input. I'm fine with > strengthening this to a MUST, since as far as I'm aware that's how it wor= ks > in all existing implementations (can anyone else comment on this?). I'm > less comfortable with making one particular mechanism MTI, since I know o= f > implementations that use either a special set of credentials passed just > like client credentials to the token endpoint, or an OAuth token > specifically for the introspection endpoint. If we do standardize on one > MTI form, I'd suggest that we make it the OAuth bearer token. > > > * SHOULDs > > > > This is my usual comment that any SHOULD statement should give the > > reader enough information about the trade-off decision he has to make. > > When should he implement something and when should he skip it? > > > Noted, thanks. > > > * Minor items > > > > You write: > > > > " > > These include using > > structured token formats such as JWT [JWT] or SAML [[ Editor's Note: > > Which SAML document should we reference here? ]] and proprietary > > inter-service communication mechanisms (such as shared databases and > > protected enterprise service buses) that convey token information. > > " > > > > Just reference the JWT since that's what we standardize. > > > I'm fine with that, didn't want to offend the SAML cabal but we can cut i= t. > > > * 'Active' claim > > > > you write: > > " > > active REQUIRED. Boolean indicator of whether or not the presented > > token is currently active. The authorization server determines > > whether and when a given token is in an active state. > > " > > > > Wouldn't it make more sense to return an error rather than saying that > > this token is not active. > > > It's not an error, really. It's a valid request and valid response saying > that token isn't any good. It would be easy enough to change the returned > error code on the {active:false} response, but to which code? The request > isn't Forbidden, or Not Found (the token could have been found but it's > been deactivated or just not available to the RS that's asking for it), o= r > Unauthorized, or even a Bad Request. So my logic is that the response is > "OK", but the content of the response tells you the metadata about the > token, which is that it's not active. > > > * Capitalization > > > > Reading through the text I see bearer token/Bearer Token, Client/client, > > etc. issue. > > > Thanks, still breaking old Bad Habits of capitalizing Terms In The > Document. Tried to clean it up, will do more. > > > * AS <-> RS relationship > > > > You write: > > " > > Since > > OAuth 2.0 [RFC6749] defines no direct relationship between the > > authorization server and the protected resource, only that they must > > have an agreement on the tokens themselves, there have been many > > different approaches to bridging this gap. > > " > > > > I am not sure what you mean by "defines no relationship" between the AS > > and the RS. Of course, there is a relationship. The AS issues tokens for > > access for a specific RS. The RS needs to understand the tokens or if it > > does not understand them it needs to know which AS to interact with to > > learn about the content. > > > > In a nutshell, I am not sure what you want to say with this paragraph > > particularly since you state that they have to have an agreement about > > the tokens. > > > What I was trying to point out is that it doesn't define the nature of th= e > relationship between the two components. Specifically, it says: > > The methods used by the resource > > server to validate the access token (as well as any error responses) > > are beyond the scope of this specification but generally involve an > > interaction or coordination between the resource server and the > > authorization server. > > This spec provides one mechanism for this validation. So we could > reference this directly if that's helpful. > > -- Justin > > > > > > > > > Ciao > > Hannes > > > > > > > _______________________________________________ > > 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 > --001a11c3674273b3a205093f21d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So what?

The request is OK (no missing parameter, etc.) so a 40= 0 is not appropriate (it could still be used, but you couldn't tell wha= t went wrong without *also* having some well-defined error response documen= t format; and an "invalid_token" error code wouldn't work if = you're also using token authentication passed in the form-encoded body = =E2=87=92 too much confusion, not worth it).

401 o= r 403 are obviously not appropriate either.

I'= m=C2=A0+1000 on keeping the 200 OK response with {"active":false}= JSON response.

On Tue Dec 02 2014 at 1= 8:27:03 Donald Coffin <donald.coffin@reminetworks.com> wrote:
=

Hi Justin,<= /p>

=C2=A0

I believe you will find the answer to wh= ich HTTP Status code the AS should return if the token is INACTIVE in Secti= on 3.1 Error Codes of =E2=80=9CThe OAuth 2.0 Framework: Bearer Token Usage= =E2=80=9D [RFC6750] which states:

=C2=A0

3.1.=C2=A0 Error Codes=

When a request fails, the resource server responds using the appropri= ate HTTP status code (typically, 400, 401, 403, or 405) and includes one of= the following error codes in the response:

=C2=A0=

invalid_request

The requ= est is missing a required parameter, includes an unsupported parameter or p= arameter value, repeats the same parameter, uses more than one method for i= ncluding an access token, or is otherwise malformed. The resource server SH= OULD respond with the HTTP 400 (Bad Request) status code.

=C2=A0

invalid_token

The access token provided is expired, revoked, malformed, or invalid fo= r other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorize= d) status code. The client MAY request a new access token and retry the pro= tected resource request.

=C2=A0

insuffici= ent_scope

The request requires hi= gher privileges than provided by the access token. The resource server SHOU= LD respond with the HTTP 403 (Forbidden) status code and MAY include the sc= ope attribute with the scope necessary to access the protected resource.=

=C2=A0

If the request lacks any authentication = information (e.g., the client was unaware that authentication is necessary = or attempted using an unsupported authentication method), the resource serv= er SHOULD NOT include an error code or other error information.

=C2=A0

For example:

=C2=A0 HTTP/1.1 401 U= nauthorized=C2=A0 WWW-Authenticate: Bearer realm=3D"example"

=C2=A0

=C2=A0

Best regards,

Don

Donald F. Coffin

Founder/CTO=

=C2=A0=

REMI Networks

22751 El Pr= ado Suite 6216

Rancho Santa Margarit= a, CA=C2=A0 92688-3836

=C2=A0=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949)= 636-8571

Email:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=

=C2=A0=

From: Justin Richer [mailto:jricher@mit.edu]
Sent: T= uesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; oauth@ietf.org
Subje= ct: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

=C2=A0=

Hannes, thanks for the review. Comme= nts inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:=

Hi Justin,
=C2=A0
I have=
 a few remarks regarding version -01 of the token introspection
document.
=C2=A0
* Terminology
=C2=A0
The=
 token introspection protocol is a client-server protocol but the=

term "client" already has a meaning in OAuth. Here=
 the client of the
token introspection protocol is =
actually the resource server. I believe
it would ma=
ke sense to clarify this issue in the terminology section or<=
/pre>
in the introduction. Maybe add a figure (which you could copy fro=
m
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.<=
u>
=C2=A0
Maybe you want to ca=
ll these two parties, the introspection client and
=
the introspection server.


I tried to avoid the word "client" for this very reason= . The draft used to say "client or protected resource" throughout= , but in a few years of deployment experience it's become clear that it= 's pretty much just protected resources that need to do introspection s= o I changed that text throughout. I don't think that "introspectio= n client" will help here because the party already has a name from OAu= th and we should inherit it.


* Scope
<= pre>=C2=A0
I think the document needs to be very cl=
ear that is only applicable to
bearer tokens (and n=
ot to PoP tokens). This issue was raised at the last
IETF meeting as well.


I think the document should be clear that it *specifies* the mechan= ism for bearer tokens, since that's the only OAuth token type that'= s defined publicly right now, and that the details for PoP will have to be = specified in another spec -- that's exactly what Appendix C is there fo= r, and if that can be clearer, please suggest better text.

However, = I think it's very clear how PoP tokens would work. You send the value r= eturned as the "access_token" in the token endpoint response, whi= ch is effectively the public portion of the PoP token. Just like a bearer t= oken, this value is passed as-is from the client to the RS and would be pas= sed as-is from the RS to the AS during introspection. The AS can then use t= hat to look up the key and return it in an as-yet-unspecified field so that= the RS can validate the request. The RS wouldn't send the signature or= signed portion of the request for the AS to validate -- that's a bad i= dea. But these are all details that we can work out in the PoP-flavored ext= ension. As I noted in the other thread, we'll have to make a similar ex= tension for Revocation, so I still don't think it makes sense to hold u= p this work and wait for PoP to be finished because it's useful now, as= -is.


=C2=A0
=C2=A0<=
/pre>
* Meta-Information
=C2=A0
You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-jso=
n-web-token-31
and I am wondering why you have =
decided to not just re-use the entire
registry from=
 JWT?
=C2=A0
If you want to=
 create a separate registry (which I wouldn't recommend)<=
/pre>
then you have to put text into the IANA consideration section.=


The idea was to in= herit JWT's syntax and semantics, at least on the wire, and add additio= nal fields. It probably makes sense to just inherit the JWT registry, so we= can do that.


When you write:
=
=C2=A0
"
The endpoint MAY=
 allow other parameters to provide further context to
the query.
"
=C2=A0
You could instead write that the token introspecti=
on MUST ignore any
parameters from the request mess=
age it does not understand.


Noted, will add.


Of course, there is the ques=
tion whether any of those would be security
critica=
l and hence ignoring them would cause problems?!


Anything security critical would be provid= er-specific, in which case it wouldn't ignore them.


= 

=
* Security
=C2=A0
The requi=
rement for authenticating the party issuing the introspection=

request to the token introspection endpoint is justified in the =
security
and the privacy consideration section. The=
 security threat is that an
attacker could use the =
endpoint to testing for tokens. The privacy
threat =
is that a resource server learns about the content of the token,<=
/u>
which may contain personal data. I see the former as more dan=
gerous than
the latter since a legitimate resource =
server is supposed to learn about
the authorization=
 information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he= 
will also be able to use it to get access to the p=
rotected resource itself.
=C2=A0
In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the ca=
se. On top of that
there is single technique mandat=
ory-to-implement outlined either (in
case someone w=
ants to use it). That's in general not very helpful from<=
/pre>
an interoperability point of view. Yet another thing to agree on =
between
the AS and the RS.

I had similar thoughts when putting draf=
t -01 together but didn't want to make a normative change like that wit=
hout the WG input. I'm fine with strengthening this to a MUST, since as=
 far as I'm aware that's how it works in all existing implementatio=
ns (can anyone else comment on this?). I'm less comfortable with making=
 one particular mechanism MTI, since I know of implementations that use eit=
her a special set of credentials passed just like client credentials to the=
 token endpoint, or an OAuth token specifically for the introspection endpo=
int. If we do standardize on one MTI form, I'd suggest that we make it =
the OAuth bearer token.


* SHOULDs
=C2=A0
This is my usual comment that any SHOULD st=
atement should give the
reader enough information a=
bout the trade-off decision he has to make.
When sh=
ould he implement something and when should he skip it?
=


Noted, thanks.


<= u>

*=
 Minor items
=C2=A0
You wri=
te:
=C2=A0
"=

These include using
=C2=A0=C2=A0 str=
uctured token formats such as JWT [JWT] or SAML [[ Editor's Note:
=C2=A0=C2=A0 Which SAML document should we reference her=
e? ]] and proprietary
=C2=A0=C2=A0 inter-service co=
mmunication mechanisms (such as shared databases and
=C2=A0=C2=A0 protected enterprise service buses) that convey token inform= ation.
"
=C2=A0=

Just reference the JWT since that's what we standardi=
ze.


I'm fine= with that, didn't want to offend the SAML cabal but we can cut it.
= 

* 'Active' claim
=C2=
=A0
you write:
"
=C2=A0=C2=A0 active=C2=A0 REQUIRED.=C2=A0 Boolean indicator of =
whether or not the presented
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 token is currently active.=C2=A0 The authorization server determi=
nes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether and when=
 a given token is in an active state.
"=

=C2=A0
Wouldn't it make more =
sense to return an error rather than saying that
th=
is token is not active.


It's not an error, really. It's a valid request and valid r= esponse saying that token isn't any good. It would be easy enough to ch= ange the returned error code on the {active:false} response, but to which c= ode? The request isn't Forbidden, or Not Found (the token could have be= en found but it's been deactivated or just not available to the RS that= 's asking for it), or Unauthorized, or even a Bad Request. So my logic = is that the response is "OK", but the content of the response tel= ls you the metadata about the token, which is that it's not active. 

* Capitalization
=C2=A0
Reading through the text I see bearer token/Bearer Token, Clie=
nt/client,
etc. issue.


Thanks, still breaking old Bad Habits of cap= italizing Terms In The Document. Tried to clean it up, will do more.

* AS <-> RS relationship
=
=C2=A0
You write:
"=

=C2=A0=C2=A0 Since
=C2=A0=C2=A0 OAut=
h 2.0 [RFC6749] defines no direct relationship between the
=C2=A0=C2=A0 authorization server and the protected resource, only =
that they must
=C2=A0=C2=A0 have an agreement on th=
e tokens themselves, there have been many
=C2=A0=C2=
=A0 different approaches to bridging this gap.
&quo=
t;
=C2=A0
I am not sure wha=
t you mean by "defines no relationship" between the AS<=
/u>
and the RS. Of course, there is a relationship. The AS issues=
 tokens for
access for a specific RS. The RS needs =
to understand the tokens or if it
does not understa=
nd them it needs to know which AS to interact with to
learn about the content.
=C2=A0
In a nutshell, I am not sure what you want to say with this paragra=
ph
particularly since you state that they have to h=
ave an agreement about
the tokens.


W= hat I was trying to point out is that it doesn't define the nature of t= he relationship between the two components. Specifically, it says:

=C2=A0=C2=A0 The methods used by the resource
=C2=A0=C2=A0 server to validate the access token (as well as any e=
rror responses)
=C2=A0=C2=A0 are beyond the scope o=
f this specification but generally involve an
=C2=
=A0=C2=A0 interaction or coordination between the resource server and the
=C2=A0=C2=A0 authorization server.
This spec provides one mechanism for this validati=
on. So we could reference this directly if that's helpful. 

=C2=
=A0 -- Justin


=C2=A0
=C2=
=A0
=C2=A0
Ciao
Hannes
=C2=A0



_____________________________=
__________________
OAuth mailing list=

OAuth@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0<=
/u>
_______________________________________________ OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a11c3674273b3a205093f21d7-- From nobody Tue Dec 2 10:19:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E68C1A1C06 for ; Tue, 2 Dec 2014 10:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egzhr_AM2BYp for ; Tue, 2 Dec 2014 10:19:19 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 616751A0392 for ; Tue, 2 Dec 2014 10:19:19 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1543952E09D; Tue, 2 Dec 2014 13:19:19 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 0562652E09B; Tue, 2 Dec 2014 13:19:19 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 13:19:18 -0500 From: "Richer, Justin P." To: Donald Coffin Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgAA3wACAAA9QAA== Date: Tue, 2 Dec 2014 18:19:17 +0000 Message-ID: <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org> References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> In-Reply-To: <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_506AAEA87D724B148CB6F3F2319ACFFBmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DDW3iX-pXDExu6g81H3KgWjvM10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:19:24 -0000 --_000_506AAEA87D724B148CB6F3F2319ACFFBmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, this isn't an appropriate mapping in this case, especially if the intro= spection endpoint is itself OAuth protected. You need to be able to differe= ntiate between the token being asked about and the token authorizing the qu= estion. These error codes apply to the latter and should not be conflated w= ith the former. -- Justin On Dec 2, 2014, at 12:25 PM, Donald Coffin > wrote: Hi Justin, I believe you will find the answer to which HTTP Status code the AS should = return if the token is INACTIVE in Section 3.1 Error Codes of =93The OAuth = 2.0 Framework: Bearer Token Usage=94 [RFC6750] which states: 3.1. Error Codes When a request fails, the resource server responds using the appropriate HT= TP status code (typically, 400, 401, 403, or 405) and includes one of the f= ollowing error codes in the response: invalid_request The request is missing a required parameter, includes an unsupported parame= ter or parameter value, repeats the same parameter, uses more than one meth= od for including an access token, or is otherwise malformed. The resource s= erver SHOULD respond with the HTTP 400 (Bad Request) status code. invalid_token The access token provided is expired, revoked, malformed, or invalid for ot= her reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) s= tatus code. The client MAY request a new access token and retry the protect= ed resource request. insufficient_scope The request requires higher privileges than provided by the access token. T= he resource server SHOULD respond with the HTTP 403 (Forbidden) status code= and MAY include the scope attribute with the scope necessary to access the= protected resource. If the request lacks any authentication information (e.g., the client was u= naware that authentication is necessary or attempted using an unsupported a= uthentication method), the resource server SHOULD NOT include an error code= or other error information. For example: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example" Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mit.edu] Sent: Tuesday, December 2, 2014 6:06 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to = say "client or protected resource" throughout, but in a few years of deploy= ment experience it's become clear that it's pretty much just protected reso= urces that need to do introspection so I changed that text throughout. I do= n't think that "introspection client" will help here because the party alre= ady has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for = bearer tokens, since that's the only OAuth token type that's defined public= ly right now, and that the details for PoP will have to be specified in ano= ther spec -- that's exactly what Appendix C is there for, and if that can b= e clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the va= lue returned as the "access_token" in the token endpoint response, which is= effectively the public portion of the PoP token. Just like a bearer token,= this value is passed as-is from the client to the RS and would be passed a= s-is from the RS to the AS during introspection. The AS can then use that t= o look up the key and return it in an as-yet-unspecified field so that the = RS can validate the request. The RS wouldn't send the signature or signed p= ortion of the request for the AS to validate -- that's a bad idea. But thes= e are all details that we can work out in the PoP-flavored extension. As I = noted in the other thread, we'll have to make a similar extension for Revoc= ation, so I still don't think it makes sense to hold up this work and wait = for PoP to be finished because it's useful now, as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, a= nd add additional fields. It probably makes sense to just inherit the JWT r= egistry, so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted, will add. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wou= ldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST, since as far as I'm aware that's how it works in al= l existing implementations (can anyone else comment on this?). I'm less com= fortable with making one particular mechanism MTI, since I know of implemen= tations that use either a special set of credentials passed just like clien= t credentials to the token endpoint, or an OAuth token specifically for the= introspection endpoint. If we do standardize on one MTI form, I'd suggest = that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted, thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error, really. It's a valid request and valid response saying t= hat token isn't any good. It would be easy enough to change the returned er= ror code on the {active:false} response, but to which code? The request isn= 't Forbidden, or Not Found (the token could have been found but it's been d= eactivated or just not available to the RS that's asking for it), or Unauth= orized, or even a Bad Request. So my logic is that the response is "OK", bu= t the content of the response tells you the metadata about the token, which= is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document= . Tried to clean it up, will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference= this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ 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 --_000_506AAEA87D724B148CB6F3F2319ACFFBmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7E67127AB4E42141BCADD37133F8A6B5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable No, this isn't an appropriate mapping in this case, especially if the intro= spection endpoint is itself OAuth protected. You need to be able to differe= ntiate between the token being asked about and the token authorizing the qu= estion. These error codes apply to the latter and should not be conflated with the former.

 -- Justin

On Dec 2, 2014, at 12:25 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote:

Hi Justin,

 

I believe you will find the answer to= which HTTP Status code the AS should return if the token is INACTIVE in Se= ction 3.1 Error Codes of =93The OAuth 2.0 Framework: Bearer Token Usage=94 [RFC6750] which states:

 

3.1. = ; Error Codes

When a re= quest fails, the resource server responds using the appropriate HTTP status= code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response:

 

invali= d_request

The reque= st is missing a required parameter, includes an unsupported parameter or pa= rameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malfor= med. The resource server SHOULD respond with the HTTP 400 (Bad Request) sta= tus code.

 

invali= d_token

The acces= s token provided is expired, revoked, malformed, or invalid for other reaso= ns. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and = retry the protected resource request.

 

insuff= icient_scope

The reque= st requires higher privileges than provided by the access token. The resour= ce server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary t= o access the protected resource.

 

If the re= quest lacks any authentication information (e.g., the client was unaware th= at authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT incl= ude an error code or other error information.

 

For examp= le:

  HT= TP/1.1 401 Unauthorized  WWW-Authenticate: Bearer realm=3D"exampl= e"

 

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com<= /p>

 

From: Justin Richer [mailto:jricher@mit.ed= u]
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; oauth@ietf.= org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01<= o:p>

 

Hannes, thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:

Hi Justin,
 
I have a few remarks regarding version -01 of the token introspection<=
o:p>
document.
 
* Terminology
 
The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the clien=
t of the
token introspection protocol is actually the resource server. I believ=
e
it would make sense to clarify this issue in the terminology section o=
r
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.<=
o:p>
 
Maybe you want to call these two parties, the introspection client and=

the introspection server.


I tried to avoid the word "client" for this very reason. The draf= t used to say "client or protected resource" throughout, but in a= few years of deployment experience it's become clear that it's pretty much= just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection = client" will help here because the party already has a name from OAuth= and we should inherit it.


* Scope
 
I think the document needs to be very clear that is only applicable to=

bearer tokens (and not to PoP tokens). This issue was raised at the la=
st
IETF meeting as well.


I think the document should be clear that it *specifies* the mechanism for = bearer tokens, since that's the only OAuth token type that's defined public= ly right now, and that the details for PoP will have to be specified in ano= ther spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better= text.

However, I think it's very clear how PoP tokens would work. You send the va= lue returned as the "access_token" in the token endpoint response= , which is effectively the public portion of the PoP token. Just like a bea= rer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS durin= g introspection. The AS can then use that to look up the key and return it = in an as-yet-unspecified field so that the RS can validate the request. The= RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad id= ea. But these are all details that we can work out in the PoP-flavored exte= nsion. As I noted in the other thread, we'll have to make a similar extensi= on for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished = because it's useful now, as-is.


 
 
* Meta-Information
 
You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire<=
o:p>
registry from JWT?
 
If you want to create a separate registry (which I wouldn't recommend)=

then you have to put text into the IANA consideration section.


The idea was to inherit JWT's syntax and semantics, at least on the wire, a= nd add additional fields. It probably makes sense to just inherit the JWT r= egistry, so we can do that.


When you write:
 
"
The endpoint MAY allow other parameters to provide further context to<=
o:p>
the query.
"
 
You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.=


Noted, will add.


Of course, there is the question whether any of those would be securit=
y
critical and hence ignoring them would cause problems?!


Anything security critical would be provider-specific, in which case it wou= ldn't ignore them. 


* Security
 
The requirement for authenticating the party issuing the introspection=

request to the token introspection endpoint is justified in the securi=
ty
and the privacy consideration section. The security threat is that an<=
o:p>
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token=
,
which may contain personal data. I see the former as more dangerous th=
an
the latter since a legitimate resource server is supposed to learn abo=
ut
the authorization information in the token. An attacker who had gotten=

hold of tokens will not only learn about the content of the token but =
he
will also be able to use it to get access to the protected resource it=
self.
 
In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that=

there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from=

an interoperability point of view. Yet another thing to agree on betwe=
en
the AS and the RS.


I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST, since as far as I'm aware that's how it works in al= l existing implementations (can anyone else comment on this?). I'm less comfortable with making one partic= ular mechanism MTI, since I know of implementations that use either a speci= al set of credentials passed just like client credentials to the token endp= oint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd = suggest that we make it the OAuth bearer token.


* SHOULDs
 
This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.=

When should he implement something and when should he skip it?


Noted, thanks. 


* Minor items
 
You write:
 
"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Edi=
tor's Note:
   Which SAML document should we reference here? ]] and prop=
rietary
   inter-service communication mechanisms (such as shared da=
tabases and
   protected enterprise service buses) that convey token inf=
ormation.
"
 
Just reference the JWT since that's what we standardize.


I'm fine with that, didn't want to offend the SAML cabal but we can cut it.= 


* 'Active' claim
 
you write:
"
   active  REQUIRED.  Boolean indicator of whether=
 or not the presented
      token is currently active.  The au=
thorization server determines
      whether and when a given token is in an=
 active state.
"
 
Wouldn't it make more sense to return an error rather than saying that=

this token is not active.


It's not an error, really. It's a valid request and valid response saying t= hat token isn't any good. It would be easy enough to change the returned er= ror code on the {active:false} response, but to which code? The request isn= 't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not availabl= e to the RS that's asking for it), or Unauthorized, or even a Bad Request. = So my logic is that the response is "OK", but the content of the = response tells you the metadata about the token, which is that it's not active. 


* Capitalization
 
Reading through the text I see bearer token/Bearer Token, Client/clien=
t,
etc. issue.


Thanks, still breaking old Bad Habits of capitalizing Terms In The Document= . Tried to clean it up, will do more.


* AS <-> RS relationship
 
You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship betwee=
n the
   authorization server and the protected resource, only tha=
t they must
   have an agreement on the tokens themselves, there have be=
en many
   different approaches to bridging this gap.

"


 


I am not sure what you mean by "defines no relationship" bet=
ween the AS


and the RS. Of course, there is a relationship. The AS issues tokens f=
or


access for a specific RS. The RS needs to understand the tokens or if =
it


does not understand them it needs to know which AS to interact with to=



learn about the content.


 


In a nutshell, I am not sure what you want to say with this paragraph<=
o:p>


particularly since you state that they have to have an agreement about=



the tokens.


What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically, it says:<= /p> 

   The methods used by the resource
   server to validate the access token (as well as any error=
 responses)
   are beyond the scope of this specification but generally =
involve an
   interaction or coordination between the resource server a=
nd the
   authorization server.

This spec provides one mechanism for this validation= . So we could reference this directly if that's helpful.

  -- Justin


 
 
 
Ciao
Hannes
 




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

 

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

--_000_506AAEA87D724B148CB6F3F2319ACFFBmitreorg_-- From nobody Tue Dec 2 10:40:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C874F1A6FC5 for ; Tue, 2 Dec 2014 10:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbmvzQznEkYu for ; Tue, 2 Dec 2014 10:40:18 -0800 (PST) Received: from nm47-vm10.bullet.mail.bf1.yahoo.com (nm47-vm10.bullet.mail.bf1.yahoo.com [216.109.114.219]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565EF1A1BD4 for ; Tue, 2 Dec 2014 10:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417545617; bh=DY+DE3qapkN8LYLvMteTE9CaHG9ysIgRhJ61rdVR8z4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Ztf1szk001rKYcyM4OYruPgW+Lo5IoHAnBF07S4kRGcfD44Urrq14kj1anNkb9Pa852xQUh2ZZhX2SnjHuHzrgFvNA3mve0E+yTB72UrXQhe14iZeBdBQZzkEQLXRrA96sMAm5aimzd8IrQdTSKLqjXreSdZAVyecc9NyKxB1lyj0dfPhsEvbGVD+UuDXiptryydghvh+olSd3lzDtKyvaRqObVC+pZLrjNVgW6Mk8Azcx0mHWlsa9L6rP9eOoXtyQPng1WwfSvoecC06AGhoH8hXkiKLOuwiC2f1KL6tllVlKZAR90ujYNTh13zFa1NqbR8t/s6hyPznwFPino6hQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=OEtuBo90465omcKoUsPbxNwodST4ydf9tDbu2CbmDSqhbkVBWnCLsgkedrKHKyTUsmA5g/H5v3YP5lCkyVF1YCwAnSGYAhPdi14lUOSORMRv7Feq14f9b56eH3GZs817fI6iY7/Ml+WxmiIDMEI3DmIrnXzEHMs9E+PvY2n6W9KqG3QkpZk3vyYiO370TaRCyhDCCoZ/jaLcaYgt9jaVjruw/nfsvseEPhbgyu10OAEu9zo5lvUh9X8Gz55cs+XnPr3hAqBtR5viOBZ6KycIlx9X/k4PD9LJ3eHNmoi+x22F8BGIXpi1E2SBha01h3fbRktBVz3bvuYRr/yN6KOf+A==; Received: from [66.196.81.173] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:40:17 -0000 Received: from [98.139.212.193] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:40:17 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:40:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 408939.31893.bm@omp1002.mail.bf1.yahoo.com Received: by 66.196.80.147; Tue, 02 Dec 2014 18:40:16 +0000 Date: Tue, 2 Dec 2014 18:40:16 +0000 (UTC) From: Bill Mills To: Justin Richer , Hannes Tschofenig , "oauth@ietf.org" Message-ID: <188955390.3945675.1417545616514.JavaMail.yahoo@jws106134.mail.bf1.yahoo.com> In-Reply-To: <547DC736.5070609@mit.edu> References: <547DC736.5070609@mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3945674_1152611627.1417545616504" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9jJ7AkHsk1DR8qCIRzQoy_BOYIc Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:40:22 -0000 ------=_Part_3945674_1152611627.1417545616504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "However, I think it's very clear how PoP tokens would work. ..."=20 I don't know if that's true. =C2=A0POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think. =C2=A0Otherwise I can as= an attacker take that toklen and get info about it that might be useful, a= nd I don't think that's what we want. -bill On Tuesday, December 2, 2014 6:06 AM, Justin Richer = wrote: =20 Hannes, thanks for the review. Comments inline. =20 On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: =20 Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server.=20 =20 I tried to avoid the word "client" for this very reason. The draft used to= say "client or protected resource" throughout, but in a few years of deplo= yment experience it's become clear that it's pretty much just protected res= ources that need to do introspection so I changed that text throughout. I d= on't think that "introspection client" will help here because the party alr= eady has a name from OAuth and we should inherit it. =20 =20 * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well.=20 =20 I think the document should be clear that it *specifies* the mechanism for= bearer tokens, since that's the only OAuth token type that's defined publi= cly right now, and that the details for PoP will have to be specified in an= other spec -- that's exactly what Appendix C is there for, and if that can = be clearer, please suggest better text. =20 However, I think it's very clear how PoP tokens would work. You send the v= alue returned as the "access_token" in the token endpoint response, which i= s effectively the public portion of the PoP token. Just like a bearer token= , this value is passed as-is from the client to the RS and would be passed = as-is from the RS to the AS during introspection. The AS can then use that = to look up the key and return it in an as-yet-unspecified field so that the= RS can validate the request. The RS wouldn't send the signature or signed = portion of the request for the AS to validate -- that's a bad idea. But the= se are all details that we can work out in the PoP-flavored extension. As I= noted in the other thread, we'll have to make a similar extension for Revo= cation, so I still don't think it makes sense to hold up this work and wait= for PoP to be finished because it's useful now, as-is. =20 =20 * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section.=20 =20 The idea was to inherit JWT's syntax and semantics, at least on the wire, = and add additional fields. It probably makes sense to just inherit the JWT = registry, so we can do that. =20 =20 When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand.=20 =20 Noted, will add. =20 =20 Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?!=20 =20 Anything security critical would be provider-specific, in which case it wo= uldn't ignore them.=20 =20 =20 * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS.=20 =20 I had similar thoughts when putting draft -01 together but didn't want to = make a normative change like that without the WG input. I'm fine with stren= gthening this to a MUST, since as far as I'm aware that's how it works in a= ll existing implementations (can anyone else comment on this?). I'm less co= mfortable with making one particular mechanism MTI, since I know of implem= entations that use either a special set of credentials passed just like cli= ent credentials to the token endpoint, or an OAuth token specifically for t= he introspection endpoint. If we do standardize on one MTI form, I'd sugges= t that we make it the OAuth bearer token. =20 =20 * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it?=20 =20 Noted, thanks.=20 =20 =20 * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize.=20 =20 I'm fine with that, didn't want to offend the SAML cabal but we can cut it= . =20 =20 * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active.=20 =20 It's not an error, really. It's a valid request and valid response saying = that token isn't any good. It would be easy enough to change the returned e= rror code on the {active:false} response, but to which code? The request is= n't Forbidden, or Not Found (the token could have been found but it's been = deactivated or just not available to the RS that's asking for it), or Unau= thorized, or even a Bad Request. So my logic is that the response is "OK", = but the content of the response tells you the metadata about the token, whi= ch is that it's not active.=20 =20 =20 * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue.=20 =20 Thanks, still breaking old Bad Habits of capitalizing Terms In The Documen= t. Tried to clean it up, will do more. =20 =20 * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens.=20 =20 What I was trying to point out is that it doesn't define the nature of the= relationship between the two components. Specifically, it says: =20 The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validati= on. So we could reference this directly if that's helpful.=20 =20 =C2=A0 -- Justin =20 =20 Ciao Hannes =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_3945674_1152611627.1417545616504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet= to be fully defined) would then also have a TLS or transport security requ= irement unless there is token introspection client auth in play I think. &n= bsp;Otherwise I can as an attacker take that toklen and get info about it t= hat might be useful, and I don't think that's what we want.

=
-bill



On Tuesday, December= 2, 2014 6:06 AM, Justin Richer <jricher@mit.edu> wrote:
 =


Hannes, thanks for the revi= ew. Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:
Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.iet=
f.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is.

* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-t=
oken-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Noted, will add.

Of course, there is the question whether any of those would be s=
ecurity
critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific, in which case it wouldn't ignore them. 

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

Noted, thanks. 

* Minor items

You write:

"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   Which SAML document should we reference here? ]] and proprietary
   inter-service communication mechanisms (such as shared databases and
   protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

I'm fine with that, didn't want to offend the SAML cabal but we can cut it.

* 'Active' claim

you write:
"
   active  REQUIRED.  Boolean indicator of whether or not the presented
      token is currently active.  The authorization server determines
      whether and when a given token is in an active state.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. 

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more.

* AS <-> RS relationship

You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.

What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says:

   The methods used by the resource
   server to validate the access token (as well as any error responses)
   are beyond the scope of this specification but generally involve an
   interaction or coordination between the resource server and the
   authorization server.
This spec provides one mechanism for this validation. So we could reference this directly if that's helpful.


  -- Justin

Ciao
Hannes




_______________________________________________
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
<= /div>

------=_Part_3945674_1152611627.1417545616504-- From nobody Tue Dec 2 10:49:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D91A1B21 for ; Tue, 2 Dec 2014 10:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruqRiRxr_FJr for ; Tue, 2 Dec 2014 10:49:31 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 10A461A6EE4 for ; Tue, 2 Dec 2014 10:49:31 -0800 (PST) Received: (qmail 11211 invoked by uid 0); 2 Dec 2014 18:49:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 2 Dec 2014 18:49:28 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by CMOut01 with id Nioy1p01C2is6CS01ip1Fv; Tue, 02 Dec 2014 11:49:01 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=VhNdJee_-yMA:10 a=A92cGCtB03wA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=sMBj6sIwAAAA:8 a=48vgC7mUAAAA:8 a=9hn9lkgQvH-8MDNfBhoA:9 a=pL8WwNu0vnHEXfgG:21 a=JcLFklui71tuRfnR:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=PKjczCZQm44nRn8oK9QA:9 a=RJNTIGC05BKz0n-p:21 a=zaKb1prAdGbajsfN:21 a=HZK3P_hFCrB_44ae:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=G7AE6tyXK8Ktf5xWCylQPCGxPp/SpyLwd8ALNdQZkUo=; b=I7g9Z+gCSx28jxrs7KBBR2swtZcEBGkW4CVpQLy9JSj4ocq9JJPcerWNy10/INQXTaD9yNIQw+cbqxwGUvbtM088Ed0h6D2ayhZRQkFREJUA+6g/jKx8L47H/k0EPJYW; Received: from [72.194.76.57] (port=53928 helo=HPLaptop) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XvsVO-0002WR-L1; Tue, 02 Dec 2014 11:48:58 -0700 From: "Donald Coffin" To: "'Richer, Justin P.'" References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org> In-Reply-To: <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org> Date: Tue, 2 Dec 2014 10:49:02 -0800 Organization: REMI Networks Message-ID: <00d601d00e60$a5dfa0d0$f19ee270$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D00E1D.97BED1D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKGGpy4MgmEfHmE8Q3UIvvG5HsInALnUkxoASbP4AECL+/gY5rem25w Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 72.194.76.57 authed with donald.coffin@reminetworks.com} Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vQvTpyTxhqiszL9ydIZO9L9rT3M Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:49:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D7_01D00E1D.97BED1D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Justin, Thanks for the clarification. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, December 2, 2014 10:19 AM To: Donald Coffin Cc: Justin Richer; Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 No, this isn't an appropriate mapping in this case, especially if the introspection endpoint is itself OAuth protected. You need to be able to differentiate between the token being asked about and the token authorizing the question. These error codes apply to the latter and should not be conflated with the former. -- Justin On Dec 2, 2014, at 12:25 PM, Donald Coffin > wrote: Hi Justin, I believe you will find the answer to which HTTP Status code the AS should return if the token is INACTIVE in Section 3.1 Error Codes of "The OAuth 2.0 Framework: Bearer Token Usage" [RFC6750] which states: 3.1. Error Codes When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code. invalid_token The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource. If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information. For example: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com From: Justin Richer [mailto:jricher@mit.edu] Sent: Tuesday, December 2, 2014 6:06 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted, will add. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wouldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted, thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ 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 ------=_NextPart_000_00D7_01D00E1D.97BED1D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Justin,

 

Thanks for the clarification.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA  92688-3836

 

Phone:    =   (949) 636-8571

Email:    =    donald.coffin@reminetworks= .com

 

From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: = Tuesday, December 2, 2014 10:19 AM
To: Donald = Coffin
Cc: Justin Richer; Hannes Tschofenig; = oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of = draft-ietf-oauth-introspection-01

 

No, this = isn't an appropriate mapping in this case, especially if the = introspection endpoint is itself OAuth protected. You need to be able to = differentiate between the token being asked about and the token = authorizing the question. These error codes apply to the latter and = should not be conflated with the former.

 

 -- Justin

 

On = Dec 2, 2014, at 12:25 PM, Donald Coffin <donald.coffin@reminetworks= .com> wrote:



Hi Justin,

 

I believe you will find the answer to which HTTP Status code the AS = should return if the token is INACTIVE in Section 3.1 Error Codes of = “The OAuth 2.0 Framework: Bearer Token Usage” [RFC6750] = which states:

 

3.1.  Error Codes

When a request fails, the resource server responds using the = appropriate HTTP status code (typically, 400, 401, 403, or 405) and = includes one of the following error codes in the = response:

 

invalid_request

The request is missing a required parameter, includes an unsupported = parameter or parameter value, repeats the same parameter, uses more than = one method for including an access token, or is otherwise malformed. The = resource server SHOULD respond with the HTTP 400 (Bad Request) status = code.

 

invalid_token

The access token provided is expired, revoked, malformed, or invalid = for other reasons. The resource SHOULD respond with the HTTP 401 = (Unauthorized) status code. The client MAY request a new access token = and retry the protected resource request.

 

insufficient_scope

The request requires higher privileges than provided by the access = token. The resource server SHOULD respond with the HTTP 403 (Forbidden) = status code and MAY include the scope attribute with the scope necessary = to access the protected resource.

 

If the request lacks any authentication information (e.g., the client = was unaware that authentication is necessary or attempted using an = unsupported authentication method), the resource server SHOULD NOT = include an error code or other error = information.

 

For example:

  HTTP/1.1 401 Unauthorized  WWW-Authenticate: Bearer = realm=3D"example"

 

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO<= /p>

 

REMI = Networks

22751 El Prado Suite = 6216

Rancho Santa Margarita, = CA  92688-3836

 

Phone:    =   (949) 636-8571

Email:    =    donald.coffin@reminetworks= .com

 

From: Justin Richer [mailto:jricher@mit.edu] =
Sent: Tuesday, December 2, 2014 6:06 AM
To: Hannes = Tschofenig; oauth@ietf.org
Subject: Re: = [OAUTH-WG] Review of = draft-ietf-oauth-introspection-01

 

Hannes, = thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, = Hannes Tschofenig wrote:

Hi =
Justin,
 
I have a few =
remarks regarding version -01 of the token =
introspection
document.
 <=
o:p>
* =
Terminology
 
The token =
introspection protocol is a client-server protocol but =
the
term "client" already has a meaning =
in OAuth. Here the client of the
token =
introspection protocol is actually the resource server. I =
believe
it would make sense to clarify this issue =
in the terminology section or
in the introduction. =
Maybe add a figure (which you could copy =
from
Figure 4 of
=
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.=

 
Maybe you want to call =
these two parties, the introspection client and
the =
introspection server.


I tried to avoid the word "client" for = this very reason. The draft used to say "client or protected = resource" throughout, but in a few years of deployment experience = it's become clear that it's pretty much just protected resources that = need to do introspection so I changed that text throughout. I don't = think that "introspection client" will help here because the = party already has a name from OAuth and we should inherit = it.



* =
Scope
 
I think the =
document needs to be very clear that is only applicable =
to
bearer tokens (and not to PoP tokens). This =
issue was raised at the last
IETF meeting as =
well.


I think the = document should be clear that it *specifies* the mechanism for bearer = tokens, since that's the only OAuth token type that's defined publicly = right now, and that the details for PoP will have to be specified in = another spec -- that's exactly what Appendix C is there for, and if that = can be clearer, please suggest better text.

However, I think it's = very clear how PoP tokens would work. You send the value returned as the = "access_token" in the token endpoint response, which is = effectively the public portion of the PoP token. Just like a bearer = token, this value is passed as-is from the client to the RS and would be = passed as-is from the RS to the AS during introspection. The AS can then = use that to look up the key and return it in an as-yet-unspecified field = so that the RS can validate the request. The RS wouldn't send the = signature or signed portion of the request for the AS to validate -- = that's a bad idea. But these are all details that we can work out in the = PoP-flavored extension. As I noted in the other thread, we'll have to = make a similar extension for Revocation, so I still don't think it makes = sense to hold up this work and wait for PoP to be finished because it's = useful now, as-is.



 
 
* =
Meta-Information
 
You =
have replicated a lot of the claims defined in
h=
ttps://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use =
the entire
registry from =
JWT?
 
If you want to =
create a separate registry (which I wouldn't =
recommend)
then you have to put text into the IANA =
consideration section.


The idea was to inherit JWT's syntax and = semantics, at least on the wire, and add additional fields. It probably = makes sense to just inherit the JWT registry, so we can do = that.



When you =
write:
 
"=

The endpoint MAY allow other parameters to provide further =
context to
the =
query.
"
 =

You could instead write that the token introspection MUST =
ignore any
parameters from the request message it =
does not understand.


Noted, will = add.



Of course, there is =
the question whether any of those would be =
security
critical and hence ignoring them would =
cause problems?!


Anything security critical would be = provider-specific, in which case it wouldn't ignore them. = 



* =
Security
 
The =
requirement for authenticating the party issuing the =
introspection
request to the token introspection =
endpoint is justified in the security
and the =
privacy consideration section. The security threat is that =
an
attacker could use the endpoint to testing for =
tokens. The privacy
threat is that a resource =
server learns about the content of the token,
which =
may contain personal data. I see the former as more dangerous =
than
the latter since a legitimate resource server =
is supposed to learn about
the authorization =
information in the token. An attacker who had =
gotten
hold of tokens will not only learn about the =
content of the token but he
will also be able to =
use it to get access to the protected resource =
itself.
 
In any case, to =
me this sounds like mutual authentication should =
be
mandatory to implement. This is currently not =
the case. On top of that
there is single technique =
mandatory-to-implement outlined either (in
case =
someone wants to use it). That's in general not very helpful =
from
an interoperability point of view. Yet another =
thing to agree on between
the AS and the =
RS.


I had similar = thoughts when putting draft -01 together but didn't want to make a = normative change like that without the WG input. I'm fine with = strengthening this to a MUST, since as far as I'm aware that's how it = works in all existing implementations (can anyone else comment on = this?). I'm less comfortable with making one particular mechanism MTI, = since I know of implementations that use either a special set of = credentials passed just like client credentials to the token endpoint, = or an OAuth token specifically for the introspection endpoint. If we do = standardize on one MTI form, I'd suggest that we make it the OAuth = bearer token.



* =
SHOULDs
 
This is my =
usual comment that any SHOULD statement should give =
the
reader enough information about the trade-off =
decision he has to make.
When should he implement =
something and when should he skip it?


Noted, thanks. = 



* Minor =
items
 
You =
write:
 
"=

These include using
   =
structured token formats such as JWT [JWT] or SAML [[ Editor's =
Note:
   Which SAML document should we =
reference here? ]] and proprietary
   =
inter-service communication mechanisms (such as shared databases =
and
   protected enterprise service =
buses) that convey token =
information.
"
 =

Just reference the JWT since that's what we =
standardize.


I'm = fine with that, didn't want to offend the SAML cabal but we can cut = it.



* 'Active' =
claim
 
you =
write:
"
   =
active  REQUIRED.  Boolean indicator of whether or not the =
presented
      token is =
currently active.  The authorization server =
determines
      whether =
and when a given token is in an active =
state.
"
 =

Wouldn't it make more sense to return an error rather than =
saying that
this token is not =
active.


It's not = an error, really. It's a valid request and valid response saying that = token isn't any good. It would be easy enough to change the returned = error code on the {active:false} response, but to which code? The = request isn't Forbidden, or Not Found (the token could have been found = but it's been deactivated or just not available to the RS that's asking = for it), or Unauthorized, or even a Bad Request. So my logic is that the = response is "OK", but the content of the response tells you = the metadata about the token, which is that it's not active. = 



* =
Capitalization
 
Reading =
through the text I see bearer token/Bearer Token, =
Client/client,
etc. =
issue.


Thanks, = still breaking old Bad Habits of capitalizing Terms In The Document. = Tried to clean it up, will do = more.



* AS <-> RS =
relationship
 
You =
write:
"
   =
Since
   OAuth 2.0 [RFC6749] defines no =
direct relationship between the
   =
authorization server and the protected resource, only that they =
must
   have an agreement on the tokens =
themselves, there have been many
   =
different approaches to bridging this =
gap.
"
 
I am not sure what you mean by "defines no =
relationship" between the AS
and the RS. Of =
course, there is a relationship. The AS issues tokens =
for
access for a specific RS. The RS needs to =
understand the tokens or if it
does not understand =
them it needs to know which AS to interact with =
to
learn about the =
content.
 
In a nutshell, =
I am not sure what you want to say with this =
paragraph
particularly since you state that they =
have to have an agreement about
the =
tokens.


What I was trying to point out is = that it doesn't define the nature of the relationship between the two = components. Specifically, it says:

   The =
methods used by the resource
   server to =
validate the access token (as well as any error =
responses)
   are beyond the scope of =
this specification but generally involve =
an
   interaction or coordination between =
the resource server and the
   =
authorization server.

This spec = provides one mechanism for this validation. So we could reference this = directly if that's helpful.

  -- = Justin



 
 
 
Ciao<=
/o:p>
Hannes
 




___________________=
____________________________
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

 

------=_NextPart_000_00D7_01D00E1D.97BED1D0-- From nobody Tue Dec 2 10:52:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1D1A1B36 for ; Tue, 2 Dec 2014 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwZLmVIzR3re for ; Tue, 2 Dec 2014 10:52:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901FA1A1A48 for ; Tue, 2 Dec 2014 10:52:24 -0800 (PST) Received: from BN3PR0301MB1235.namprd03.prod.outlook.com (25.161.207.23) by BN3PR0301MB1283.namprd03.prod.outlook.com (25.161.210.147) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 18:52:23 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (25.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 18:52:10 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 18:52:09 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] draft-ietf-oauth-introspection Thread-Index: AdAMxAKwZxroeEnvQECE1qCS/1bO3AAToa8AACr/M7AAApA9AAAfbxJw Date: Tue, 2 Dec 2014 18:52:08 +0000 Message-ID: References: <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> <4B1239F5-5DD3-4F1B-8691-75E8B07F3891@mit.edu> In-Reply-To: <4B1239F5-5DD3-4F1B-8691-75E8B07F3891@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235;UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(51444003)(377454003)(189002)(51914003)(24454002)(87936001)(19300405004)(86362001)(86612001)(2656002)(21056001)(16236675004)(19625215002)(110136001)(31966008)(19580405001)(74316001)(4396001)(19580395003)(54606007)(62966003)(54206007)(77156002)(76176999)(54356999)(50986999)(2171001)(97736003)(19617315012)(101416001)(15975445006)(99396003)(122556002)(107046002)(99286002)(93886004)(95666004)(76576001)(105586002)(33656002)(20776003)(106356001)(15202345003)(40100003)(120916001)(68736005)(230783001)(92726001)(46102003)(92566001)(64706001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234B515D3C028F9E9CBC44BA67A0BN3PR0301MB1234_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1283; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FDzJRYaX83l3v8qQV0_BK425lo4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:52:35 -0000 --_000_BN3PR0301MB1234B515D3C028F9E9CBC44BA67A0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Answer is still unclear, Is the metadata (introspection response) = being returned from the authorization endpoint or from the token or a combi= nation of both ? The answer needs to go in the spec 2. Spec needs to contain this information about stateless tokens 3. For interoperability there needs to be an understanding of what to= ken types this specification supports, we already know some token types tha= t may not work 4. I'm not issuing an Oauth encrypted token as it's just a bearer tok= en, just happens to be a an encrypted SAML token, which I don't know since = I'm a client that can't understand what is in token 5. I would propose wording but I'm still trying to figure out what "a= ctive" means so that everyone implementing this has the same understanding,= I did not see a definition of active in the specification. What about the Audience restricted tokens, do you expect the endpoint to ig= nore this and process the tokens for metadata ? From: Justin Richer [mailto:jricher@mit.edu] Sent: Monday, December 1, 2014 4:42 PM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection 1. Is the metadata (introspection response) being returned from the a= uthorization endpoint or from the token or a combination of both ? As I said below, ultimately it's about the token and what it represents. If= the token was issued through use of the authorization endpoint, then it's = likely that there's some context from that authorization endpoint tied to t= he token that can be returned. 2. "context" there may be no context other than the token, are you ex= pecting the authorization endpoint to always keep a context of how/why the = token was issued ? If you're asking if stateless tokens can be supported with this, then yes, = that's fine. If the token's completely on its own (like a structured token = generated as an assertion and used as an OAuth 2.0 access token) and a serv= er's able to unpack that for a client without access to other pieces of con= text, then that's what it returns. But in that case, if you're issuing stat= eless tokens, with self-contained metadata and expirations and no other con= text to be conveyed beyond what's already inside the token, then you'd prob= ably just tell your protected resources how to parse and handle them direct= ly. 3. The specification should clearly state which type of tokens are su= pported and what profiles/bindings are supported, like JWT Bearer, etc. That's opaque to the protected resource for purposes of this protocol, just= like a token is opaque to a client for purposes of 6749/6750 OAuth. The in= trospection protocol supports whatever tokens are supported by the AS, so w= e don't need to list token types, but maybe we can be clearer about the opa= queness of the token value in this process. Since these are OAuth tokens an= d not assertions, no bindings or profiles are needed beyond this. It's a si= mple query-response and it's up to the server to know how to fulfill this c= ontract. 4. If I have an SAML Bearer assertion, and the SAML assertion is encr= ypted and have no way to know this, it can potentially fail if it can't be = decrypted but as far as I can tell I'm not sending an encrypted token since= this is just a SAML assertion, not sure how one really determines what is = wrong If the AS can't decrypt the token then it can't introspect it. So it doesn'= t in this case. And if you're issuing encrypted OAuth tokens with no means = to decrypt them back at the AS, then you probably wouldn't offer an introsp= ection service to begin with. This is covered in the security consideration= s section already. 5. Should be spelled out what "active" is supposed to mean so folks g= et the same results on different endpoints As I said below, it means to answer "is this token still good or not?" for = a protected resource that can't answer that on its own, and I believe the c= urrent definition reflects that. Please submit text if the existing definit= ion is insufficient or unclear to you. - Justin From: Justin Richer [mailto:jricher@mit.edu] Sent: Sunday, November 30, 2014 6:57 PM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection Tony, thanks for the comments. Your timing is great, as I was just today si= tting down to polish the introspection draft into a proper WG document read= y for the last-call tomorrow. I've just posted the updated draft, and I thi= nk that you'll find it addresses your concerns. More direct answers inline: On Nov 30, 2014, at 1:01 PM, Anthony Nadalin > wrote: Comments Intro "about the authentication conext", not sure what this is since there is no = authentication context in Oauth There are several authentication contexts in OAuth: the resource owner at t= he authorization endpoint, the client at the token endpoint, etc. Regardles= s, this is meant to be the context of the authorization decision, text now = reads: "context in which the token was issued" Use of Oauth2, mixed with use of Oauth, pick one All usage changed to "OAuth 2.0" throughout the document, let me know if I = missed any. "allows holder of a token to query" so anything/anyone that has a token can= use this endpoint? Now reads authorized holder of the token and has stronger language and reco= mmendations about requiring authorization on the endpoint to prevent public= token fishing. This was already addressed in the security considerations s= ection, but that has been propagated throughout the specification now. Introspection Endpoint Use of Oauth2, mixed with use of Oauth, pick one See above. Introspection Request The endpoint SHOULD also require some form of authentication", what about s= ome form of authorization ? Why do we have to have another endpoint that we= have to manage and then have a management API draft?] This is now clearer that it needs to be an authorized protected resource. T= his authorization may be carried through a credential mechanism as defined = in OAuth 2.0, through an access token, or through some other mechanism. Token - is this any type of token ? how does the endpoint know that it can = deal with this token type? Clarified that it's either the access_token from the token endpoint or the = refresh_token from the token endpoint. You can use this with other token ty= pes, but that's not defined in this spec which concerns itself with RFC6749= /RFC6750. So endpoint has to try to lookup token to determine if it can maybe find o= ut something about the token? That's the idea, the protected resource is asking an authoritative source (= the authorization server) about a given token. I had always thought it was = obvious that the authorization server would have to be able to know somethi= ng about the token in order to provide an introspection service, but since = that seems to have been unclear to some I've made it explicit in the securi= ty considerations section. Can the one use the authorization code or does one have to get a token firs= t? No, this is for tokens only. I don't see the point of introspecting an auth= orization code - those aren't sent to protected resources, they're sent to = clients, which would in turn just hand it to the token endpoint to get a to= ken. There's nothing else to find out about it. Can I send a encrypted token and expect a proper response ? If the server can decrypt or otherwise understand the token, yes. I've poin= ted out this requirement in the security considerations section. What about a Proof of Possession Token? Yes, I think this fits great with PoP tokens, but those aren't defined well= enough yet to say anything concrete. As the PoP work progresses, we can ha= ve an extension document to determine what needs to be done there. Note tha= t we'll have to do the same thing with the Revocation RFC. Introspection Response What is "active" mean ? Is this up to the server to determine ? It means the token is live, hasn't been revoked, was actually issued by thi= s server, isn't expired, and the protected resource that's asking has the r= ight to know all that information. This is all up to the server to determin= e. If the server can't determine that information for its own tokens, it pr= obably shouldn't be offering this service. "scope OPTIONAL", is this the scope in the token or is this the scope that = the introspection endpoint sources may have ? It's unclear if all these ret= urn values are from the token or from the introspection endpoint sources ? These are the scopes of the token. All return values are, as stated, metada= ta about the token itself that is being queried against. What error codes/conditions are there? Just the 400 (bad request)? The errors are more clearly spelled out. Most of it involves bad client aut= hentication (when client credentials are used), bad authorization (when acc= ess tokens are used to access the introspection endpoint itself), or the li= ke. If the token being introspected isn't good, that's still a 200 response= - the request is fine, but the token being introspected isn't active, whic= h is what's returned. This isn't an error, it's a valid answer to the quest= ion of "what is this token?" that's being asked every time introspection is= called. Can the endpoint return a encrypted response ? That's outside the scope of this document. It returns JSON like the rest of= OAuth. What about PII such as user_id, aud ? This is now covered in the Privacy Considerations section, which wasn't A T= hing when this draft was first written. - Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BN3PR0301MB1234B515D3C028F9E9CBC44BA67A0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.&n= bsp;      Answer is stil= l unclear, Is the metadata (introspection respons= e) being returned from the authorization endpoint or from the token or a co= mbination of both ? The answer needs to go in the spec

2.&n= bsp;      Spec needs to = contain this information about stateless tokens

3.&n= bsp;      For interopera= bility there needs to be an understanding of what token types this specific= ation supports, we already know some token types that may not work

4.&n= bsp;      I’m not = issuing an Oauth encrypted token as it’s just a bearer token, just ha= ppens to be a an encrypted SAML token, which I don’t know since IR= 17;m a client that can’t understand what is in token

5.&n= bsp;      I would propos= e wording but I’m still trying to figure out what “active”= ; means so that everyone implementing this has the same understanding, I di= d not see a definition of active in the specification.

 

What about the Audienc= e restricted tokens, do you expect the endpoint to ignore this and process = the tokens for metadata ?

 

From: Justin Richer [mailto:jricher@mit.edu] =
Sent: Monday, December 1, 2014 4:42 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

 

1. =       Is the metadata (introspection respons= e) being returned from the authorization endpoint or from the token or a co= mbination of both ?

 

As I said below, ultimately it’s about the tok= en and what it represents. If the token was issued through use of the autho= rization endpoint, then it’s likely that there’s some context f= rom that authorization endpoint tied to the token that can be returned.



2. =       “context” there may be no = context other than the token, are you expecting the authorization endpoint = to always keep a context of how/why the token was issued ?

 

If you’re asking if stateless tokens can be su= pported with this, then yes, that’s fine. If the token’s comple= tely on its own (like a structured token generated as an assertion and used= as an OAuth 2.0 access token) and a server’s able to unpack that for a client without access to other pieces of context, then t= hat’s what it returns. But in that case, if you’re issuing stat= eless tokens, with self-contained metadata and expirations and no other con= text to be conveyed beyond what’s already inside the token, then you’d probably just tell your protected resources ho= w to parse and handle them directly. 



3. =       The specification should clearly state= which type of tokens are supported and what profiles/bindings are supporte= d, like JWT Bearer, etc.

 

That’s opaque to the protected resource for pu= rposes of this protocol, just like a token is opaque to a client for purpos= es of 6749/6750 OAuth. The introspection protocol supports whatever tokens = are supported by the AS, so we don’t need to list token types, but maybe we can be clearer about the opaqueness of t= he token value in this process. Since these are OAuth tokens and not assert= ions, no bindings or profiles are needed beyond this. It’s a simple q= uery-response and it’s up to the server to know how to fulfill this contract. 



4. =       If I have an SAML Bearer assertion, an= d the SAML assertion is encrypted and have no way to know this, it can pote= ntially fail if it can’t be decrypted but as far as I can tell I̵= 7;m not sending an encrypted token since this is just a SAML assertion, not sure how one really determines what is wrong=

 

If the AS can’t decrypt the token then it can&= #8217;t introspect it. So it doesn’t in this case. And if you’r= e issuing encrypted OAuth tokens with no means to decrypt them back at the = AS, then you probably wouldn’t offer an introspection service to begin with. This is covered in the security considerations section alre= ady.



5. =       Should be spelled out what “acti= ve” is supposed to mean so folks get the same results on different en= dpoints

 

As I said below, it means to answer “is this t= oken still good or not?” for a protected resource that can’t an= swer that on its own, and I believe the current definition reflects that. P= lease submit text if the existing definition is insufficient or unclear to you.

 

 — Justin



 

 

From: Justin Richer [mai= lto:jricher@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

 

Tony, thanks for the comments. Your timing is great, as I was just= today sitting down to polish the introspection draft into a proper WG docu= ment ready for the last-call tomorrow. I’ve just posted the updated draft, and I think that you’ll fi= nd it addresses your concerns. More direct answers inline:

 

 

On Nov 30, 2014, at 1:01 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:




Comments

 

Intro

“about the authentication conext”, not sure what this = is since there is no authentication context in Oauth

 

There are several authentication contexts in OAuth: the resource o= wner at the authorization endpoint, the client at the token endpoint, etc. = Regardless, this is meant to be the context of the authorization decision, text now reads: "context in wh= ich the token was issued"




Use of Oauth2, mixed with use of Oauth, pick one

 

All usage changed to “OAuth 2.0” throughout the docume= nt, let me know if I missed any.




“allows holder of a token to query” so anything/anyone= that has a token can use this endpoint?

 

Now reads authorized holder of the token and has stronger language= and recommendations about requiring authorization on the endpoint to preve= nt public token fishing. This was already addressed in the security considerations section, but that has been propag= ated throughout the specification now. 




 

Introspection Endpoint

Use of Oauth2, mixed with use of Oauth, pick one

 

 

See above.





Introspection Request

The endpoint SHOULD also require some form of authentication”= ;, what about some form of authorization ? Why do we have to have another e= ndpoint that we have to manage and then have a management API draft?]

 

This is now clearer that it needs to be an authorized protected re= source. This authorization may be carried through a credential mechanism as= defined in OAuth 2.0, through an access token, or through some other mechanism. 




 

Token – is this any type of token ? how does the endpoint kn= ow that it can deal with this token type?

 

Clarified that it’s either the access_token from the token e= ndpoint or the refresh_token from the token endpoint. You can use this with= other token types, but that’s not defined in this spec which concerns itself with RFC6749/RFC6750. <= /p>




So endpoint has to try to lookup token  to determine if it ca= n maybe find out something about the token?

 

That’s the idea, the protected resource is asking an authori= tative source (the authorization server) about a given token. I had always = thought it was obvious that the authorization server would have to be able to know something about the token in order to= provide an introspection service, but since that seems to have been unclea= r to some I’ve made it explicit in the security considerations sectio= n. 




Can the one use the authorization code or does one have to get a t= oken first?

 

No, this is for tokens only. I don’t see the point of intros= pecting an authorization code — those aren’t sent to protected = resources, they’re sent to clients, which would in turn just hand it to the token endpoint to get a token. There’s nothing e= lse to find out about it.




 Can I send a encrypted token and expect a proper response ?<= o:p>

 

If the server can decrypt or otherwise understand the token, yes. = I’ve pointed out this requirement in the security considerations sect= ion. 




What about a Proof of Possession Token?

 

Yes, I think this fits great with PoP tokens, but those aren’= ;t defined well enough yet to say anything concrete. As the PoP work progre= sses, we can have an extension document to determine what needs to be done there. Note that we’ll have to do th= e same thing with the Revocation RFC.




 Introspection Response

What is “active” mean ? Is this up to the server to de= termine ?

 

It means the token is live, hasn’t been revoked, was actuall= y issued by this server, isn’t expired, and the protected resource th= at’s asking has the right to know all that information. This is all up to the server to determine. If the server can’t deter= mine that information for its own tokens, it probably shouldn’t be of= fering this service.




“scope OPTIONAL”, is this the scope in the token or is= this the scope that the introspection endpoint sources may have ? It’= ;s unclear if all these return values are from the token or from the introspection endpoint sources ?

 

These are the scopes of the token. All return values are, as state= d, metadata about the token itself that is being queried against.




What error codes/conditions are there? Just the 400  (bad req= uest)?

 

The errors are more clearly spelled out. Most of it involves bad c= lient authentication (when client credentials are used), bad authorization = (when access tokens are used to access the introspection endpoint itself), or the like. If the token being intros= pected isn’t good, that’s still a 200 response — the requ= est is fine, but the token being introspected isn’t active, which is = what’s returned. This isn’t an error, it’s a valid answer to the question of “what is this token?” that’s being as= ked every time introspection is called.




Can the endpoint return a encrypted response ?

 

That’s outside the scope of this document. It returns JSON l= ike the rest of OAuth.




What about PII such as user_id, aud ?

 

This is now covered in the Privacy Considerations section, which w= asn’t A Thing when this draft was first written.

 

 — Justin




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

 

 

--_000_BN3PR0301MB1234B515D3C028F9E9CBC44BA67A0BN3PR0301MB1234_-- From nobody Tue Dec 2 10:53:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A49C1A6FC8 for ; Tue, 2 Dec 2014 10:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-XRHZInnniR for ; Tue, 2 Dec 2014 10:53:27 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id DA63F1A6F0D for ; Tue, 2 Dec 2014 10:53:26 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6ED30B2E037; Tue, 2 Dec 2014 13:53:26 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 6320CB2E036; Tue, 2 Dec 2014 13:53:26 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 13:53:25 -0500 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: Notes on draft-ietf-oauth-introspection-01 Thread-Index: AQHQDkpJKmFk6MGa7kiP8hZWrsiWypx8+fSA Date: Tue, 2 Dec 2014 18:53:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_D807C922808E445BA9F2D1C8DAEE1BF5mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3m2KeveAjbUESK2_EZcsYPHH5Ko Cc: "" Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:53:30 -0000 --_000_D807C922808E445BA9F2D1C8DAEE1BF5mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thomas, thanks for the review. Responses inline. On Dec 2, 2014, at 11:08 AM, Thomas Broyer > wrote: Hi, Here are some notes about draft-ietf-oauth-introspection-01. Background: I have implemented and deployed -00 (actually that was some ver= sion of the individual draft, before it got adopted by the WG), currently w= ith only a couple "clients" (out of 20 or so OAuth 2.0 clients currently, o= nly a couple expose resources themselves and thus need the introspection en= dpoint; we otherwise have many resources exposed by the same piece of softw= are as the AS so they use internal means of validating the token without th= e need for the introspection endpoint). resource_id OPTIONAL. A service-specific string identifying the resource that the token is being used for. This value allows the protected resource to convey to the authorization server the context in which the token is being used at the protected resource, allowing the authorization server to tailor its response accordingly if desired. I think it should be noted somewhere that it's totally OK for the introspec= tion endpoint to tailor the response to the resource server making the requ= est too, independently of whether there's a resource_id or not. With "tailo= ring the response" meaning that it could return active:false even if the to= ken is active but the AS doesn't want the RS to know about it (because, for= example, it knows that the token doesn't grant any scope that the RS accep= ts, and therefore couldn't be used at the RS), or limiting the returned lis= t of scopes to the ones the AS knows the RS handles. This is very true, we should call that out explicitly in the description of= the response. Thanks! As far as resource_id is concerned, I really think an example would make th= ings clearer (what kind of value could be used in a real scenario, etc. =96= there's been a mail earlier today assuming it would be a URL, which I assu= me to mean the URL of the resource that received the token and needs to int= rospect it to allow access or not; my interpretation of the draft initially= was that it would rather be identifiers as can be seen for scopes, or a re= source-set ID ) My thought on this was that it would be the URL in many cases, but I want t= o keep it as a generic string to allow for resource sets or other identifyi= ng mechanisms. This is going to have to be something that's agreed on betwe= en the AS and RS if it's going to mean anything. I agree on adding it to at= least one of the examples. The methods of managing and validating these authentication credentials are out of scope of this specification, though it is RECOMMENDED that these credentials be distinct from those used at an authorization server's token endpoint. and later in the Security Considerations section: The authorization server SHOULD issue credentials to any protected resources that need to access the introspection endpoint, SHOULD require protected resources to be specifically authorized to call the introspection endpoint, and SHOULD NOT allow a single piece of software acting as both a client and a protected resource to re- use the same credentials between the token endpoint and the introspection endpoint. Could you expand on the RECOMMENDED and SHOULD NOT here? What would be the problem with using the same credentials? What's the trade= -off? Different credentials for different purposes, and it lets you manage things= separately at the server. In other words, you've got one class of thing th= at *gets* tokens, and one class of thing that *accepts* tokens. The dynamic= resource registration draft doesn't presume client credentials at all, sin= ce a resource might not (and in many cases is not) also an OAuth client. Th= is draft even uses tokens to authorize its calls to the introspection endpo= int, which was suggested as MTI in another thread. Additionally, and this may be getting unnecessarily colored by our own impl= ementation and deployment of pre-WG drafts: we have it currently implemente= d such that both are clients (and Ping does something similar with their ow= n method of accomplishing the same thing), and we want to start to keep the= se classes separate. We've found that developers get confused about whether= they're a client or a resource or whatnot as it is. This recommendation he= lps keep the roles separate logically, though servers are of course free to= throw everyone in the same bucket if they so choose. The response MAY be cached by the protected resource, and the authorization server SHOULD communicate appropriate cache controls using applicable HTTP headers. Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf= .org/html/rfc7231), it's not clear to me how cache headers would really hel= p, given that the requests to the introspection endpoint are mostly using t= he POST method ("optionally" a GET method, and the Security Considerations = section somehow discourages it). You'd want to check with the HTTPWG but maybe this text should define what = the cache-key would be (it would at least include the token and resource_id= if provided, maybe also the token_type_hint), and that the response SHOULD= NOT have Cache-Control:public or even s-maxage (for the same reason that i= t should be protected by authentication). I'd actually rather say that the RS may cache the response (we're talking a= bout an "application-level cache" here, not an HTTP cache), and probably sh= ould do it for a small amount of time; and possibly (not sure how well that= would fit here) hint that the AS could very well return an HTTP 429 (Too M= any Requests) if it somehow detects t= hat the RS doesn't use a (application-level) cache (e.g. asks many times fo= r the same token in a very short time frame). This is the kind of things I = could very well add to my implementation later on if we ever see a very hig= h number of requests on our introspection endpoint (because looking up a ke= y-value store using the token as key is much faster than validating the tok= en =96 our tokens are base64url-encoded JSON structures containing an ID an= d a salt, and we store the ID and a hash in our datastore; validating a tok= en thus involves decoding base64url, parsing JSON and computing a hash, in = addition to looking it up in the datastore and validating "iat" and "exp"). All that we're really trying to say here is that the protected resource is = allowed to cache the response if it wants to, and that the AS could give so= me hints as to how to do it. I can pull out the HTTP-cache-mechanism langua= ge if it's just confusing the matter (which I suspect it is). In one deploy= ment profile I've written of this, we say that the RS can cache the introsp= ection result for up to half the token lifetime, given by the 'exp' claim (= which we also require in the profile). If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and its credentials are invalid, the authorization server responds with an HTTP 400 (Bad Request) as described in section 5.2 of OAuth 2.0 [RFC6749]. Either I don't understand what "OAuth 2.0 client credentials" actually mean= s, or that section should mention HTTP 401 (Unauthorized). (we use HTTP Basic auth FWIW so, per the HTTP spec, we return a 401 for bad= credentials). If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint and the token used for authorization does not contain sufficient privileges or is otherwise invalid for this request, the authorization server responds with an HTTP 400 code as described in section 3 of OAuth 2.0 Bearer Token Usage [RFC6750]. Same here; unless you use the "Form-Encoded Body Parameter" or "URL Query P= arameter" means of sending a Bearer token, the status code would be a 401. BTW, if an introspection endpoint MAY support those means of authenticating= a RS, then it should be more clearly stated in the draft that it is allowe= d and left at the discretion of the implementation. As an implementer, unle= ss I'm told that I could use access_token in the request body, I would assu= me only the Authorization header is accepted. Noted, I'll change these to 401. Thanks very much! -- Justin --_000_D807C922808E445BA9F2D1C8DAEE1BF5mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8CEF358A6F8F364DBC8FDA44DC82C653@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Thomas, thanks for the review. Responses inline.

On Dec 2, 2014, at 11:08 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Hi,

Here are some notes about draft-ietf-oauth-introspection-01.
Background: I have implemented and deployed -00 (actually that was som= e version of the individual draft, before it got adopted by the WG), curren= tly with only a couple "clients" (out of 20 or so OAuth 2.0 clien= ts currently, only a couple expose resources themselves and thus need the introspection endpoint; we otherwise have man= y resources exposed by the same piece of software as the AS so they use int= ernal means of validating the token without the need for the introspection = endpoint).

   resource_id  OPTIONAL.  A service-specif=
ic string identifying the
      resource that the token is being used for.  This value allows the

      protected resource to convey to the a=
uthorization server the
      context in which the token is being used at the protected
      resource, allowing the authorization server to tailor its response
      accordingly if desired.

I think it should be noted somewhere that it's totally OK for the introspec= tion endpoint to tailor the response to the resource server making the requ= est too, independently of whether there's a resource_id or not. With "= tailoring the response" meaning that it could return active:false even if the token is active but the AS doesn'= t want the RS to know about it (because, for example, it knows that the tok= en doesn't grant any scope that the RS accepts, and therefore couldn't be u= sed at the RS), or limiting the returned list of scopes to the ones the AS knows the RS handles.

This is very true, we should call that out explicitly in the descripti= on of the response. Thanks!


As far as resource_id is concerned, I really think an example would ma= ke things clearer (what kind of value could be used in a real scenario, etc= . =96 there's been a mail earlier today assuming it would be a URL, which I= assume to mean the URL of the resource that received the token and needs to introspect it to allow access or not;= my interpretation of the draft initially was that it would rather be ident= ifiers as can be seen for scopes, or a resource-set ID <https://tools.= ietf.org/html/draft-hardjono-oauth-resource-reg-03> )

My thought on this was that it would be the URL in many cases, but I w= ant to keep it as a generic string to allow for resource sets or other iden= tifying mechanisms. This is going to have to be something that's agreed on = between the AS and RS if it's going to mean anything. I agree on adding it to at least one of the examples. 

   The methods of managing and
   validating these authentication credentials are out of scope of this
   specification, though it is RECOMMENDED that these credentials be
   distinct from those used at an authorization server's token endpoint.

and later in the Security Considerations section:

   The authorization server SHOULD issue cr=
edentials to any
   protected resources that need to access the introspection endpoint,
   SHOULD require protected resources to be specifically authorized to
   call the introspection endpoint, and SHOULD NOT allow a single piece
   of software acting as both a client and a protected resource to re-
   use the same credentials between the token endpoint and the
   introspection endpoint.

Could you expand on the RECOMMENDED and SHOULD NOT here?
What would be the problem with using the same credentials? What's the = trade-off?

Different credentials for different purposes, and it lets you manage t= hings separately at the server. In other words, you've got one class of thi= ng that *gets* tokens, and one class of thing that *accepts* tokens. The dy= namic resource registration draft doesn't presume client credentials at all, since a resource might not (and= in many cases is not) also an OAuth client. This draft even uses tokens to= authorize its calls to the introspection endpoint, which was suggested as = MTI in another thread.

Additionally, and this may be getting unnecessarily colored by our own= implementation and deployment of pre-WG drafts: we have it currently imple= mented such that both are clients (and Ping does something similar with the= ir own method of accomplishing the same thing), and we want to start to keep these classes separate. We've fo= und that developers get confused about whether they're a client or a resour= ce or whatnot as it is. This recommendation helps keep the roles separate l= ogically, though servers are of course free to throw everyone in the same bucket if they so choose.


   The response MAY be cached by the protec=
ted resource, and the
   authorization server SHOULD communicate appropriate cache controls
   using applicable HTTP headers.

Reading through https:= //tools.ietf.org/html/rfc7234 (and https://tools.ietf.org/html/rfc7231), it's not clear t= o me how cache headers would really help, given that the requests to the introspection endpoint are mostly using the= POST method ("optionally" a GET method, and the Security Conside= rations section somehow discourages it).
You'd want to check with the HTTPWG but maybe this text should define = what the cache-key would be (it would at least include the token and resour= ce_id if provided, maybe also the token_type_hint), and that the response S= HOULD NOT have Cache-Control:public or even s-maxage (for the same reason that it should be protected by aut= hentication).
I'd actually rather say that the RS may cache the response (we're talk= ing about an "application-level cache" here, not an HTTP cache), = and probably should do it for a small amount of time; and possibly (not sur= e how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) <https://tools.ietf.org/html/rfc658= 5> if it somehow detects that the RS doesn't use a (application-leve= l) cache (e.g. asks many times for the same token in a very short time frame). This is the kind of things I could very= well add to my implementation later on if we ever see a very high number o= f requests on our introspection endpoint (because looking up a key-value st= ore using the token as key is much faster than validating the token =96 our tokens are base64url-encoded JSON= structures containing an ID and a salt, and we store the ID and a hash in = our datastore; validating a token thus involves decoding base64url, parsing= JSON and computing a hash, in addition to looking it up in the datastore and validating "iat" and "= ;exp").

All that we're really trying to say here is that the protected resourc= e is allowed to cache the response if it wants to, and that the AS could gi= ve some hints as to how to do it. I can pull out the HTTP-cache-mechanism l= anguage if it's just confusing the matter (which I suspect it is). In one deployment profile I've written of = this, we say that the RS can cache the introspection result for up to half = the token lifetime, given by the 'exp' claim (which we also require in the = profile). 


   If the protected resource uses OAuth 2.0=
 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 400 (Bad
   Request) as described in section 5.2 of OAuth 2.0 [RFC6749].

Either I don't understand what "OAuth 2.0 client credentials"= ; actually means, or that section should mention HTTP 401 (Unauthorized).
(we use HTTP Basic auth FWIW so, per the HTTP spec, we return a 401 fo= r bad credentials).

   If the protected resource uses an OAuth =
2.0 bearer token to authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 400 code as described in section 3 of OAuth 2.0 Bearer=
 Token
   Usage [RFC6750]=
.

Same here; unless you use the "Form-Encoded Body Parameter" = or "URL Query Parameter" means of sending a Bearer token, the sta= tus code would be a 401.
BTW, if an introspection endpoint MAY support those means of authentic= ating a RS, then it should be more clearly stated in the draft that it is a= llowed and left at the discretion of the implementation. As an implementer,= unless I'm told that I could use access_token in the request body, I would assume only the Authorization he= ader is accepted.

Noted, I'll change these to 401. 

Thanks very much!
 -- Justin


--_000_D807C922808E445BA9F2D1C8DAEE1BF5mitreorg_-- From nobody Tue Dec 2 11:05:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27821A6FE3 for ; Tue, 2 Dec 2014 11:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFevxWrEJbPm for ; Tue, 2 Dec 2014 11:05:08 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id E4B331A0673 for ; Tue, 2 Dec 2014 11:05:05 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A57372E1BB; Tue, 2 Dec 2014 14:05:03 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 1059172E1BF; Tue, 2 Dec 2014 14:05:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 14:05:02 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAA== Date: Tue, 2 Dec 2014 19:05:02 +0000 Message-ID: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> References: <547DC736.5070609@mit.edu> <188955390.3945675.1417545616514.JavaMail.yahoo@jws106134.mail.bf1.yahoo.com> In-Reply-To: <188955390.3945675.1417545616514.JavaMail.yahoo@jws106134.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_131139F20F734315B52A9F609B55EF4Cmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0skIhEDO552xuOInY61PZpit0lM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:05:19 -0000 --_000_131139F20F734315B52A9F609B55EF4Cmitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill On Tuesday, December 2, 2014 6:06 AM, Justin Richer > wrote: Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to = say "client or protected resource" throughout, but in a few years of deploy= ment experience it's become clear that it's pretty much just protected reso= urces that need to do introspection so I changed that text throughout. I do= n't think that "introspection client" will help here because the party alre= ady has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for = bearer tokens, since that's the only OAuth token type that's defined public= ly right now, and that the details for PoP will have to be specified in ano= ther spec -- that's exactly what Appendix C is there for, and if that can b= e clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the va= lue returned as the "access_token" in the token endpoint response, which is= effectively the public portion of the PoP token. Just like a bearer token,= this value is passed as-is from the client to the RS and would be passed a= s-is from the RS to the AS during introspection. The AS can then use that t= o look up the key and return it in an as-yet-unspecified field so that the = RS can validate the request. The RS wouldn't send the signature or signed p= ortion of the request for the AS to validate -- that's a bad idea. But thes= e are all details that we can work out in the PoP-flavored extension. As I = noted in the other thread, we'll have to make a similar extension for Revoc= ation, so I still don't think it makes sense to hold up this work and wait = for PoP to be finished because it's useful now, as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, a= nd add additional fields. It probably makes sense to just inherit the JWT r= egistry, so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted, will add. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wou= ldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST, since as far as I'm aware that's how it works in al= l existing implementations (can anyone else comment on this?). I'm less com= fortable with making one particular mechanism MTI, since I know of implemen= tations that use either a special set of credentials passed just like clien= t credentials to the token endpoint, or an OAuth token specifically for the= introspection endpoint. If we do standardize on one MTI form, I'd suggest = that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted, thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error, really. It's a valid request and valid response saying t= hat token isn't any good. It would be easy enough to change the returned er= ror code on the {active:false} response, but to which code? The request isn= 't Forbidden, or Not Found (the token could have been found but it's been d= eactivated or just not available to the RS that's asking for it), or Unauth= orized, or even a Bad Request. So my logic is that the response is "OK", bu= t the content of the response tells you the metadata about the token, which= is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document= . Tried to clean it up, will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference= this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ 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 --_000_131139F20F734315B52A9F609B55EF4Cmitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <6F7CF7CE3557DA4DAD40AA81794EF797@imc.mitre.org> Content-Transfer-Encoding: quoted-printable The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it and the request. What I'm saying is th= at you introspect the identifier and get back something that lets you, the = RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ...= "

I don't know if that's true.  POP tokens (as yet to be fully def= ined) would then also have a TLS or transport security requirement unless t= here is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and ge= t info about it that might be useful, and I don't think that's what we want= .

-bill



On Tuesday, December 2, 20= 14 6:06 AM, Justin Richer <jricher@mi= t.edu> wrote:


Hannes, thanks for the review. = Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:
Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of =
the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.iet=
f.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

I tried to avoid the word "client" for this very reason. The draf= t used to say "client or protected resource" throughout, but in a= few years of deployment experience it's become clear that it's pretty much= just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection = client" will help here because the party already has a name from OAuth= and we should inherit it.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism for = bearer tokens, since that's the only OAuth token type that's defined public= ly right now, and that the details for PoP will have to be specified in ano= ther spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better= text.

However, I think it's very clear how PoP tokens would work. You send the va= lue returned as the "access_token" in the token endpoint response= , which is effectively the public portion of the PoP token. Just like a bea= rer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS durin= g introspection. The AS can then use that to look up the key and return it = in an as-yet-unspecified field so that the RS can validate the request. The= RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad id= ea. But these are all details that we can work out in the PoP-flavored exte= nsion. As I noted in the other thread, we'll have to make a similar extensi= on for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished = because it's useful now, as-is.

* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-t=
oken-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics, at least on the wire, a= nd add additional fields. It probably makes sense to just inherit the JWT r= egistry, so we can do that.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Noted, will add.

Of course, there is the question whether any of those would be securit=
y
critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific, in which case it wou= ldn't ignore them. 

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST, since as far as I'm aware that's how it works in al= l existing implementations (can anyone else comment on this?). I'm less comfortable with making one partic= ular mechanism MTI, since I know of implementations that use either a speci= al set of credentials passed just like client credentials to the token endp= oint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd = suggest that we make it the OAuth bearer token.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

Noted, thanks. 

* Minor items

You write:

"
These include using
   structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   Which SAML document should we reference here? ]] and proprietary
   inter-service communication mechanisms (such as shared databases and
   protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

I'm fine with that, didn't want to offend the SAML cabal but we can cut it.= 

* 'Active' claim

you write:
"
   active  REQUIRED.  Boolean indicator of whether or not the presented
      token is currently active.  The authorization server determines
      whether and when a given token is in an active state.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

It's not an error, really. It's a valid request and valid response saying t= hat token isn't any good. It would be easy enough to change the returned er= ror code on the {active:false} response, but to which code? The request isn= 't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not availabl= e to the RS that's asking for it), or Unauthorized, or even a Bad Request. = So my logic is that the response is "OK", but the content of the = response tells you the metadata about the token, which is that it's not active. 

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

Thanks, still breaking old Bad Habits of capitalizing Terms In The Document= . Tried to clean it up, will do more.

* AS <-> RS relationship

You write:
"
   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between =
the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.

What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically, it says:

   The methods used by the resource
   server to validate the access token (as well as any error responses)
   are beyond the scope of this specification but generally involve an
   interaction or coordination between the resource server and the
   authorization server.
This spec provides one mechanism for this validation. So we could reference= this directly if that's helpful.

  -- Justin

Ciao
Hannes




_______________________________________________
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

--_000_131139F20F734315B52A9F609B55EF4Cmitreorg_-- From nobody Tue Dec 2 11:09:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6691A6F93 for ; Tue, 2 Dec 2014 11:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5uKdGwV3Wl0 for ; Tue, 2 Dec 2014 11:09:15 -0800 (PST) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A641E1A6EDA for ; Tue, 2 Dec 2014 11:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417547354; bh=OUPnWoSBPvdrva2qwKMRDy4UVnlNzjFwE4qLNB0IXl8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Gf9Yjog0LA8qhZxOBCG7FWuLMT9wesdNJ6q2rNvEr36GvY/YluGNG/EdXXgYgPAmT3Sx9tSHevPcGCDCVPRPAfvvdopBJCQqFO+kENXDIfC0MdRgvmtebT7GJ+mdSNpnhhIhBfOPrUjwTiV7/L92sllrpUL3Oazq6neDwt74TidiKkUG+oGJM/qCj5iiCipTgE1cNvseLN/3Tjz+BGBqFYXwJ21OZoPJv36446rZql6Jy3eBygU8kafrMqV4TruBCxVynKqyt+BoSF8UnhCijaTl19K53U44I0gm8U9q4/+cWyTxhdy9apt61RlVAvlnhSTNfur2ULwgwqAeJsmmkg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=R5RRbpcLtW/gKCPvNSmuvbjcIxTuzpn2/Ji/BFknnRtX0hgUwu9YREgj5DSZb4MV0fRzfPDpolXwsbBNVu8e84fvGQirviFdpY2wNan+ScjFiY76StgtXdFUSf9Xy3/6My2jmarCHcf0t8Qm87EPlRe2OhhdTW3EN9LwbaW1PankwO5NR2ANE1kNicKFmzqQ+F7Yg8+bOOM4bSMMxu6QsQWvhhq87JJLmzIADRs+4Rejk+utRQEVTfVuGjHEbuh8ZFU3Vg+Yi/z6Ut2Fv1Pr+3cxADFTstupsko5E8/yl/S8ZUL3pLRa2lR1+aDCKdR9gSp0Cvx/CSmw8ejRrMjkog==; Received: from [98.139.212.153] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:09:14 -0000 Received: from [98.139.212.198] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:09:14 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:09:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 812646.41844.bm@omp1007.mail.bf1.yahoo.com X-YMail-OSG: 4eaOtmIVM1kQosMR0WfEWuXL4fUN4n15CS_SFL6zJsauO0KEXNETheYrpVGoFWT koJUF6KvaGdD4b.jU0GU7WMtfaMy1kW.C4l9XEstBxfoaB1FMmaCCrvo7o80DgqC5ub98vGPWlH0 mE_M2LunGk8MxfdLP0TM5klFmL7aYyg4XvUd5XecaeJxTDHbAIoCNNBbQb1RV1nevfwT6rcZ4GVh 3sbas__xXKE5jRUbajj6JEOHdzt7VcGQO5b9Aq8Hn4RpbceNzL5ef8a677hmyPMUhAhQbhlt36Fv 6djoB9pbesfJFNu8wIPLFKeqpfOjfAt3NnQJzgi0bCg1sUl6hf3NCSzYROySFeNXZ5Q8sxY.zhxu v4ppxYjkZTfDh1b6vuk4Q8bVRsZ4Gbw0phh0HzIRA3YPjXGDSwjchPWqCuSb_vHzO4AJ7UWuMp5Y Av7ByM.xx68ekfjq3fHHduk1hXpyMW5HoyclLqZaC_ZfBp_bAt4YVrr_.3Oq5cr4rC4M6_4J5mNM- Received: by 76.13.27.48; Tue, 02 Dec 2014 19:09:14 +0000 Date: Tue, 2 Dec 2014 19:09:13 +0000 (UTC) From: Bill Mills To: "Richer, Justin P." Message-ID: <244078391.3267266.1417547353925.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> In-Reply-To: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> References: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3267265_2097723159.1417547353922" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2J_t44OvxFKBnRjC6k2BjDV_GLc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:09:21 -0000 ------=_Part_3267265_2097723159.1417547353922 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? =C2=A0Data about the user? =C2=A0= Where does this blur the line between this and "act on behalf of"?=20 On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." wrote: =20 The call to introspection has a TLS requirement, but the call to the RS wo= uldn't necessarily have that requirement. The signature and the token ident= ifier are two different things. The identifier doesn't do an attacker any g= ood on its own without the verifiable signature that's associated with it a= nd the request. What I'm saying is that you introspect the identifier and g= et back something that lets you, the RS, check the signature. =C2=A0-- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. =C2=A0POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think. =C2=A0Otherwise I can as= an attacker take that toklen and get info about it that might be useful, a= nd I don't think that's what we want. -bill ------=_Part_3267265_2097723159.1417547353922 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fetching the public key for a token might b= e fine, but what if the introspection endpoint returns the symmetric key? &= nbsp;Data about the user?  Where does this blur the line between this = and "act on behalf of"?


= On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mit= re.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it and the request. What I'm saying is th= at you introspect the identifier and get back something that lets you, the = RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill = Mills <wmills_92105@yahoo.com> wrote:
"However, I think it's very cle= ar how PoP tokens would work. ..."

I don't know if that's true.  POP toke= ns (as yet to be fully defined) would then also have a TLS or transport sec= urity requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and ge= t info about it that might be useful, and I don't think that's what we want= .

-bill




=
------=_Part_3267265_2097723159.1417547353922-- From nobody Tue Dec 2 11:13:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612BB1A6FC9 for ; Tue, 2 Dec 2014 11:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMESlY_zxUsn for ; Tue, 2 Dec 2014 11:13:19 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 638081A6FB7 for ; Tue, 2 Dec 2014 11:13:18 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1970572E1B2; Tue, 2 Dec 2014 14:13:18 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 0BDF172E1BB; Tue, 2 Dec 2014 14:13:18 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 14:13:17 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoA= Date: Tue, 2 Dec 2014 19:13:16 +0000 Message-ID: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> References: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> <244078391.3267266.1417547353925.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> In-Reply-To: <244078391.3267266.1417547353925.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_46D29E355A694687BC4445462DEA8D47mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2gR-wlZ333tJz4DYXXXJ5pqJDqA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:13:25 -0000 --_000_46D29E355A694687BC4445462DEA8D47mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token. Can you explain how this is related to "act on behalf of"? I don't see any = connection. -- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? Data about the user? Where does= this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." > wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill --_000_46D29E355A694687BC4445462DEA8D47mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <29A28B68A0874D468B5E8A849AE1AE65@imc.mitre.org> Content-Transfer-Encoding: quoted-printable That's all fine -- it's all going over TLS anyway (RS->AS) just like the= original token fetch by the client (C->AS). Doesn't mean you need TLS *= into* the RS (C->RS) with a good PoP token. 

Can you explain how this is related to "act on behalf of"? I= don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be = fine, but what if the introspection endpoint returns the symmetric key? &nb= sp;Data about the user?  Where does this blur the line between this and "act on behalf of"?


On Tuesday, Decembe= r 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has= a TLS requirement, but the call to the RS wouldn't necessarily have that r= equirement. The signature and the token identifier are two different things= . The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated wit= h it and the request. What I'm saying is that you introspect the identifier= and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, B= ill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's ver= y clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think.  Otherwise I can as= an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill





--_000_46D29E355A694687BC4445462DEA8D47mitreorg_-- From nobody Tue Dec 2 11:19:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F101A1B60 for ; Tue, 2 Dec 2014 11:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beMrVYjDP24p for ; Tue, 2 Dec 2014 11:19:09 -0800 (PST) Received: from BLU004-OMC4S16.hotmail.com (blu004-omc4s16.hotmail.com [65.55.111.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FEC1A6F17 for ; Tue, 2 Dec 2014 11:19:08 -0800 (PST) Received: from BLU406-EAS294 ([65.55.111.135]) by BLU004-OMC4S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 11:19:08 -0800 X-TMN: [oTvVtzt1a7FnmASHzolmiQdPURFtk+FQ] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/mixed; boundary="===============0763700109==" MIME-Version: 1.0 X-Client-ID: 498 X-Mailer: BlackBerry Email (10.2.1.3442) Date: Wed, 3 Dec 2014 02:19:04 +0700 From: Panca Agus Ananda To: X-OriginalArrivalTime: 02 Dec 2014 19:19:08.0082 (UTC) FILETIME=[D8382120:01D00E64] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QJGvtE-YgBgv6tBhuUAxBQZSEgw Cc: Outlook Traveller Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:19:15 -0000 --===============0763700109== Content-Type: multipart/alternative; boundary="_8cd6cfda-8210-4e67-b257-4185fb764dae_" --_8cd6cfda-8210-4e67-b257-4185fb764dae_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Panca.blogspot.com Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Rabu=2C 3 Desember 2014 02.06 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 74=2C Issue 21 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Notes on draft-ietf-oauth-introspection-01 (Richer=2C Justin P.) 2. Re: Review of draft-ietf-oauth-introspection-01 (Richer=2C Justin P.) ---------------------------------------------------------------------- Message: 1 Date: Tue=2C 2 Dec 2014 18:53:25 +0000 From: "Richer=2C Justin P." To: Thomas Broyer Cc: "" Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01 Message-ID: Content-Type: text/plain=3B charset=3D"windows-1252" Thomas=2C thanks for the review. Responses inline. On Dec 2=2C 2014=2C at 11:08 AM=2C Thomas Broyer > wrote: Hi=2C Here are some notes about draft-ietf-oauth-introspection-01. Background: I have implemented and deployed -00 (actually that was some ver= sion of the individual draft=2C before it got adopted by the WG)=2C current= ly with only a couple "clients" (out of 20 or so OAuth 2.0 clients currentl= y=2C only a couple expose resources themselves and thus need the introspect= ion endpoint=3B we otherwise have many resources exposed by the same piece = of software as the AS so they use internal means of validating the token wi= thout the need for the introspection endpoint). resource_id OPTIONAL. A service-specific string identifying the resource that the token is being used for. This value allows the protected resource to convey to the authorization server the context in which the token is being used at the protected resource=2C allowing the authorization server to tailor its response accordingly if desired. I think it should be noted somewhere that it's totally OK for the introspec= tion endpoint to tailor the response to the resource server making the requ= est too=2C independently of whether there's a resource_id or not. With "tai= loring the response" meaning that it could return active:false even if the = token is active but the AS doesn't want the RS to know about it (because=2C= for example=2C it knows that the token doesn't grant any scope that the RS= accepts=2C and therefore couldn't be used at the RS)=2C or limiting the re= turned list of scopes to the ones the AS knows the RS handles. This is very true=2C we should call that out explicitly in the description = of the response. Thanks! As far as resource_id is concerned=2C I really think an example would make = things clearer (what kind of value could be used in a real scenario=2C etc.= ? there's been a mail earlier today assuming it would be a URL=2C which I = assume to mean the URL of the resource that received the token and needs to= introspect it to allow access or not=3B my interpretation of the draft ini= tially was that it would rather be identifiers as can be seen for scopes=2C= or a resource-set ID ) My thought on this was that it would be the URL in many cases=2C but I want= to keep it as a generic string to allow for resource sets or other identif= ying mechanisms. This is going to have to be something that's agreed on bet= ween the AS and RS if it's going to mean anything. I agree on adding it to = at least one of the examples. The methods of managing and validating these authentication credentials are out of scope of this specification=2C though it is RECOMMENDED that these credentials be distinct from those used at an authorization server's token endpoint. and later in the Security Considerations section: The authorization server SHOULD issue credentials to any protected resources that need to access the introspection endpoint=2C SHOULD require protected resources to be specifically authorized to call the introspection endpoint=2C and SHOULD NOT allow a single piece of software acting as both a client and a protected resource to re- use the same credentials between the token endpoint and the introspection endpoint. Could you expand on the RECOMMENDED and SHOULD NOT here? What would be the problem with using the same credentials? What's the trade= -off? Different credentials for different purposes=2C and it lets you manage thin= gs separately at the server. In other words=2C you've got one class of thin= g that *gets* tokens=2C and one class of thing that *accepts* tokens. The d= ynamic resource registration draft doesn't presume client credentials at al= l=2C since a resource might not (and in many cases is not) also an OAuth cl= ient. This draft even uses tokens to authorize its calls to the introspecti= on endpoint=2C which was suggested as MTI in another thread. Additionally=2C and this may be getting unnecessarily colored by our own im= plementation and deployment of pre-WG drafts: we have it currently implemen= ted such that both are clients (and Ping does something similar with their = own method of accomplishing the same thing)=2C and we want to start to keep= these classes separate. We've found that developers get confused about whe= ther they're a client or a resource or whatnot as it is. This recommendatio= n helps keep the roles separate logically=2C though servers are of course f= ree to throw everyone in the same bucket if they so choose. The response MAY be cached by the protected resource=2C and the authorization server SHOULD communicate appropriate cache controls using applicable HTTP headers. Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf= .org/html/rfc7231)=2C it's not clear to me how cache headers would really h= elp=2C given that the requests to the introspection endpoint are mostly usi= ng the POST method ("optionally" a GET method=2C and the Security Considera= tions section somehow discourages it). You'd want to check with the HTTPWG but maybe this text should define what = the cache-key would be (it would at least include the token and resource_id= if provided=2C maybe also the token_type_hint)=2C and that the response SH= OULD NOT have Cache-Control:public or even s-maxage (for the same reason th= at it should be protected by authentication). I'd actually rather say that the RS may cache the response (we're talking a= bout an "application-level cache" here=2C not an HTTP cache)=2C and probabl= y should do it for a small amount of time=3B and possibly (not sure how wel= l that would fit here) hint that the AS could very well return an HTTP 429 = (Too Many Requests) if it somehow det= ects that the RS doesn't use a (application-level) cache (e.g. asks many ti= mes for the same token in a very short time frame). This is the kind of thi= ngs I could very well add to my implementation later on if we ever see a ve= ry high number of requests on our introspection endpoint (because looking u= p a key-value store using the token as key is much faster than validating t= he token ? our tokens are base64url-encoded JSON structures containing an I= D and a salt=2C and we store the ID and a hash in our datastore=3B validati= ng a token thus involves decoding base64url=2C parsing JSON and computing a= hash=2C in addition to looking it up in the datastore and validating "iat" and "exp"). All that we're really trying to say here is that the protected resource is = allowed to cache the response if it wants to=2C and that the AS could give = some hints as to how to do it. I can pull out the HTTP-cache-mechanism lang= uage if it's just confusing the matter (which I suspect it is). In one depl= oyment profile I've written of this=2C we say that the RS can cache the int= rospection result for up to half the token lifetime=2C given by the 'exp' c= laim (which we also require in the profile). If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and its credentials are invalid=2C the authorization server responds with an HTTP 400 (Bad Request) as described in section 5.2 of OAuth 2.0 [RFC6749]. Either I don't understand what "OAuth 2.0 client credentials" actually mean= s=2C or that section should mention HTTP 401 (Unauthorized). (we use HTTP Basic auth FWIW so=2C per the HTTP spec=2C we return a 401 for= bad credentials). If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint and the token used for authorization does not contain sufficient privileges or is otherwise invalid for this request=2C the authorization server responds with an HTTP 400 code as described in section 3 of OAuth 2.0 Bearer Token Usage [RFC6750]. Same here=3B unless you use the "Form-Encoded Body Parameter" or "URL Query= Parameter" means of sending a Bearer token=2C the status code would be a 4= 01. BTW=2C if an introspection endpoint MAY support those means of authenticati= ng a RS=2C then it should be more clearly stated in the draft that it is al= lowed and left at the discretion of the implementation. As an implementer= =2C unless I'm told that I could use access_token in the request body=2C I = would assume only the Authorization header is accepted. Noted=2C I'll change these to 401. Thanks very much! -- Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue=2C 2 Dec 2014 19:05:02 +0000 From: "Richer=2C Justin P." To: Bill Mills Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: <131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org> Content-Type: text/plain=3B charset=3D"us-ascii" The call to introspection has a TLS requirement=2C but the call to the RS w= ouldn't necessarily have that requirement. The signature and the token iden= tifier are two different things. The identifier doesn't do an attacker any = good on its own without the verifiable signature that's associated with it = and the request. What I'm saying is that you introspect the identifier and = get back something that lets you=2C the RS=2C check the signature. -- Justin On Dec 2=2C 2014=2C at 1:40 PM=2C Bill Mills > wrote: "However=2C I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful=2C and I don= 't think that's what we want. -bill On Tuesday=2C December 2=2C 2014 6:06 AM=2C Justin Richer > wrote: Hannes=2C thanks for the review. Comments inline. On 12/2/2014 6:23 AM=2C Hannes Tschofenig wrote: Hi Justin=2C I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties=2C the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to = say "client or protected resource" throughout=2C but in a few years of depl= oyment experience it's become clear that it's pretty much just protected re= sources that need to do introspection so I changed that text throughout. I = don't think that "introspection client" will help here because the party al= ready has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for = bearer tokens=2C since that's the only OAuth token type that's defined publ= icly right now=2C and that the details for PoP will have to be specified in= another spec -- that's exactly what Appendix C is there for=2C and if that= can be clearer=2C please suggest better text. However=2C I think it's very clear how PoP tokens would work. You send the = value returned as the "access_token" in the token endpoint response=2C whic= h is effectively the public portion of the PoP token. Just like a bearer to= ken=2C this value is passed as-is from the client to the RS and would be pa= ssed as-is from the RS to the AS during introspection. The AS can then use = that to look up the key and return it in an as-yet-unspecified field so tha= t the RS can validate the request. The RS wouldn't send the signature or si= gned portion of the request for the AS to validate -- that's a bad idea. Bu= t these are all details that we can work out in the PoP-flavored extension.= As I noted in the other thread=2C we'll have to make a similar extension f= or Revocation=2C so I still don't think it makes sense to hold up this work= and wait for PoP to be finished because it's useful now=2C as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics=2C at least on the wire= =2C and add additional fields. It probably makes sense to just inherit the = JWT registry=2C so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted=2C will add. Of course=2C there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific=2C in which case it w= ouldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token=2C which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case=2C to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST=2C since as far as I'm aware that's how it works in = all existing implementations (can anyone else comment on this?). I'm less c= omfortable with making one particular mechanism MTI=2C since I know of impl= ementations that use either a special set of credentials passed just like c= lient credentials to the token endpoint=2C or an OAuth token specifically f= or the introspection endpoint. If we do standardize on one MTI form=2C I'd = suggest that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted=2C thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that=2C didn't want to offend the SAML cabal but we can cut i= t. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error=2C really. It's a valid request and valid response saying= that token isn't any good. It would be easy enough to change the returned = error code on the {active:false} response=2C but to which code? The request= isn't Forbidden=2C or Not Found (the token could have been found but it's = been deactivated or just not available to the RS that's asking for it)=2C o= r Unauthorized=2C or even a Bad Request. So my logic is that the response i= s "OK"=2C but the content of the response tells you the metadata about the = token=2C which is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token=2C Client/client= =2C etc. issue. Thanks=2C still breaking old Bad Habits of capitalizing Terms In The Docume= nt. Tried to clean it up=2C will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource=2C only that they must have an agreement on the tokens themselves=2C there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course=2C there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell=2C I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically=2C it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference= this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 74=2C Issue 21 ************************************* --_8cd6cfda-8210-4e67-b257-4185fb764dae_ MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Panca.blogspot.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Rabu=2C 3 Desember 2014 02.06
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 74=2C Issue 21

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Notes on draft-ietf-oauth-introspection-01 (Richer= =2C Justin P.)
 =3B =3B 2. Re: Review of draft-ietf-oauth-introspection-01
 =3B =3B =3B =3B =3B (Richer=2C Justin P.)


----------------------------------------------------------------------

Message: 1
Date: Tue=2C 2 Dec 2014 18:53:25 +=3B0000
From: "=3BRicher=2C Justin P."=3B <=3Bjricher@mitre.org>=3B
To: Thomas Broyer <=3Bt.broyer@gmail.com>=3B
Cc: "=3B<=3Boauth@ietf.org>=3B"=3B <=3Boauth@ietf.org>=3B Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01
Message-ID: <=3BD807C922-808E-445B-A9F2-D1C8DAEE1BF5@mitre.org>=3B
Content-Type: text/plain=3B charset=3D"=3Bwindows-1252"=3B

Thomas=2C thanks for the review. Responses inline.

On Dec 2=2C 2014=2C at 11:08 AM=2C Thomas Broyer <=3Bt.broyer@gmail.com&l= t=3Bmailto:t.broyer@gmail.com>=3B>=3B wrote:

Hi=2C

Here are some notes about draft-ietf-oauth-introspection-01.
Background: I have implemented and deployed -00 (actually that was some ver= sion of the individual draft=2C before it got adopted by the WG)=2C current= ly with only a couple "=3Bclients"=3B (out of 20 or so OAuth 2.0 cl= ients currently=2C only a couple expose resources themselves and thus need the introspection endpoint=3B we otherwise have many resourc= es exposed by the same piece of software as the AS so they use internal mea= ns of validating the token without the need for the introspection endpoint)= .


 =3B =3B resource_id =3B OPTIONAL. =3B A service-specific s= tring identifying the
 =3B =3B =3B =3B =3B resource that the token is being u= sed for. =3B This value allows the


 =3B =3B =3B =3B =3B protected resource to convey to th= e authorization server the
 =3B =3B =3B =3B =3B context in which the token is bein= g used at the protected
 =3B =3B =3B =3B =3B resource=2C allowing the authoriza= tion server to tailor its response
 =3B =3B =3B =3B =3B accordingly if desired.


I think it should be noted somewhere that it's totally OK for the introspec= tion endpoint to tailor the response to the resource server making the requ= est too=2C independently of whether there's a resource_id or not. With &quo= t=3Btailoring the response"=3B meaning that it could return active:false even if the token is active but the AS doesn'= t want the RS to know about it (because=2C for example=2C it knows that the= token doesn't grant any scope that the RS accepts=2C and therefore couldn'= t be used at the RS)=2C or limiting the returned list of scopes to the ones the AS knows the RS handles.

This is very true=2C we should call that out explicitly in the description = of the response. Thanks!


As far as resource_id is concerned=2C I really think an example would make = things clearer (what kind of value could be used in a real scenario=2C etc.= ? there's been a mail earlier today assuming it would be a URL=2C which I = assume to mean the URL of the resource that received the token and needs to introspect it to allow access or not= =3B my interpretation of the draft initially was that it would rather be id= entifiers as can be seen for scopes=2C or a resource-set ID <=3Bhttps= ://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03>=3B )

My thought on this was that it would be the URL in many cases=2C but I want= to keep it as a generic string to allow for resource sets or other identif= ying mechanisms. This is going to have to be something that's agreed on bet= ween the AS and RS if it's going to mean anything. I agree on adding it to at least one of the examples.



 =3B =3B The methods of managing and
 =3B =3B validating these authentication credentials are out of sco= pe of this
 =3B =3B specification=2C though it is RECOMMENDED that these crede= ntials be
 =3B =3B distinct from those used at an authorization server's toke= n endpoint.

and later in the Security Considerations section:


 =3B =3B The authorization server SHOULD issue credentials to any  =3B =3B protected resources that need to access the introspection = endpoint=2C
 =3B =3B SHOULD require protected resources to be specifically auth= orized to
 =3B =3B call the introspection endpoint=2C and SHOULD NOT allow a = single piece
 =3B =3B of software acting as both a client and a protected resour= ce to re-
 =3B =3B use the same credentials between the token endpoint and th= e
 =3B =3B introspection endpoint.

Could you expand on the RECOMMENDED and SHOULD NOT here?
What would be the problem with using the same credentials? What's the trade= -off?

Different credentials for different purposes=2C and it lets you manage thin= gs separately at the server. In other words=2C you've got one class of thin= g that *gets* tokens=2C and one class of thing that *accepts* tokens. The d= ynamic resource registration draft doesn't presume client credentials at all=2C since a resource might not (and in ma= ny cases is not) also an OAuth client. This draft even uses tokens to autho= rize its calls to the introspection endpoint=2C which was suggested as MTI = in another thread.

Additionally=2C and this may be getting unnecessarily colored by our own im= plementation and deployment of pre-WG drafts: we have it currently implemen= ted such that both are clients (and Ping does something similar with their = own method of accomplishing the same thing)=2C and we want to start to keep these classes separate. We've found= that developers get confused about whether they're a client or a resource = or whatnot as it is. This recommendation helps keep the roles separate logi= cally=2C though servers are of course free to throw everyone in the same bucket if they so choose.



 =3B =3B The response MAY be cached by the protected resource=2C an= d the
 =3B =3B authorization server SHOULD communicate appropriate cache = controls
 =3B =3B using applicable HTTP headers.


Reading through https://too= ls.ietf.org/html/rfc7234 (and https://tools.ietf.org/html= /rfc7231)=2C it's not clear to me how cache headers would really help= =2C given that the requests to the introspection endpoint are mostly using = the POST method ("=3Boptionally"=3B a GET method=2C and the Security Considerations section somehow discourages it).
You'd want to check with the HTTPWG but maybe this text should define what = the cache-key would be (it would at least include the token and resource_id= if provided=2C maybe also the token_type_hint)=2C and that the response SH= OULD NOT have Cache-Control:public or even s-maxage (for the same reason that it should be protected by authenti= cation).
I'd actually rather say that the RS may cache the response (we're talking a= bout an "=3Bapplication-level cache"=3B here=2C not an HTTP cache)= =2C and probably should do it for a small amount of time=3B and possibly (n= ot sure how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) <=3Bhttps://tools.ietf.org/html/rfc6585&= gt=3B if it somehow detects that the RS doesn't use a (application-level) c= ache (e.g. asks many times for the same token in a very short time frame). This is the kind of things I could very well = add to my implementation later on if we ever see a very high number of requ= ests on our introspection endpoint (because looking up a key-value store us= ing the token as key is much faster than validating the token ? our tokens are base64url-encoded JSON structur= es containing an ID and a salt=2C and we store the ID and a hash in our dat= astore=3B validating a token thus involves decoding base64url=2C parsing JS= ON and computing a hash=2C in addition to looking it up
 =3B in the datastore and validating "=3Biat"=3B and "=3Bex= p"=3B).

All that we're really trying to say here is that the protected resource is = allowed to cache the response if it wants to=2C and that the AS could give = some hints as to how to do it. I can pull out the HTTP-cache-mechanism lang= uage if it's just confusing the matter (which I suspect it is). In one deployment profile I've written of this=2C= we say that the RS can cache the introspection result for up to half the t= oken lifetime=2C given by the 'exp' claim (which we also require in the pro= file).



 =3B =3B If the protected resource uses OAuth 2.0 client credential= s to
 =3B =3B authenticate to the introspection endpoint and its credent= ials are
 =3B =3B invalid=2C the authorization server responds with an HTTP = 400 (Bad
 =3B =3B Request) as described in section 5.2<=3Bhttps= ://tools.ietf.org/html/draft-ietf-oauth-introspection-01#section-5.2>= =3B of OAuth 2.0 [RFC6749<=3Bhttps://tools.ietf.org/html/rfc6749>=3B].<= br>
Either I don't understand what "=3BOAuth 2.0 client credentials"=3B= actually means=2C or that section should mention HTTP 401 (Unauthorized).<= br> (we use HTTP Basic auth FWIW so=2C per the HTTP spec=2C we return a 401 for= bad credentials).


 =3B =3B If the protected resource uses an OAuth 2.0 bearer token t= o authorize
 =3B =3B its call to the introspection endpoint and the token used = for
 =3B =3B authorization does not contain sufficient privileges or is= otherwise
 =3B =3B invalid for this request=2C the authorization server respo= nds with an
 =3B =3B HTTP 400 code as described in section 3<=3Bhttp= s://tools.ietf.org/html/draft-ietf-oauth-introspection-01#section-3>= =3B of OAuth 2.0 Bearer Token
 =3B =3B Usage [RFC6750<=3Bhttps://tools.ietf.org/html/rfc6750>= =3B].

Same here=3B unless you use the "=3BForm-Encoded Body Parameter"=3B= or "=3BURL Query Parameter"=3B means of sending a Bearer token=2C = the status code would be a 401.
BTW=2C if an introspection endpoint MAY support those means of authenticati= ng a RS=2C then it should be more clearly stated in the draft that it is al= lowed and left at the discretion of the implementation. As an implementer= =2C unless I'm told that I could use access_token in the request body=2C I would assume only the Authorization header is acc= epted.

Noted=2C I'll change these to 401.

Thanks very much!
 =3B-- Justin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141202/ed245936/attachment.html>=3B

------------------------------

Message: 2
Date: Tue=2C 2 Dec 2014 19:05:02 +=3B0000
From: "=3BRicher=2C Justin P."=3B <=3Bjricher@mitre.org>=3B
To: Bill Mills <=3Bwmills_92105@yahoo.com>=3B
Cc: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <=3B131139F2-0F73-4315-B52A-9F609B55EF4C@mitre.org>=3B
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B

The call to introspection has a TLS requirement=2C but the call to the RS w= ouldn't necessarily have that requirement. The signature and the token iden= tifier are two different things. The identifier doesn't do an attacker any = good on its own without the verifiable signature that's associated with it and the request. What I'm saying is th= at you introspect the identifier and get back something that lets you=2C th= e RS=2C check the signature.

 =3B-- Justin

On Dec 2=2C 2014=2C at 1:40 PM=2C Bill Mills <=3Bwmills_92105@yahoo.com&l= t=3Bmailto:wmills_92105@yahoo.com>=3B>=3B wrote:

"=3BHowever=2C I think it's very clear how PoP tokens would work. ...&q= uot=3B

I don't know if that's true. =3B POP tokens (as yet to be fully defined= ) would then also have a TLS or transport security requirement unless there= is token introspection client auth in play I think. =3B Otherwise I ca= n as an attacker take that toklen and get info about it that might be useful=2C and I don't think that's what we want.
-bill



On Tuesday=2C December 2=2C 2014 6:06 AM=2C Justin Richer <=3Bjricher@mit= .edu<=3Bmailto:jricher@mit.edu>=3B>=3B wrote:


Hannes=2C thanks for the review. Comments inline.

On 12/2/2014 6:23 AM=2C Hannes Tschofenig wrote:

Hi Justin=2C

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "=3Bclient"=3B already has a meaning in OAuth. Here the client= of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties=2C the introspection client and the introspection server.

I tried to avoid the word "=3Bclient"=3B for this very reason. The = draft used to say "=3Bclient or protected resource"=3B throughout= =2C but in a few years of deployment experience it's become clear that it's= pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "=3Bintrospectio= n client"=3B will help here because the party already has a name from O= Auth and we should inherit it.


* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well.

I think the document should be clear that it *specifies* the mechanism for = bearer tokens=2C since that's the only OAuth token type that's defined publ= icly right now=2C and that the details for PoP will have to be specified in= another spec -- that's exactly what Appendix C is there for=2C and if that can be clearer=2C please suggest be= tter text.

However=2C I think it's very clear how PoP tokens would work. You send the = value returned as the "=3Baccess_token"=3B in the token endpoint re= sponse=2C which is effectively the public portion of the PoP token. Just li= ke a bearer token=2C this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS durin= g introspection. The AS can then use that to look up the key and return it = in an as-yet-unspecified field so that the RS can validate the request. The= RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad id= ea. But these are all details that we can work out in the PoP-flavored exte= nsion. As I noted in the other thread=2C we'll have to make a similar exten= sion for Revocation=2C so I still don't think it makes sense to hold up this work and wait for PoP to be finished = because it's useful now=2C as-is.


* Meta-Information

You have replicated a lot of the claims defined in
= https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

The idea was to inherit JWT's syntax and semantics=2C at least on the wire= =2C and add additional fields. It probably makes sense to just inherit the = JWT registry=2C so we can do that.


When you write:

"=3B
The endpoint MAY allow other parameters to provide further context to
the query.
"=3B

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Noted=2C will add.


Of course=2C there is the question whether any of those would be security critical and hence ignoring them would cause problems?!

Anything security critical would be provider-specific=2C in which case it w= ouldn't ignore them.


* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token=2C which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself.=

In any case=2C to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between the AS and the RS.

I had similar thoughts when putting draft -01 together but didn't want to m= ake a normative change like that without the WG input. I'm fine with streng= thening this to a MUST=2C since as far as I'm aware that's how it works in = all existing implementations (can anyone else comment on this?). I'm less comfortable with making one partic= ular mechanism MTI=2C since I know of implementations that use either a spe= cial set of credentials passed just like client credentials to the token en= dpoint=2C or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form=2C I'= d suggest that we make it the OAuth bearer token.


* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

Noted=2C thanks.


* Minor items

You write:

"=3B
These include using
 =3B =3B structured token formats such as JWT [JWT] or SAML [[ Edit= or's Note:
 =3B =3B Which SAML document should we reference here? ]] and propr= ietary
 =3B =3B inter-service communication mechanisms (such as shared dat= abases and
 =3B =3B protected enterprise service buses) that convey token info= rmation.
"=3B

Just reference the JWT since that's what we standardize.

I'm fine with that=2C didn't want to offend the SAML cabal but we can cut i= t.


* 'Active' claim

you write:
"=3B
 =3B =3B active =3B REQUIRED. =3B Boolean indicator of whet= her or not the presented
 =3B =3B =3B =3B =3B token is currently active. =3B= The authorization server determines
 =3B =3B =3B =3B =3B whether and when a given token is = in an active state.
"=3B

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

It's not an error=2C really. It's a valid request and valid response saying= that token isn't any good. It would be easy enough to change the returned = error code on the {active:false} response=2C but to which code? The request= isn't Forbidden=2C or Not Found (the token could have been found but it's been deactivated or just not availabl= e to the RS that's asking for it)=2C or Unauthorized=2C or even a Bad Reque= st. So my logic is that the response is "=3BOK"=3B=2C but the conte= nt of the response tells you the metadata about the token=2C which is that it's not active.


* Capitalization

Reading through the text I see bearer token/Bearer Token=2C Client/client= =2C
etc. issue.

Thanks=2C still breaking old Bad Habits of capitalizing Terms In The Docume= nt. Tried to clean it up=2C will do more.


* AS <=3B->=3B RS relationship

You write:
"=3B
 =3B =3B Since
 =3B =3B OAuth 2.0 [RFC6749] defines no direct relationship between= the
 =3B =3B authorization server and the protected resource=2C only th= at they must
 =3B =3B have an agreement on the tokens themselves=2C there have b= een many
 =3B =3B different approaches to bridging this gap.
"=3B

I am not sure what you mean by "=3Bdefines no relationship"=3B betw= een the AS
and the RS. Of course=2C there is a relationship. The AS issues tokens for<= br> access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell=2C I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.

What I was trying to point out is that it doesn't define the nature of the = relationship between the two components. Specifically=2C it says:


 =3B =3B The methods used by the resource
 =3B =3B server to validate the access token (as well as any error = responses)
 =3B =3B are beyond the scope of this specification but generally i= nvolve an
 =3B =3B interaction or coordination between the resource server an= d the
 =3B =3B authorization server.

This spec provides one mechanism for this validation. So we could reference= this directly if that's helpful.


 =3B -- Justin


Ciao
Hannes





_______________________________________________
OAuth mailing list
OAuth@ietf.org<=3Bmailto:OAuth@ietf.org= >=3B
https://www.ietf.or= g/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org<=3Bmailto:OAuth@ietf.org= >=3B
https://www.ietf.or= g/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org<=3Bmailto:OAuth@ietf.org= >=3B
https://www.ietf.or= g/mailman/listinfo/oauth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141202/de09852b/attachment.html>=3B

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest=2C Vol 74=2C Issue 21
*************************************
--_8cd6cfda-8210-4e67-b257-4185fb764dae_-- --===============0763700109== Content-Type: text/x-vcard; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Outlook Traveller.vcf" QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpQUk9ESUQ6LS8vUmVzZWFyY2ggSW4gTW90aW9uLy9S SU0gQXBwLy9FTg0KVUlEOjA0N2JlNjQwLTdhNTgtMTFlNC1hYzY5LWQxZDUxYjU2NGM1MA0KRU1B SUw7VFlQRT1IT01FOnBhbmNhX2Fzc2FhZkB5YWhvby5jb20NCkVNQUlMO1RZUEU9SE9NRTpwYW5j YV9hc3NhYWZAeWFob28uY29tDQpFTUFJTDtUWVBFPUlOVEVSTkVUOlJpY29hZnJpemFsNzFAZ21h aWwuY29tDQpFTUFJTDtUWVBFPUlOVEVSTkVUOnBhbmNhNzBAb3V0bG9vay5jb20NCkVNQUlMO1RZ UEU9SE9NRTpwYW5jYV9hc3NhYWZAeWFob28uY29tDQpFTUFJTDtUWVBFPVdPUks6cGFuY2FfYXNz YWFmQHlhaG9vLmNvLmlkDQpFTUFJTDtUWVBFPUlOVEVSTkVUOnBhbmNhX2Fzc2FhZkB5YWhvby5j b20NCkZOOk91dGxvb2sgVHJhdmVsbGVyDQpOOlRyYXZlbGxlcjtPdXRsb29rOzs7DQpOSUNLTkFN RTpwYW5jYSBhZ3VzIGFuYW5kYQ0KT1JHOlJpYW5uZ3JvdXBzOzsNClBIT1RPO1RZUEU9UE5HO0VO Q09ESU5HPUI6aVZCT1J3MEtHZ29BQUFBTlNVaEVVZ0FBQUNBQUFBQWdDQUlBQUFEOEdPMmpBQUFB QTNOQ1NWUUlDQWpiNFUvZ0FBQUFDWEJJV1hNQUFBdUpBQUFMaVFFM3ljdXRBQUFJakVsRVFWUklp YVZXYVd4YzFSbjk3dkxlTE00c0hzY2I5bUJueG1QakxRa3hkY0lTUW9CRUJ1T0VWbTFwNlEra0xL NUFxa3JWcW9XcVZWc3FVVkJGYVNzRkNrb1JLVlVMU2dOT2pBT2lDVXVEeVdTMTQvRTI5c3pFay9F ZWV6eUxQY3VidS9SSGh1ZlFCU3IxL256bnZITys3VjU5Q0Q3L1lHU3FhakJXMVJzcjNRZ1JwY1FK QUxuNWlKUThNeG5NaEVmUzRXRVE4bk1FMEg5VlhtTXR2SzNEMHJERndsT2JLeXk3dnRUb2NWV3ZL eThGZ01zemMrT2hpV1BuaHM1TUpaUEVuQnoyTG4zU0xaWVQvN01CVld4YjduZmNjdmZORnY3TUl4 MDFMcmRFc0pMT1RpNGxOU1lBb01CSVN5MEZCU1lEa2hBSUJaODQxTjJYSk5Iejc4ZTl4NEhsdnNB QXI3R1dQdmpvamNXT2x6dDNOZGZWelNhVy8rb2RlZDA3a2tpbGtlQUlBd0JJQVJJVHE5bjBqUzMx Mzl4U1gyWmQ0L1A3TzE4K2R1VnFkSzdyeFg5SjVUTUdTb216L0t2ZnViZlNmUENKeDVZMTdXZEhU dlgwanhPUUFoT0JzQVI4M1c4Q1M0RUY1NERhTjNwKy9wVTdMQWJEdm1kZU9EbVZuajc4Kzl4OFJH ZVM2Mk92ZlBpSGU1cUxuM3Q4LzBCa3Z2MzV2d1ZtNWdGVFRsU0pDQkNDTUVJSUk0UVJSb0N4UUZo aVNrQ0dwK2RlNlIyOHU2RjZUOXUyUkdROFdOeWNIRGtqdGV4bkRRZ3UrOXAzZDdnY3YzbDhmL2Vs OFVmLzJJTkZqaVBLc1FJQVJBb3NPWllDUzRrbHc0SmpDUUFTQUdGQVJMQWZ0YlZzYi9JQXdMWmJO dm91OWMydXJWc2VPZzFTcmhyWWJ0OVZVK3M1OXN2dkRVVG1ILzNEbThaY0NvU1FtR0NFTU12ZzdJ ckNzb1JsS2MrU1hKYmtzb1JsZ1d1WVVDSzVDWW5uOSs3R0tGL3QzVnRiai9SZVRHSno5b29mQUNn QUVJdk4zckw5WU9kOUFtU1p6WHorMmNleU9TWTQvT1gwcFpjK0dQaCsrKzI3TnRWSzREa3VKNjlH cldaVGtkVXNFT1NZZk9EWGIrUWtxQW9sYUxVOUFQRHl2dDBkM0xoODZVT2VqRk1Bc0xlMnRWaEZR NjBIQUVxc2F3QmdLWmw2cDIvczNZRVFFTnJWTjg0WTI5NTRvN3VzcE14dUJRQXA1WjgrUERjWlcy RlNBcUVyV25vNkdydkJZZGNObW02cWE3RytzOXphdG5qeURRS3FXdnJBL2tPZDdUYTdYVTl6T1pQ OXdhczlVUTBZVWFOcDdVSWdNcnNZdlc5VGZYNkVFSHFydDYrclA4U0l3aEhGQUF2eHhJNzFIdDBn a2Nsc2RwY2ZEbXV4aXlkeGdYdTluU1ZyWE83M2ZKZDFScG5kdXRacUJBQUppQ0hDQ1BVR3BwTHBs RTdZMFZJUEFCSVRnVEdqNm9uQmlhSEpPUjA5TVJ5dWRibnRMRm5nWG8rTnpycXRWWFlwNVMrTzlq TEc5QmpiYjc0SmdVUUlBVklFVlRXc2Z1QUw2UklicWlzVVlGZ0NRa2dpeWpIOTdkc2Y2K2pyWi8x U3lxMVZkcU96RHF0cks5cGJOeWJTV2pxZDlvNkhkZEsySmc4V09Td2xRa2dpTEREdE9qK2lveGFU c2RWZFFTUWpnQ1Fta3FnWEoyWVhFZ2tBRUNDdlRNMG4wbHA3NjBaMWJRVW1oU1hOdGRXUnBTU1Nj T1RNa0M1UlYxbnNNQ2dZV0Q0Sm92cW1GNi9HNHpwaDU0WTZEQnlRQkVRRUpvalF5WVVsQVBCUHpm RmNOaEtMTjlkV2s4SVNURlN6dytHSXAxTVVnM2M4RWt2bEM2MFFlaytUaTBpQmdFbU1BQ09FU0NL eCtzN2NVdXRVV0E1TEFVZ0FSZ0t3Z2hFQUhEMDdpa0VtMGptSHcwRlVjMzUrcFVRY2tSelFuZ3Vq dXNRZERldUlZQmdrbGdBQW5sSkxlVkdSanBiYnJMWGxEaUlGa2dJQUNnelV1YmFRUzNGeU1NQ0pv dE13MTFMUmFOUm1NZ3BNQktiZGZXTTZ0cVd1eWt5QUNvR0FVU0Z1clM0MW04MEQ0V21kY0ZlVGkz QkdwTVJTMUJWYlRBWmo3M0FvbHM1eFFxd21KUnFOY2kyRitkSzhiMnppUm9lVkl5d0pEYzRuUnFm bjlDcTExcFJqa2FOQ0dyQzhwOUUxTkRsejRIaXZibkI3UXczaEdwVk1FYXkxcWxoUmxMZjd4eEdo SEJTbjNlWWJtK0JMODFoYm1PbzUyMjgxcVJJd0lDU0ljdVRzYXBYdWJmWVFscU1pVzFOa3Fpb3Q3 ajduSDRwTXp5V1hyNkcxcFk1eXU0bHdSaVcvdTlHZDByTGV3SXpBaEFHeW10U2VzLzNhd2hUT1JQ eW53akdFME5jM3VSQ0F4T1FmSTFjNDU1L0c2S0l5aDRGdmRqck1adk5IdzVjRlV0LzArdkwxeGZn MlQ1WENzMjZiV2xGUzlKNHZrR0VjQUI1cThTQ0VUb1ZqbVlnZnJ3UUhZdFF5RmdydXZiTkpreGdR aVdhMTkwZnlkOHBpTURRN1M0eFM3R3gwOS9vbm90bGNUbEgvUGpTaHA3aTF5VU5ZNXVaS2g4bGtl cmN2S0FuT0lIWHZuUTFqb1dDTVdsYUNBeGcwTFRGMCtzbFhqMVVXMnU1cmNnSUlRUFRvT2Y5cUo5 ZDdxcXlxczZ5b3V5L0FxRWtRdzJRc05SaVp6UStycTh4U1lON2U2SXFsVWtPVGN3QzRyYkd5c3RE MjVLdkhrcjZQUWRNd0FNUzlQUmVUWkhEVS81UDIxcHpFRXFPKzhKeis4bXh2cnRubUxqT1l6R2RD TTV5cWpCbzRNUncrazcvVktsVyt2WE96cTdLODYveG9Ua0lhbEo4K3NIbHcxTisvVEdObjN3VUFE QUE4R1k5ZCtLRHo0RkdieWZUYW5oMFpTYmdVaDcyam44Njc1ZUcyTzAvNlFpdE1TcUlJcWdxcWZo S1laaUxmcDQ3VzlUYUw5Y1JnYUFVWi9yeDNwODFrNmp4NE5IcitmWjZNNXcwQUlPNDlmbVVwdmYv WkZ6YzZTMzYxdXpVTmh2ZDhBYjFLQlNaelY5OFl3d2FCRklFVWdkUzR4azhNQksraGhKREZsZlR3 MWVXbnYzenJSbWZKL21kZnZMS1VqbnVQNXdjaHI4RnljMTBIVHN4b1Q3MTBxR09ENTlDK3R0SEZW UGpxNGpVd3g5blFWQlFJRVpnQXhwSlFUdFczK2xZajZMa1VmR1hQL1IwYlBFKzlkT2pFakRiWGRV QmZrRmEzQ3BsSnBTZEdBbXViQndmNk85dnYrdFp0OVlPVGkrdUs3UURRZFc3a28vRnBSZzBTVXdT QWdHUE80NG5ZUTV0dlVpa0ZnTHJ5UXFmRHR1K1pGOTRNSm1ZTy80NHR6T2l5cXdZQXdGZml5WkV6 TTBXMVIwNzFiYTBwM1ZKZmMrMzdhOTZSMGRrNGdDUklZTUZsSnMwWW94amYyMWhkdE1ZRUFHT0Iw SU5QSHp3Zm5wOSs0em0yTkgrOTVuOWVIZTIzdHRzMjNkVmlGVTgvMGxIcmNrc0V5NWxzZUNGNXJi RkdTaW9jbGpXcWloQWFDd1YvZktqN1FnTEhMMzRZTzkzenhhdWpmdjU5K2EycmNWV1hsUURBeE95 OFB4RDZQNWJmNncvQnh1cUdndXBtd3czckpDS0drZ29BeU01UEljbXowNWRYSm55WmlXSGc0bk1F L2duYXpDYUtESjJya2dBQUFBQkpSVTVFcmtKZ2dnPT0NClRFTDtUWVBFPVdPUks6MzA2MTEzOA0K VEVMO1RZUEU9V09SSzo2MjgxMjcxMTExMTU1DQpURUw7VFlQRT1DRUxMOjA4MTI3MTExMTE1NQ0K VVJMOmh0dHBzOi8vcGx1cy5nb29nbGUuY29tLzEwNzA4MTE3NjcyOTM3NjU1MzYwNA0KVVJMOmh0 dHA6Ly93d3cuYmxvZ2dlci5jb20NClgtRkFDRUJPT0s6UGFuY2FfYXNzYWFmQHlhaG9vLmNvLmlk DQpYLUxJTktFRElOOlBhbmNhX2Fzc2FhZkB5YWhvby5jb20NClgtUklNLVBJTjoyQUUzRjRDNA0K WC1UV0lUVEVSOlBhbmNhYWd1c2FuYW5kYQ0KRU5EOlZDQVJEDQo= --===============0763700109==-- From nobody Tue Dec 2 11:25:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A439F1A6FCD for ; Tue, 2 Dec 2014 11:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-uBvx0fIRKC for ; Tue, 2 Dec 2014 11:25:04 -0800 (PST) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5367E1A6EDA for ; Tue, 2 Dec 2014 11:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417548303; bh=G1zUUIXUcuI9E/gsBTKelc4KAmYaFtsom+gFRoOhieM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lgul0131xpKjjppsughTO05+0tYF570lfmtLIDBJRPLxPAg2HkYERGAaQuTMCOjxalmPiQSobJH37BW842xhageKh+IszUWFUNwhsIlR+6ozqsjK5YyJ0nzIBuzEQi8VHVJoBmvmfEaIVduEypuEyRqIEoAlEl6gDHWbDqQXThei1wQZwW3VpJuzjNvRrQPB8QJW5wjXuXncxEIbsKmgPTplPQhynJ6iBaH16pr/rDsa1dNjbKbyAtf4HR0uhUXbvVb3Xq1oytfgDktu4ow5r0Cfu7oWDgTOzzKAp4C5/rh2wii7JTuxLBhl4HSKuVRmqFyhI744hdV8gt/03Qy75A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=hIidOl8lovwbKt7VZUbpfaIE6aDGMfBlM8YCp2D9Bp+M8ZvvHBwDwPNBYrLAl+Ifz9t78MY5OUtiM0GXGi5hMu5ivPTu+ZXur1nbYy2tr1XVZ/0u07kZ/rQyuFVQJOdGpYZTRIJd0h/8C2RZO6UbKwt6kYiom4b9AgbbtO/IZlFtCn1rFJd17j1Pbi+/rRTbgdIShyx6LNm9EpmOzaKuWrVDqZUVwsLbD1Ancl9Twjwv9qmabAX6xcbo6MLuUsQyIFqi+T6iJ1pAPMu4CKXUVCiiEmswOKgWpJUI6R2IVU4S6V3BKHBPdXO6zns+pMAQ4Ha60MppekrbOr4seSa2zQ==; Received: from [98.139.212.149] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000 Received: from [98.139.212.220] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 19:25:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 469752.26755.bm@omp1029.mail.bf1.yahoo.com X-YMail-OSG: qYU82DIVM1lIaunxtgB0HRZnNXPS5WO2MxGEjLEoT0wjp03jdGiHxmaJlKLCcCd H1dEg5ybw91Dzo99hbG3zAT4E4Qd0FoAkFh.FONeeEBz0KeKBweSvWU9KDszHCaEeVIKJniiPhjy nDqLV2OQW2LLzFMO8LQjZ9n6zy_dQOPbpLvp4bn2PLlFxFFdeACAafA7JETYFJqHyUuZRz07ASd1 Ve3spJWth0Ss6YbGvWwRziveCT7W9b4gKUiPMrBh.yN4cthTezxTKExxPKFdNmERJoo7Sh5wn2MS LRR9PzYri684JKaDBtDSbgytJKv_HhCE4LLZMmJ5K1_O6c0MR5QYfRRUGiIErFviKs9HJDS_XOBq EFf3S5E423rohx1W5dyEB.pFUy1jYQM5Iz8uoI6yf9g0qAel4Iv8kf.gUD7T.cPoom0.tFbQS13t IX7ILk3xHOn4CgIcDI3djXzDObWcea9LB0uEMR35w58bvAen52UEjj.B3tNSWUO9EoIZgJDKJoeI- Received: by 66.196.81.114; Tue, 02 Dec 2014 19:25:03 +0000 Date: Tue, 2 Dec 2014 19:25:02 +0000 (UTC) From: Bill Mills To: "Richer, Justin P." Message-ID: <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3962315_695460837.1417548302661" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fF8CGrHBNFJODvD3fPn54vvRLe0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:25:05 -0000 ------=_Part_3962315_695460837.1417548302661 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake.=20 On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." wrote: =20 That's all fine -- it's all going over TLS anyway (RS->AS) just like the o= riginal token fetch by the client (C->AS). Doesn't mean you need TLS *into*= the RS (C->RS) with a good PoP token.=C2=A0 Can you explain how this is related to "act on behalf of"? I don't see any = connection. =C2=A0-- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? =C2=A0Data about the user? =C2=A0= Where does this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. =C2=A0-- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. =C2=A0POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think. =C2=A0Otherwise I can as= an attacker take that toklen and get info about it that might be useful, a= nd I don't think that's what we want. -bill ------=_Part_3962315_695460837.1417548302661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token. 

Can you explain how this is related to "act on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf of"?


On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill







------=_Part_3962315_695460837.1417548302661-- From nobody Tue Dec 2 11:25:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05FA1A6FED for ; Tue, 2 Dec 2014 11:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocueyF9srGSk for ; Tue, 2 Dec 2014 11:25:20 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2721A1A51 for ; Tue, 2 Dec 2014 11:25:19 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so22076551wid.12 for ; Tue, 02 Dec 2014 11:25:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0RVazEGjlUr3ZJa/9p9egpoKO2+r4G43B/jVNZ70Fq4=; b=FP88SW8OqQCft52+ogKZBc7EyQAxehTSX+Bn2PdlUg5yOuhfU0Y3RS43FXcPOngRKC JAI8Nj5o037GeekCHxRs3HjIU/aXw6pdCgak6yGVvsfnOBEYQHuR4+R39pCFPiEzThzb b8V6MEFx90HiqPjGKUcyg02WU/0PCSgf8GpvN+zQXiZ7L0TwvB0xTHNfLGRSXiiS4Mfo xErAxpIQRV6ovX4zfmWldXOBd9PWkyg9NTniCbSVq78/qIQLUZUcM2JCAXoUB1KYS4mf z2tplswTTXVNuNkGIn8BxFdKUyY34Y78vdFHWN8u3CS7TJJKE6bEvp3dR1hf1AnMjhoG rbWg== X-Gm-Message-State: ALoCoQnF3J+swnQ4sJ4LVPQ16k1ofiBehhih2F9M0vJ6ka73PN4+VttmDCh3KSQj3+NJCFw8JdYi X-Received: by 10.194.71.45 with SMTP id r13mr1210991wju.128.1417548317846; Tue, 02 Dec 2014 11:25:17 -0800 (PST) Received: from [10.47.81.9] (host86-187-11-58.range86-187.btcentralplus.com. [86.187.11.58]) by mx.google.com with ESMTPSA id vy7sm33152832wjc.27.2014.12.02.11.25.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 11:25:16 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_EF1CD07B-520D-45DF-B405-C262B07E0700"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org> Date: Tue, 2 Dec 2014 16:25:17 -0300 Message-Id: <5F939C67-C677-4C8F-BCF3-BD93559D01E3@ve7jtb.com> References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org> To: "Justin P. Richer" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wbG1mZV2e1LEuav3ZFmsQxPDdQI Cc: Donald Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:25:25 -0000 --Apple-Mail=_EF1CD07B-520D-45DF-B405-C262B07E0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E2CC733D-B4AA-42E2-8C1F-1BCB22076C91" --Apple-Mail=_E2CC733D-B4AA-42E2-8C1F-1BCB22076C91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 > On Dec 2, 2014, at 3:19 PM, Richer, Justin P. = wrote: >=20 > No, this isn't an appropriate mapping in this case, especially if the = introspection endpoint is itself OAuth protected. You need to be able to = differentiate between the token being asked about and the token = authorizing the question. These error codes apply to the latter and = should not be conflated with the former. >=20 > -- Justin >=20 > On Dec 2, 2014, at 12:25 PM, Donald Coffin = > = wrote: >=20 >> Hi Justin, >> =20 >> I believe you will find the answer to which HTTP Status code the AS = should return if the token is INACTIVE in Section 3.1 Error Codes of = =93The OAuth 2.0 Framework: Bearer Token Usage=94 [RFC6750] which = states: >> =20 >> 3.1. Error Codes >> When a request fails, the resource server responds using the = appropriate HTTP status code (typically, 400, 401, 403, or 405) and = includes one of the following error codes in the response: >> =20 >> invalid_request >> The request is missing a required parameter, includes an unsupported = parameter or parameter value, repeats the same parameter, uses more than = one method for including an access token, or is otherwise malformed. The = resource server SHOULD respond with the HTTP 400 (Bad Request) status = code. >> =20 >> invalid_token >> The access token provided is expired, revoked, malformed, or invalid = for other reasons. The resource SHOULD respond with the HTTP 401 = (Unauthorized) status code. The client MAY request a new access token = and retry the protected resource request. >> =20 >> insufficient_scope >> The request requires higher privileges than provided by the access = token. The resource server SHOULD respond with the HTTP 403 (Forbidden) = status code and MAY include the scope attribute with the scope necessary = to access the protected resource. >> =20 >> If the request lacks any authentication information (e.g., the client = was unaware that authentication is necessary or attempted using an = unsupported authentication method), the resource server SHOULD NOT = include an error code or other error information. >> =20 >> For example: >> HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example"= >> =20 >> =20 >> Best regards, >> Don >> Donald F. Coffin >> Founder/CTO >> =20 >> REMI Networks >> 22751 El Prado Suite 6216 >> Rancho Santa Margarita, CA 92688-3836 >> =20 >> Phone: (949) 636-8571 >> Email: donald.coffin@reminetworks.com = >> =20 >> From: Justin Richer [mailto:jricher@mit.edu ]=20= >> Sent: Tuesday, December 2, 2014 6:06 AM >> To: Hannes Tschofenig; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 >> =20 >> Hannes, thanks for the review. Comments inline. >>=20 >> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: >> Hi Justin, >> =20 >> I have a few remarks regarding version -01 of the token introspection >> document. >> =20 >> * Terminology >> =20 >> The token introspection protocol is a client-server protocol but the >> term "client" already has a meaning in OAuth. Here the client of the >> token introspection protocol is actually the resource server. I = believe >> it would make sense to clarify this issue in the terminology section = or >> in the introduction. Maybe add a figure (which you could copy from >> Figure 4 of >> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt = . >> =20 >> Maybe you want to call these two parties, the introspection client = and >> the introspection server. >>=20 >> I tried to avoid the word "client" for this very reason. The draft = used to say "client or protected resource" throughout, but in a few = years of deployment experience it's become clear that it's pretty much = just protected resources that need to do introspection so I changed that = text throughout. I don't think that "introspection client" will help = here because the party already has a name from OAuth and we should = inherit it. >>=20 >>=20 >> * Scope >> =20 >> I think the document needs to be very clear that is only applicable = to >> bearer tokens (and not to PoP tokens). This issue was raised at the = last >> IETF meeting as well. >>=20 >> I think the document should be clear that it *specifies* the = mechanism for bearer tokens, since that's the only OAuth token type = that's defined publicly right now, and that the details for PoP will = have to be specified in another spec -- that's exactly what Appendix C = is there for, and if that can be clearer, please suggest better text. >>=20 >> However, I think it's very clear how PoP tokens would work. You send = the value returned as the "access_token" in the token endpoint response, = which is effectively the public portion of the PoP token. Just like a = bearer token, this value is passed as-is from the client to the RS and = would be passed as-is from the RS to the AS during introspection. The AS = can then use that to look up the key and return it in an = as-yet-unspecified field so that the RS can validate the request. The RS = wouldn't send the signature or signed portion of the request for the AS = to validate -- that's a bad idea. But these are all details that we can = work out in the PoP-flavored extension. As I noted in the other thread, = we'll have to make a similar extension for Revocation, so I still don't = think it makes sense to hold up this work and wait for PoP to be = finished because it's useful now, as-is. >>=20 >>=20 >> =20 >> =20 >> * Meta-Information >> =20 >> You have replicated a lot of the claims defined in >> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 = >> and I am wondering why you have decided to not just re-use the entire >> registry from JWT? >> =20 >> If you want to create a separate registry (which I wouldn't = recommend) >> then you have to put text into the IANA consideration section. >>=20 >> The idea was to inherit JWT's syntax and semantics, at least on the = wire, and add additional fields. It probably makes sense to just inherit = the JWT registry, so we can do that. >>=20 >>=20 >> When you write: >> =20 >> " >> The endpoint MAY allow other parameters to provide further context to >> the query. >> " >> =20 >> You could instead write that the token introspection MUST ignore any >> parameters from the request message it does not understand. >>=20 >> Noted, will add. >>=20 >>=20 >> Of course, there is the question whether any of those would be = security >> critical and hence ignoring them would cause problems?! >>=20 >> Anything security critical would be provider-specific, in which case = it wouldn't ignore them.=20 >>=20 >>=20 >> * Security >> =20 >> The requirement for authenticating the party issuing the = introspection >> request to the token introspection endpoint is justified in the = security >> and the privacy consideration section. The security threat is that an >> attacker could use the endpoint to testing for tokens. The privacy >> threat is that a resource server learns about the content of the = token, >> which may contain personal data. I see the former as more dangerous = than >> the latter since a legitimate resource server is supposed to learn = about >> the authorization information in the token. An attacker who had = gotten >> hold of tokens will not only learn about the content of the token but = he >> will also be able to use it to get access to the protected resource = itself. >> =20 >> In any case, to me this sounds like mutual authentication should be >> mandatory to implement. This is currently not the case. On top of = that >> there is single technique mandatory-to-implement outlined either (in >> case someone wants to use it). That's in general not very helpful = from >> an interoperability point of view. Yet another thing to agree on = between >> the AS and the RS. >>=20 >> I had similar thoughts when putting draft -01 together but didn't = want to make a normative change like that without the WG input. I'm fine = with strengthening this to a MUST, since as far as I'm aware that's how = it works in all existing implementations (can anyone else comment on = this?). I'm less comfortable with making one particular mechanism MTI, = since I know of implementations that use either a special set of = credentials passed just like client credentials to the token endpoint, = or an OAuth token specifically for the introspection endpoint. If we do = standardize on one MTI form, I'd suggest that we make it the OAuth = bearer token. >>=20 >>=20 >> * SHOULDs >> =20 >> This is my usual comment that any SHOULD statement should give the >> reader enough information about the trade-off decision he has to = make. >> When should he implement something and when should he skip it? >>=20 >> Noted, thanks.=20 >>=20 >>=20 >> * Minor items >> =20 >> You write: >> =20 >> " >> These include using >> structured token formats such as JWT [JWT] or SAML [[ Editor's = Note: >> Which SAML document should we reference here? ]] and proprietary >> inter-service communication mechanisms (such as shared databases = and >> protected enterprise service buses) that convey token information. >> " >> =20 >> Just reference the JWT since that's what we standardize. >>=20 >> I'm fine with that, didn't want to offend the SAML cabal but we can = cut it. >>=20 >>=20 >> * 'Active' claim >> =20 >> you write: >> " >> active REQUIRED. Boolean indicator of whether or not the = presented >> token is currently active. The authorization server determines >> whether and when a given token is in an active state. >> " >> =20 >> Wouldn't it make more sense to return an error rather than saying = that >> this token is not active. >>=20 >> It's not an error, really. It's a valid request and valid response = saying that token isn't any good. It would be easy enough to change the = returned error code on the {active:false} response, but to which code? = The request isn't Forbidden, or Not Found (the token could have been = found but it's been deactivated or just not available to the RS that's = asking for it), or Unauthorized, or even a Bad Request. So my logic is = that the response is "OK", but the content of the response tells you the = metadata about the token, which is that it's not active.=20 >>=20 >>=20 >> * Capitalization >> =20 >> Reading through the text I see bearer token/Bearer Token, = Client/client, >> etc. issue. >>=20 >> Thanks, still breaking old Bad Habits of capitalizing Terms In The = Document. Tried to clean it up, will do more. >>=20 >>=20 >> * AS <-> RS relationship >> =20 >> You write: >> " >> Since >> OAuth 2.0 [RFC6749] defines no direct relationship between the >> authorization server and the protected resource, only that they = must >> have an agreement on the tokens themselves, there have been many >> different approaches to bridging this gap. >> " >> =20 >> I am not sure what you mean by "defines no relationship" between the = AS >> and the RS. Of course, there is a relationship. The AS issues tokens = for >> access for a specific RS. The RS needs to understand the tokens or if = it >> does not understand them it needs to know which AS to interact with = to >> learn about the content. >> =20 >> In a nutshell, I am not sure what you want to say with this paragraph >> particularly since you state that they have to have an agreement = about >> the tokens. >>=20 >> What I was trying to point out is that it doesn't define the nature = of the relationship between the two components. Specifically, it says: >>=20 >> The methods used by the resource >> server to validate the access token (as well as any error = responses) >> are beyond the scope of this specification but generally involve = an >> interaction or coordination between the resource server and the >> authorization server. >> This spec provides one mechanism for this validation. So we could = reference this directly if that's helpful.=20 >>=20 >> -- Justin >>=20 >>=20 >> =20 >> =20 >> =20 >> Ciao >> Hannes >> =20 >>=20 >>=20 >>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_E2CC733D-B4AA-42E2-8C1F-1BCB22076C91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1
On Dec 2, 2014, at 3:19 PM, Richer, Justin P. <jricher@mitre.org> = wrote:

No, this isn't an appropriate mapping in this = case, especially if the introspection endpoint is itself OAuth = protected. You need to be able to differentiate between the token being = asked about and the token authorizing the question. These error codes = apply to the latter and should not be conflated with the = former.

 -- Justin

On Dec 2, 2014, at 12:25 PM, Donald Coffin = <donald.coffin@reminetworks.com> wrote:

Hi Justin,

 

I = believe you will find the answer to which HTTP Status code the AS should = return if the token is INACTIVE in Section 3.1 Error Codes of =93The = OAuth 2.0 Framework: Bearer Token Usage=94 [RFC6750] which states:

 

3.1.  Error Codes
When a request fails, the resource server responds using the = appropriate HTTP status code (typically, 400, 401, 403, or 405) and = includes one of the following error codes in the response:

 

invalid_request
The= request is missing a required parameter, includes an unsupported = parameter or parameter value, repeats the same parameter, uses more than = one method for including an access token, or is otherwise malformed. The = resource server SHOULD respond with the HTTP 400 (Bad Request) status = code.

 

invalid_token
The access token = provided is expired, revoked, malformed, or invalid for other reasons. = The resource SHOULD respond with the HTTP 401 (Unauthorized) status = code. The client MAY request a new access token and retry the protected = resource request.

 

insufficient_scope
The request requires = higher privileges than provided by the access token. The resource server = SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include = the scope attribute with the scope necessary to access the protected = resource.

 

If the request lacks any authentication = information (e.g., the client was unaware that authentication is = necessary or attempted using an unsupported authentication method), the = resource server SHOULD NOT include an error code or other error = information.

 

For example:
  HTTP/1.1 401 = Unauthorized  WWW-Authenticate: Bearer realm=3D"example"

 

 

Best regards,
Don
Donald F. Coffin
Founder/CTO
 
REMI Networks
22751 El Prado = Suite 6216
Rancho Santa Margarita, CA  = 92688-3836
 
Phone:      (949) = 636-8571
Email:       donald.coffin@reminetworks.com

 

From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Tuesday, December 2, 2014 = 6:06 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of = draft-ietf-oauth-introspection-01
 
Hannes, thanks for the review. Comments = inline.

On 12/2/2014 6:23 AM, Hannes = Tschofenig wrote:
Hi Justin,
 
I have a few remarks regarding version -01 of =
the token introspection
document.
 
* =
Terminology
 
The token =
introspection protocol is a client-server protocol but the
term "client" =
already has a meaning in OAuth. Here the client of the
token =
introspection protocol is actually the resource server. I believe
it would make =
sense to clarify this issue in the terminology section or
in the =
introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt=
.
 
Maybe you want =
to call these two parties, the introspection client and
the =
introspection server.

I tried to avoid the word = "client" for this very reason. The draft used to say "client or = protected resource" throughout, but in a few years of deployment = experience it's become clear that it's pretty much just protected = resources that need to do introspection so I changed that text = throughout. I don't think that "introspection client" will help here = because the party already has a name from OAuth and we should inherit = it.


* Scope
 
I think the =
document needs to be very clear that is only applicable to
bearer tokens =
(and not to PoP tokens). This issue was raised at the last
IETF meeting as =
well.

I think the document should be clear that it = *specifies* the mechanism for bearer tokens, since that's the only OAuth = token type that's defined publicly right now, and that the details for = PoP will have to be specified in another spec -- that's exactly what = Appendix C is there for, and if that can be clearer, please suggest = better text.

However, I think it's very = clear how PoP tokens would work. You send the value returned as the = "access_token" in the token endpoint response, which is effectively the = public portion of the PoP token. Just like a bearer token, this value is = passed as-is from the client to the RS and would be passed as-is from = the RS to the AS during introspection. The AS can then use that to look = up the key and return it in an as-yet-unspecified field so that the RS = can validate the request. The RS wouldn't send the signature or signed = portion of the request for the AS to validate -- that's a bad idea. But = these are all details that we can work out in the PoP-flavored = extension. As I noted in the other thread, we'll have to make a similar = extension for Revocation, so I still don't think it makes sense to hold = up this work and wait for PoP to be finished because it's useful now, = as-is.


 
 
* =
Meta-Information
 
You=
 have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31<=
/a>
and I am =
wondering why you have decided to not just re-use the entire
registry from =
JWT?
 
If you want to =
create a separate registry (which I wouldn't recommend)
then you have =
to put text into the IANA consideration section.
When you =
write:
 
"
The endpoint =
MAY allow other parameters to provide further context to
the query.
"
 
You could =
instead write that the token introspection MUST ignore any
parameters from =
the request message it does not understand.
Of course, there is the question whether any =
of those would be security
critical and hence ignoring them would cause =
problems?!

Anything security critical would be = provider-specific, in which case it wouldn't ignore them. 


* Security
 
The requirement for authenticating the party =
issuing the introspection
request to the token introspection endpoint is justified in =
the security
and =
the privacy consideration section. The security threat is that an
attacker could =
use the endpoint to testing for tokens. The privacy
threat is that =
a resource server learns about the content of the token,
which may =
contain personal data. I see the former as more dangerous than
the latter =
since a legitimate resource server is supposed to learn about
the =
authorization information in the token. An attacker who had gotten
hold of tokens =
will not only learn about the content of the token but he
will also be =
able to use it to get access to the protected resource itself.
 
In any case, to =
me this sounds like mutual authentication should be
mandatory to =
implement. This is currently not the case. On top of that
there is single =
technique mandatory-to-implement outlined either (in
case someone =
wants to use it). That's in general not very helpful from
an =
interoperability point of view. Yet another thing to agree on =
between
the =
AS and the RS.

I had similar thoughts = when putting draft -01 together but didn't want to make a normative = change like that without the WG input. I'm fine with strengthening this = to a MUST, since as far as I'm aware that's how it works in all existing = implementations (can anyone else comment on this?). I'm less comfortable = with making one particular mechanism MTI, since I know of = implementations that use either a special set of credentials passed just = like client credentials to the token endpoint, or an OAuth token = specifically for the introspection endpoint. If we do standardize on one = MTI form, I'd suggest that we make it the OAuth bearer token.


* SHOULDs
 
This is my =
usual comment that any SHOULD statement should give the
reader enough =
information about the trade-off decision he has to make.
When should he =
implement something and when should he skip it?
* Minor items
 
You write:
 
"
These include using
   =
structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
   =
Which SAML document should we reference here? ]] and proprietary
   =
inter-service communication mechanisms (such as shared databases and
   =
protected enterprise service buses) that convey token information.
"
 
Just reference =
the JWT since that's what we standardize.
* =
'Active' claim
 
you write:
"
   =
active  REQUIRED.  Boolean indicator of whether or not the =
presented
      token is currently =
active.  The authorization server determines
      whether and when a given token =
is in an active state.
"
 
Wouldn't it =
make more sense to return an error rather than saying that
this token is =
not active.

It's not an error, really. It's a = valid request and valid response saying that token isn't any good. It = would be easy enough to change the returned error code on the = {active:false} response, but to which code? The request isn't Forbidden, = or Not Found (the token could have been found but it's been deactivated = or just not available to the RS that's asking for it), or Unauthorized, = or even a Bad Request. So my logic is that the response is "OK", but the = content of the response tells you the metadata about the token, which is = that it's not active. 


* Capitalization
 
Reading through =
the text I see bearer token/Bearer Token, Client/client,
etc. issue.
* AS <-> =
RS relationship
 
You write:
"
   =
Since
   =
OAuth 2.0 [RFC6749] defines no direct relationship between the
   =
authorization server and the protected resource, only that they must
   =
have an agreement on the tokens themselves, there have been many
   =
different approaches to bridging this gap.
"
 
I am not sure what you mean by "defines no =
relationship" between the AS
and the RS. Of course, there is a =
relationship. The AS issues tokens for
access for a specific RS. The RS needs to =
understand the tokens or if it
does not understand them it needs to know =
which AS to interact with to
learn about the content.
 
In a nutshell, =
I am not sure what you want to say with this paragraph
particularly =
since you state that they have to have an agreement about
the tokens.


What I was trying to point out is that it = doesn't define the nature of the relationship between the two = components. Specifically, it says:

   The methods used by the =
resource
   server to validate the access token (as well as =
any error responses)
   are beyond the scope of this specification but =
generally involve an
   interaction or coordination between the resource =
server and the
   authorization server.
This = spec provides one mechanism for this validation. So we could reference = this directly if that's helpful. 

  -- Justin


 
 
 
Ciao
Hannes
 



_______________________________________________
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

= --Apple-Mail=_E2CC733D-B4AA-42E2-8C1F-1BCB22076C91-- --Apple-Mail=_EF1CD07B-520D-45DF-B405-C262B07E0700 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDIxOTI1MThaMCMGCSqGSIb3DQEJBDEWBBTeIxZuIVNk6oytFQi51Z78 M/+oQzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBlsg/HfO9Bmdc1mDMYEchqw2w5Tg8sAIMUm252i3Wknm7vyufxkMaA q2MsYfEeqODsY/DlRJlIOT6WJS/M4/JJjGWu0yKn3YuRvIJPu0kO2yBwcfahYMiHtyMyipE+i3I6 aYrJs6JZk/2DqCLS5+cNpT83uYnaN/6cu+QXNNh5VhjceUGg9OY3/LVub/FLmj93eIRyJjN252TX 1g7WrcZbqv1+fBtgZ2Ltw6MA0fJVsBhB07hpXCqAkCETsytfk3LwjBwVkofHibCC8wzDCZdc905o MdJWoKJXs9K8cIuJUAME7gGgiA35zOzfcX/OWcYFA7bra74g98k8gXJGB5M6AAAAAAAA --Apple-Mail=_EF1CD07B-520D-45DF-B405-C262B07E0700-- From nobody Tue Dec 2 11:56:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52C1A1F20 for ; Tue, 2 Dec 2014 11:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUvcZYhleZLr for ; Tue, 2 Dec 2014 11:56:38 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 709071A6FE2 for ; Tue, 2 Dec 2014 11:56:37 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8BE5CB2E088; Tue, 2 Dec 2014 14:56:36 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 7F1ADB2E105; Tue, 2 Dec 2014 14:56:36 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 14:56:35 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoCAAAMSAIAACQgA Date: Tue, 2 Dec 2014 19:56:35 +0000 Message-ID: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/C5qa8xxT60y2KuM1dAWsvTYRbIM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:56:40 -0000 --_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it. -- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." > wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token. Can you explain how this is related to "act on behalf of"? I don't see any = connection. -- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? Data about the user? Where does= this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." > wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill --_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Agreed, which is why we've got space for the "sub" and "user= _id" fields but not anything else about the user, and we've got a priv= acy considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data = beyond what is strictly required to validate the token based solely on poss= ession of the public part it would be a mistake.


On Tuesday, December 2, 20= 14 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over TLS anyway= (RS->AS) just like the original token fetch by the client (C->AS). D= oesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.&nb= sp;

Can you explain how this is related to "act on behalf of"? I= don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
Fetching the public= key for a token might be fine, but what if the introspection endpoint retu= rns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on be= half of"?


On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P."= <jricher@mitre.org= > wrote:


The call to intr= ospection has a TLS requirement, but the call to the RS wouldn't necessaril= y have that requirement. The signature and the token identifier are two dif= ferent things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's= associated with it and the request. What I'm saying is that you introspect= the identifier and get back something that lets you, the RS, check the sig= nature.

 -- Justin<= /div>

On Dec 2, 2014, = at 1:40 PM, Bill Mills <wmills_921= 05@yahoo.com> wrote:

"However, I think it's ver= y clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think.  Otherwise I can as= an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








--_000_EA29FCACB69040D3A6EF345F4483856Emitreorg_-- From nobody Tue Dec 2 12:15:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA26A1A6FCA for ; Tue, 2 Dec 2014 12:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SngmXi4DlCJ for ; Tue, 2 Dec 2014 12:15:20 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC881A7016 for ; Tue, 2 Dec 2014 12:15:00 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so17941452wgh.30 for ; Tue, 02 Dec 2014 12:14:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=9QOeV2csuaQnhhzMO8wbs0B7LT8M23R50Z337WbCmtA=; b=mH2AQ3fwDjN9p1bQFWycaTHD3VlAIcRKS+GJzDvX2NhHmLnBuxJ7af+Qolxy0oEMUH DGlUiSkPIRHah7tbAzctRbwtGadue1su+nF1i8JQxGzp8rrlgFotMuD/15ErUf5CsbsF fqLWiTzMaBKhGokAfd2nEJed8jQOBGKxEBNZ54NGjC7T4FdYlqj6u6eGqfIuAgU7MWnj TKH1p9+P8y3QySUcIUx9IUJRzyTH3h1G9bIloTw3736++12rsRaUYxmawMruLovDY7K0 WCreDe2ouJzg69i2H89CeW6KtjQYoRLQk22kxRa2pr5hvv3V6VXtULBGTpO3mbfaS9wU pGoA== X-Gm-Message-State: ALoCoQkyNW3F7PK3IOLUtAK3y6H68Pm3hb19t6okH8z/uJIX28x6RDWZaaAz1d7kSe4qf2nQhHSj X-Received: by 10.180.38.98 with SMTP id f2mr7808352wik.55.1417551299145; Tue, 02 Dec 2014 12:14:59 -0800 (PST) Received: from [10.47.81.9] (host86-187-11-58.range86-187.btcentralplus.com. [86.187.11.58]) by mx.google.com with ESMTPSA id j2sm33307981wjs.28.2014.12.02.12.14.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 12:14:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2519D241-BA48-494E-BAB9-27ECD4DF6DBD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Tue, 2 Dec 2014 17:14:54 -0300 Message-Id: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> To: "Justin P. Richer" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H1Ali2oAFfxBpjbfz9_sjem1T6Y Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:15:24 -0000 --Apple-Mail=_2519D241-BA48-494E-BAB9-27ECD4DF6DBD Content-Type: multipart/alternative; boundary="Apple-Mail=_D365FEE6-E05B-4FAD-88DB-A45598B634E3" --Apple-Mail=_D365FEE6-E05B-4FAD-88DB-A45598B634E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Many of the proprietary introspection protocols in use return scope, = role or other meta data for the RS to make its access policy decision = on. One of the reasons for using opaque tokens rather than JWT is to prevent = leakage of that info. Making authentication to the introspection endpoint a MUST if additional = attributes are present is OK, I might even be inclined to say that = authentication of some sort is always required, but that might be going = a bit far for some use cases. We have a lot of proprietary ways to do this from IBM, Layer 7, Ping = etc. It would be nice if we could standardize it. Precluding other = attributes would not be helpful for adoption. One issue that we haven=E2=80=99t addressed in this spec is what happens = if there are multiple AS for the RS and how it would decide what = introspection endpoint to use. Perhaps that needs to be a extension, leaving this for the simple case. However having more than on e AS per RS is not as unusual as it once was = in larger environments. John B. > On Dec 2, 2014, at 4:56 PM, Richer, Justin P. = wrote: >=20 > Agreed, which is why we've got space for the "sub" and "user_id" = fields but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it. >=20 > -- Justin >=20 > On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: >=20 >> If introspection returns any other user data beyond what is strictly = required to validate the token based solely on possession of the public = part it would be a mistake. >>=20 >>=20 >> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." = > wrote: >>=20 >>=20 >> That's all fine -- it's all going over TLS anyway (RS->AS) just like = the original token fetch by the client (C->AS). Doesn't mean you need = TLS *into* the RS (C->RS) with a good PoP token.=20 >>=20 >> Can you explain how this is related to "act on behalf of"? I don't = see any connection. >>=20 >> -- Justin >>=20 >> On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: >>=20 >>> Fetching the public key for a token might be fine, but what if the = introspection endpoint returns the symmetric key? Data about the user? = Where does this blur the line between this and "act on behalf of"? >>>=20 >>>=20 >>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." = > wrote: >>>=20 >>>=20 >>> The call to introspection has a TLS requirement, but the call to the = RS wouldn't necessarily have that requirement. The signature and the = token identifier are two different things. The identifier doesn't do an = attacker any good on its own without the verifiable signature that's = associated with it and the request. What I'm saying is that you = introspect the identifier and get back something that lets you, the RS, = check the signature. >>>=20 >>> -- Justin >>>=20 >>> On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: >>>=20 >>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>=20 >>>> I don't know if that's true. POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. = Otherwise I can as an attacker take that toklen and get info about it = that might be useful, and I don't think that's what we want. >>>>=20 >>>> -bill >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D365FEE6-E05B-4FAD-88DB-A45598B634E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Many of the proprietary introspection protocols in use return = scope, role or other meta data for the RS to make its access policy = decision on.
One of the reasons for using opaque tokens = rather than JWT is to prevent leakage of that info.

Making authentication to = the introspection endpoint a MUST if additional attributes are present = is OK,  I might even be inclined to say that authentication of some = sort is always required, but that might be going a bit far for some use = cases.

We have = a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. =  It would be nice if we could standardize it.   Precluding = other attributes would not be helpful for adoption.


One issue that we haven=E2=80=99t addressed in this spec is = what happens if there are multiple AS for the RS and how it would decide = what introspection endpoint to use.
Perhaps that = needs to be a extension, leaving this for the simple case.

However having more than = on e AS per RS is not as unusual as it once was in larger = environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> = wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields = but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection = returns any other user data beyond what is strictly required to validate = the token based solely on possession of the public part it would be a mistake.


On = Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> = wrote:


That's all fine -- it's all going = over TLS anyway (RS->AS) just like the original token fetch by the = client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) = with a good PoP token. 

Can you explain how this is related to "act on behalf = of"? I don't see any connection.

 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what = if the introspection endpoint returns the symmetric key?  Data = about the user?  Where does this blur the line between this and "act on = behalf of"?


On Tuesday, December 2, 2014 11:05 = AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The = call to introspection has a TLS requirement, but the call to the RS = wouldn't necessarily have that requirement. The signature and the token = identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature = that's associated with it and the request. What I'm saying is that you = introspect the identifier and get back something that lets you, the RS, = check the signature.

 -- Justin

On = Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear = how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. =  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we = want.

-bill








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

= --Apple-Mail=_D365FEE6-E05B-4FAD-88DB-A45598B634E3-- --Apple-Mail=_2519D241-BA48-494E-BAB9-27ECD4DF6DBD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDIyMDE0NTVaMCMGCSqGSIb3DQEJBDEWBBTlno3itaY/yzXcxD7VrV+2 deOhGjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA9/vA1TfQSOccwHaBxsO6FSKEgq+9x8VUIARsX/VY3PvAMAtF5kZ8/ 57GtZ771YYx9mHSFEPudjJGGqPKSymODMH9FztP62pV0eQwvPC4FUniDbjOwjtw35mmQEsgMmPN5 a/j3fIqbsXls7XeZtf+qL5YkuygW6mjFjkUfVkSztVL6+33HUrn3nou18VkYqVh5Rbf0p5OzOE9O AMlhMKR94HsR/K/5i/f28NhU8sYlFQdXZHR23s9FHe7F0UClyQ4+ZAusqLBf9uViGx1pF2GPV+eP tpZLp9X2Jay1GU4qofjunZ9p7x9bva/1xVgG1ZH6IMEW9xPMQAnetxMqumnkAAAAAAAA --Apple-Mail=_2519D241-BA48-494E-BAB9-27ECD4DF6DBD-- From nobody Tue Dec 2 12:15:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7951A7014 for ; Tue, 2 Dec 2014 12:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDGFvssZya5o for ; Tue, 2 Dec 2014 12:15:23 -0800 (PST) Received: from BLU004-OMC4S7.hotmail.com (blu004-omc4s7.hotmail.com [65.55.111.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3441A701C for ; Tue, 2 Dec 2014 12:15:03 -0800 (PST) Received: from BLU406-EAS110 ([65.55.111.135]) by BLU004-OMC4S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 12:15:02 -0800 X-TMN: [hf0zbC64OdCpDlUc5rQJjPQ+P1vXuI/n] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_b9d4fddd-a6b6-4cbb-a00a-42e6ded2d50c_" MIME-Version: 1.0 X-Client-ID: 509 X-Mailer: BlackBerry Email (10.2.1.3442) Date: Wed, 3 Dec 2014 03:14:58 +0700 From: Panca Agus Ananda To: X-OriginalArrivalTime: 02 Dec 2014 20:15:02.0594 (UTC) FILETIME=[A7AA0A20:01D00E6C] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-StZAeeA-OTShQk_p1uLAJXu_hI Cc: Outlook Traveller Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 24 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:15:25 -0000 --_b9d4fddd-a6b6-4cbb-a00a-42e6ded2d50c_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" =E2=80=8EPanca.blogspot.com Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Rabu=2C 3 Desember 2014 03.00 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 74=2C Issue 24 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Review of draft-ietf-oauth-introspection-01 (Richer=2C Justin P.) ---------------------------------------------------------------------- Message: 1 Date: Tue=2C 2 Dec 2014 19:56:35 +0000 From: "Richer=2C Justin P." To: Bill Mills Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Message-ID: Content-Type: text/plain=3B charset=3D"us-ascii" Agreed=2C which is why we've got space for the "sub" and "user_id" fields b= ut not anything else about the user=2C and we've got a privacy consideratio= ns section for dealing with that. If you can help make the wording on that = section stronger=2C I'd appreciate it. -- Justin On Dec 2=2C 2014=2C at 2:25 PM=2C Bill Mills > wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday=2C December 2=2C 2014 11:13 AM=2C "Richer=2C Justin P." > wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token. Can you explain how this is related to "act on behalf of"? I don't see any = connection. -- Justin On Dec 2=2C 2014=2C at 2:09 PM=2C Bill Mills > wrote: Fetching the public key for a token might be fine=2C but what if the intros= pection endpoint returns the symmetric key? Data about the user? Where do= es this blur the line between this and "act on behalf of"? On Tuesday=2C December 2=2C 2014 11:05 AM=2C "Richer=2C Justin P." > wrote: The call to introspection has a TLS requirement=2C but the call to the RS w= ouldn't necessarily have that requirement. The signature and the token iden= tifier are two different things. The identifier doesn't do an attacker any = good on its own without the verifiable signature that's associated with it = and the request. What I'm saying is that you introspect the identifier and = get back something that lets you=2C the RS=2C check the signature. -- Justin On Dec 2=2C 2014=2C at 1:40 PM=2C Bill Mills > wrote: "However=2C I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful=2C and I don= 't think that's what we want. -bill -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 74=2C Issue 24 ************************************* --_b9d4fddd-a6b6-4cbb-a00a-42e6ded2d50c_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
=E2=80=8EPanca.blogspot.com =3B

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Rabu=2C 3 Desember 2014 03.00
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 74=2C Issue 24

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Review of draft-ietf-oauth-introspection-01
 =3B =3B =3B =3B =3B (Richer=2C Justin P.)


----------------------------------------------------------------------

Message: 1
Date: Tue=2C 2 Dec 2014 19:56:35 +=3B0000
From: "=3BRicher=2C Justin P."=3B <=3Bjricher@mitre.org>=3B
To: Bill Mills <=3Bwmills_92105@yahoo.com>=3B
Cc: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <=3BEA29FCAC-B690-40D3-A6EF-345F4483856E@mitre.org>=3B
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B

Agreed=2C which is why we've got space for the "=3Bsub"=3B and &quo= t=3Buser_id"=3B fields but not anything else about the user=2C and we'v= e got a privacy considerations section for dealing with that. If you can he= lp make the wording on that section stronger=2C I'd appreciate it.

 =3B-- Justin

On Dec 2=2C 2014=2C at 2:25 PM=2C Bill Mills <=3Bwmills_92105@yahoo.com&l= t=3Bmailto:wmills_92105@yahoo.com>=3B>=3B wrote:

If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake.


On Tuesday=2C December 2=2C 2014 11:13 AM=2C "=3BRicher=2C Justin P.&qu= ot=3B <=3Bjricher@mitre.org<=3Bmailto:jricher@mitre.org>=3B>=3B wro= te:


That's all fine -- it's all going over TLS anyway (RS->=3BAS) just like t= he original token fetch by the client (C->=3BAS). Doesn't mean you need T= LS *into* the RS (C->=3BRS) with a good PoP token.

Can you explain how this is related to "=3Bact on behalf of"=3B? I = don't see any connection.

 =3B-- Justin

On Dec 2=2C 2014=2C at 2:09 PM=2C Bill Mills <=3Bwmills_92105@yahoo.com&l= t=3Bmailto:wmills_92105@yahoo.com>=3B>=3B wrote:

Fetching the public key for a token might be fine=2C but what if the intros= pection endpoint returns the symmetric key? =3B Data about the user?&nb= sp=3B Where does this blur the line between this and "=3Bact on behalf = of"=3B?


On Tuesday=2C December 2=2C 2014 11:05 AM=2C "=3BRicher=2C Justin P.&qu= ot=3B <=3Bjricher@mitre.org<=3Bmailto:jricher@mitre.org>=3B>=3B wro= te:


The call to introspection has a TLS requirement=2C but the call to the RS w= ouldn't necessarily have that requirement. The signature and the token iden= tifier are two different things. The identifier doesn't do an attacker any = good on its own without the verifiable signature that's associated with it and the request. What I'm saying is th= at you introspect the identifier and get back something that lets you=2C th= e RS=2C check the signature.

 =3B-- Justin

On Dec 2=2C 2014=2C at 1:40 PM=2C Bill Mills <=3Bwmills_92105@yahoo.com&l= t=3Bmailto:wmills_92105@yahoo.com>=3B>=3B wrote:

"=3BHowever=2C I think it's very clear how PoP tokens would work. ...&q= uot=3B

I don't know if that's true. =3B POP tokens (as yet to be fully defined= ) would then also have a TLS or transport security requirement unless there= is token introspection client auth in play I think. =3B Otherwise I ca= n as an attacker take that toklen and get info about it that might be useful=2C and I don't think that's what we want.
-bill








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141202/6392a329/attachment.html>=3B

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest=2C Vol 74=2C Issue 24
*************************************
--_b9d4fddd-a6b6-4cbb-a00a-42e6ded2d50c_-- From nobody Tue Dec 2 12:35:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470C31A7005 for ; Tue, 2 Dec 2014 12:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LETJ401A-G_Y for ; Tue, 2 Dec 2014 12:35:53 -0800 (PST) Received: from nm37-vm4.bullet.mail.bf1.yahoo.com (nm37-vm4.bullet.mail.bf1.yahoo.com [72.30.238.204]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0591D1A7006 for ; Tue, 2 Dec 2014 12:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417552552; bh=MVI6FYrPvvrvyQuaw1yOCyDIB7T5Kd0iKG+0w5nIb7I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=s/+RejiO8XvUk/ixlWvmztshAGJx6SWJjKeo4OtZ/ETFWuPSl6nk4yV+bm+RDu/PJp7Fl3INOSBlVkHVVZdaWmrhZnQcY9vKO+7fxkE5WTNcHXKZNINal1jwR+bV/C7kKr9gsDLtHQa0bk6QqwtXoQWTcMhoTMWgMC2iOejU0O7X7+xqFMlLncAfUMAhvjaMyOaSQNElStjMjbNdHKVIoAHb+xefcFGxyBj3RYMl+Osf3e0FPlrpij4RoUaBKqWoBJJ/dGMB2Dp82fTT44oS/zZrkRdsGs9IRK6hJPqvawrQRCSDvyN6BPaYUzHShQCw0R8OITIvzh3nxUF1hlIRRA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=OxaXxwH0u0sOuCmYTTo2mwWunQmtKCgHDmfWXm/tcJSnAsmpQ003YgfBtj1NzkBFSzXzF9fG3glYUlwjQfMkX6G09iqDx1nT65hkROU5GFZv5MbP0TRLJDQMLKXeOfe13Gk0ieWxMyyRlxKJ235Ww5soWxZbCeelZcIcIVIm/l9smYbKurL7xE3mTU0IXZMB+dzwVgWuf3PEf4qy64uYKVVdp2gmr4v0dbIhOM07oTHo5YdMIVBH7HABTmKFffbuomm9YuWsoayyEvGoe1wVhm4oaangkBWBl9TTshCDxjz0wNNqz0EF0goCnfgDJ5v7h/FrXaInutYc57eL20lLCw==; Received: from [98.139.215.140] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 20:35:52 -0000 Received: from [98.139.212.243] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 20:35:52 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 20:35:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 166178.96850.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: c5m_gxUVM1kf5u5drP11PukQtR_rsW09WsPWICHGSoxe_N8SDTERDzO.VL.5cpa JAhRwA_fXbWunQjjux9mkcLc9h35V1wOjvqWd6E1GDZ4Laq9Et7f44DJ4u5O35FxwhRt10ZGi.WZ pPjJNNSeUz7rp4ZEn3F2vYmUqJyv2vnYNWkq9VPnan6qvjSSZjCYZeOvE_gB38NdHT_k_aOeUCaJ PooBDJQHuPIepKXIKEbs7Vq97eo4uZRUsdOFr7rBb7V44hfzJQ8P9k.WOV75Kb7545G8p_2MNEJ5 Wz24b3FPSllAfKfZi6JSRlc76aEvlq.uEGHIAqnPohp2qQEXlZaj.mXtrQL7VdlDwJ9kyrjEhYf8 KE7ENZYPZtpmW7Y.2W7M0xjDUlHZl7VjqwbNXEmrKEYuDPDFqPGV83fT80sXuSwqH8Qru5j6Hlo8 Wtv5sOxbmaC22IFp3FrtJeSVlk6FS_4AtcXcmDYUGO_4mRuLNsvvN530tT7DeovzXdUUQeNpQeXM- Received: by 66.196.81.116; Tue, 02 Dec 2014 20:35:51 +0000 Date: Tue, 2 Dec 2014 20:35:51 +0000 (UTC) From: Bill Mills To: John Bradley , "Justin P. Richer" Message-ID: <361405969.4017078.1417552551240.JavaMail.yahoo@jws106103.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4017077_1227672910.1417552551230" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bvwMOJL8fDlgw7dX2aojlxsHRKc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:35:55 -0000 ------=_Part_4017077_1227672910.1417552551230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for "Making authentication to the introspection endpoint a MUST if addit= ional attributes are present is OK"=20 On Tuesday, December 2, 2014 12:15 PM, John Bradley wrote: =20 Many of the proprietary introspection protocols in use return scope, role = or other meta data for the RS to make its access policy decision on.One of = the reasons for using opaque tokens rather than JWT is to prevent leakage o= f that info. Making authentication to the introspection endpoint a MUST if additional at= tributes are present is OK, =C2=A0I might even be inclined to say that auth= entication of some sort is always required, but that might be going a bit f= ar for some use cases. We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. = =C2=A0It would be nice if we could standardize it. =C2=A0 Precluding other = attributes would not be helpful for adoption. One issue that we haven=E2=80=99t addressed in this spec is what happens if= there are multiple AS for the RS and how it would decide what introspectio= n endpoint to use.Perhaps that needs to be a extension, leaving this for th= e simple case. However having more than on e AS per RS is not as unusual as it once was in= larger environments. John B. On Dec 2, 2014, at 4:56 PM, Richer, Justin P. wrote: Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it. =C2=A0-- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token.=C2=A0 Can you explain how this is related to "act on behalf of"? I don't see any = connection. =C2=A0-- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? =C2=A0Data about the user? =C2=A0= Where does this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. =C2=A0-- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. =C2=A0POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think. =C2=A0Otherwise I can as= an attacker take that toklen and get info about it that might be useful, a= nd I don't think that's what we want. -bill _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4017077_1227672910.1417552551230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for "Making authentication to the introspe= ction endpoint a MUST if additional attributes are present is OK"


<= div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, = Lucida Grande, sans-serif; font-size: 16px;">
On Tuesday, December 2, 2014 12:15 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:


Many of the proprietary in= trospection protocols in use return scope, role or other meta data for the = RS to make its access policy decision on.
One o= f the reasons for using opaque tokens rather than JWT is to prevent leakage= of that info.

Making authentication= to the introspection endpoint a MUST if additional attributes are present = is OK,  I might even be inclined to say that authentication of some so= rt is always required, but that might be going a bit far for some use cases= .

We have a lot of proprietary ways to= do this from IBM, Layer 7, Ping etc.  It would be nice if we could st= andardize it.   Precluding other attributes would not be helpful for a= doption.


One issue that we haven=E2= =80=99t addressed in this spec is what happens if there are multiple AS for= the RS and how it would decide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving th= is for the simple case.

However having= more than on e AS per RS is not as unusual as it once was in larger enviro= nments.

John B.


On Dec 2, 20= 14, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:
<= br clear=3D"none" class=3D"yiv6057726670Apple-interchange-newline">
Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data b= eyond what is strictly required to validate the token based solely on posse= ssion of the public part it would be a mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, Justi= n P." <jricher@mitre.org> wrote:


That's all fine -- it's a= ll going over TLS anyway (RS->AS) just like the original token fetch by = the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) w= ith a good PoP token. 

Can you explain how this is related to "act on= behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be f= ine, but what if the introspection endpoint returns the symmetric key? &nbs= p;Data about the user?  Where does this blur the line between this and "act on behalf = of"?


On Tuesday, December= 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to th= e RS wouldn't necessarily have that requirement. The signature and the toke= n identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's= associated with it and the request. What I'm saying is that you introspect= the identifier and get back something that lets you, the RS, check the sig= nature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would wor= k. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think.  Otherwise I can as= an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








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



=
------=_Part_4017077_1227672910.1417552551230-- From nobody Tue Dec 2 12:44:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18171A1DE1 for ; Tue, 2 Dec 2014 12:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M18x0KCq6Hqh for ; Tue, 2 Dec 2014 12:44:51 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5107E1A6F0D for ; Tue, 2 Dec 2014 12:44:51 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE70352E0BA; Tue, 2 Dec 2014 15:44:50 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id E029652E0A4; Tue, 2 Dec 2014 15:44:50 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 15:44:50 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoCAAAMSAIAACQgAgAAE5gCAAAXbgIAAAr2A Date: Tue, 2 Dec 2014 20:44:50 +0000 Message-ID: <680A352F-F1ED-4CA5-B0E0-C3A97DD224C5@mitre.org> References: <361405969.4017078.1417552551240.JavaMail.yahoo@jws106103.mail.bf1.yahoo.com> In-Reply-To: <361405969.4017078.1417552551240.JavaMail.yahoo@jws106103.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_680A352FF1ED4CA5B0E0C3A97DD224C5mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/b_c-h6vXCHXwKcf2ueVB6DdYpgk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:44:55 -0000 --_000_680A352FF1ED4CA5B0E0C3A97DD224C5mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK, I'm taking a note to make it a MUST in general in the next draft, and w= e can dial back from there if there are honest, specific use cases where it= doesn't make sense. Thanks. -- Justin On Dec 2, 2014, at 3:35 PM, Bill Mills > wrote: +1 for "Making authentication to the introspection endpoint a MUST if addit= ional attributes are present is OK" On Tuesday, December 2, 2014 12:15 PM, John Bradley > wrote: Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on. One of the reasons for using opaque tokens rather than JWT is to prevent le= akage of that info. Making authentication to the introspection endpoint a MUST if additional at= tributes are present is OK, I might even be inclined to say that authentic= ation of some sort is always required, but that might be going a bit far fo= r some use cases. We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. = It would be nice if we could standardize it. Precluding other attributes = would not be helpful for adoption. One issue that we haven=92t addressed in this spec is what happens if there= are multiple AS for the RS and how it would decide what introspection endp= oint to use. Perhaps that needs to be a extension, leaving this for the simple case. However having more than on e AS per RS is not as unusual as it once was in= larger environments. John B. On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > wrote: Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it. -- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." > wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token. Can you explain how this is related to "act on behalf of"? I don't see any = connection. -- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? Data about the user? Where does= this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." > wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_680A352FF1ED4CA5B0E0C3A97DD224C5mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable OK, I'm taking a note to make it a MUST in general in the next draft, and w= e can dial back from there if there are honest, specific use cases where it= doesn't make sense.

Thanks.

 -- Justin

On Dec 2, 2014, at 3:35 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

+1 for "Making authentication to the i= ntrospection endpoint a MUST if additional attributes are present is OK"


On Tuesday, December 2, 20= 14 12:15 PM, John Bradley <ve7jtb@v= e7jtb.com> wrote:


Many of the proprietary introspection protocols in use return scope, r= ole or other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rat= her than JWT is to prevent leakage of that info.

Making authentication to the introspection end= point a MUST if additional attributes are present is OK,  I might even= be inclined to say that authentication of some sort is always required, bu= t that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this f= rom IBM, Layer 7, Ping etc.  It would be nice if we could standardize = it.   Precluding other attributes would not be helpful for adoption.


One issue that we haven=92t addressed in this = spec is what happens if there are multiple AS for the RS and how it would d= ecide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving = this for the simple case.

However having more than on e AS per RS is not= as unusual as it once was in larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. = <jricher@mitre.org> wrote:

Agreed, which = is why we've got space for the "sub" and "user_id" fiel= ds but not anything else about the user, and we've got a privacy considerat= ions section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data beyond what is strict= ly required to validate the token based solely on possession of the public = part it would be a mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, = Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's a= ll going over TLS anyway (RS->AS) just like the original token fetch by = the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) w= ith a good PoP token. 

Can you explain how this is related to "a= ct on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the= introspection endpoint returns the symmetric key?  Data about the use= r?  Where does this blur the line between this and "act on behalf of"?


On Tuesday, December 2, 2014 11:05 AM, &= quot;Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to th= e RS wouldn't necessarily have that requirement. The signature and the toke= n identifier are two different things. The identifier doesn't do an attacker any good on its own without the veri= fiable signature that's associated with it and the request. What I'm saying= is that you introspect the identifier and get back something that lets you= , the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think.  Otherwise I can as= an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








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




--_000_680A352FF1ED4CA5B0E0C3A97DD224C5mitreorg_-- From nobody Tue Dec 2 14:03:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80841A8780 for ; Tue, 2 Dec 2014 14:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of3O195Si3pp for ; Tue, 2 Dec 2014 14:02:54 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6F01A7006 for ; Tue, 2 Dec 2014 14:02:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id D0E4863841E1; Tue, 2 Dec 2014 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkQSTosPkrz5; Tue, 2 Dec 2014 14:02:51 -0800 (PST) Received: from [192.168.168.101] (unknown [192.168.168.101]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 4B29C63841B2; Tue, 2 Dec 2014 14:02:51 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C81EB212-406B-4BC7-A9E1-A21170B5F63C" From: Eve Maler In-Reply-To: Date: Tue, 2 Dec 2014 14:02:50 -0800 Message-Id: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> To: John Bradley X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nEcx-3yaojTmlahas-hx5gmG5bY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:02:58 -0000 --Apple-Mail=_C81EB212-406B-4BC7-A9E1-A21170B5F63C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, UMA goes ahead and standardizes a good deal about the trust = establishment between the RS and the AS, and (of course) profiles and = wraps the token introspection spec as part of the resulting = =E2=80=9Cauthorization API=E2=80=9D that the AS presents to the RS. A = big part of the motivation for this is to support an n:n relationship = between AS and RS entities. EVe > On 2 Dec 2014, at 12:14 PM, John Bradley wrote: >=20 > Many of the proprietary introspection protocols in use return scope, = role or other meta data for the RS to make its access policy decision = on. > One of the reasons for using opaque tokens rather than JWT is to = prevent leakage of that info. >=20 > Making authentication to the introspection endpoint a MUST if = additional attributes are present is OK, I might even be inclined to = say that authentication of some sort is always required, but that might = be going a bit far for some use cases. >=20 > We have a lot of proprietary ways to do this from IBM, Layer 7, Ping = etc. It would be nice if we could standardize it. Precluding other = attributes would not be helpful for adoption. >=20 >=20 > One issue that we haven=E2=80=99t addressed in this spec is what = happens if there are multiple AS for the RS and how it would decide what = introspection endpoint to use. > Perhaps that needs to be a extension, leaving this for the simple = case. >=20 > However having more than on e AS per RS is not as unusual as it once = was in larger environments. >=20 > John B. >=20 >=20 >> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > wrote: >>=20 >> Agreed, which is why we've got space for the "sub" and "user_id" = fields but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it. >>=20 >> -- Justin >>=20 >> On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: >>=20 >>> If introspection returns any other user data beyond what is strictly = required to validate the token based solely on possession of the public = part it would be a mistake. >>>=20 >>>=20 >>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." = > wrote: >>>=20 >>>=20 >>> That's all fine -- it's all going over TLS anyway (RS->AS) just like = the original token fetch by the client (C->AS). Doesn't mean you need = TLS *into* the RS (C->RS) with a good PoP token.=20 >>>=20 >>> Can you explain how this is related to "act on behalf of"? I don't = see any connection. >>>=20 >>> -- Justin >>>=20 >>> On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: >>>=20 >>>> Fetching the public key for a token might be fine, but what if the = introspection endpoint returns the symmetric key? Data about the user? = Where does this blur the line between this and "act on behalf of"? >>>>=20 >>>>=20 >>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." = > wrote: >>>>=20 >>>>=20 >>>> The call to introspection has a TLS requirement, but the call to = the RS wouldn't necessarily have that requirement. The signature and the = token identifier are two different things. The identifier doesn't do an = attacker any good on its own without the verifiable signature that's = associated with it and the request. What I'm saying is that you = introspect the identifier and get back something that lets you, the RS, = check the signature. >>>>=20 >>>> -- Justin >>>>=20 >>>> On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: >>>>=20 >>>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>>=20 >>>>> I don't know if that's true. POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. = Otherwise I can as an attacker take that toklen and get info about it = that might be useful, and I don't think that's what we want. >>>>>=20 >>>>> -bill >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_C81EB212-406B-4BC7-A9E1-A21170B5F63C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
FWIW, UMA goes ahead and standardizes a good = deal about the trust establishment between the RS and the AS, and (of = course) profiles and wraps the token introspection spec as part of the = resulting =E2=80=9Cauthorization API=E2=80=9D that the AS presents to = the RS. A big part of the motivation for this is to support an n:n = relationship between AS and RS entities.

EVe

On = 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Many of the = proprietary introspection protocols in use return scope, role or other = meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is = to prevent leakage of that info.

Making authentication to the = introspection endpoint a MUST if additional attributes are present is = OK,  I might even be inclined to say that authentication of some = sort is always required, but that might be going a bit far for some use = cases.

We have = a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. =  It would be nice if we could standardize it.   Precluding = other attributes would not be helpful for adoption.


One issue that we haven=E2=80=99t addressed in this spec is = what happens if there are multiple AS for the RS and how it would decide = what introspection endpoint to use.
Perhaps that = needs to be a extension, leaving this for the simple case.

However having more than = on e AS per RS is not as unusual as it once was in larger = environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. = <jricher@mitre.org> wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields = but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection = returns any other user data beyond what is strictly required to validate = the token based solely on possession of the public part it would be a mistake.


On = Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> = wrote:


That's all fine -- it's all going = over TLS anyway (RS->AS) just like the original token fetch by the = client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) = with a good PoP token. 

Can you explain how this is related to "act on behalf = of"? I don't see any connection.

 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what = if the introspection endpoint returns the symmetric key?  Data = about the user?  Where does this blur the line between this and "act on = behalf of"?


On Tuesday, December 2, 2014 11:05 = AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The = call to introspection has a TLS requirement, but the call to the RS = wouldn't necessarily have that requirement. The signature and the token = identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature = that's associated with it and the request. What I'm saying is that you = introspect the identifier and get back something that lets you, the RS, = check the signature.

 -- Justin

On = Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear = how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. =  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we = want.

-bill








_______________________________________________
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


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

= --Apple-Mail=_C81EB212-406B-4BC7-A9E1-A21170B5F63C-- From nobody Tue Dec 2 14:14:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070A11A3BA6 for ; Tue, 2 Dec 2014 14:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOFPYtJ4iA3O for ; Tue, 2 Dec 2014 14:13:56 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0191A1BFE for ; Tue, 2 Dec 2014 14:13:56 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so18300483wgg.35 for ; Tue, 02 Dec 2014 14:13:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ma2pTn/iRGzyV0hSSWzy7AU8vmki+d59e0xGZtaj+CE=; b=aHbGb5XZibAoYFdUHvKJcsQ2ki6NgT5k23J/Kt+K0mnsrF+3YKndUcYqflyx7AQvPx J2zwH+r9VwLZP1OK9/q5Lma+2N0m4+KQ2Sz3fLsH5wjTIfx5fyJAubqvrxx3UO3H8h8B 4E3zXNUympQ+1g0T7ZiHPlYxodwNs+UwlrM1vqAt4DdTN9ieJli9Izw4GDULaY1Fza/4 FHNZRoyufRUE0QvR+WNmCgUc3KlRLoVJukYCgxo38Huhl5RPfoya4zMDSJ5agrMjCg4x s2OJKz3brexc05/wXuh+A3RD8Ox3dq+dzrlmYXJtdjPuh0z/+zP87mT1lyZWDNE/UfgT 7f3w== X-Gm-Message-State: ALoCoQnpCE+Wz/T/g9nkAQFlCpqiKgexBkqP4CB8RW9/ihzM5swDBVH3IqeN46S+PLPaEhharbV1 X-Received: by 10.180.73.101 with SMTP id k5mr17431778wiv.43.1417558435001; Tue, 02 Dec 2014 14:13:55 -0800 (PST) Received: from [10.46.7.166] (188.29.165.81.threembb.co.uk. [188.29.165.81]) by mx.google.com with ESMTPSA id ec2sm34487305wib.23.2014.12.02.14.13.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 14:13:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E0357C18-8E5F-4C99-83FB-BA8E3C4BB896 Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B436) In-Reply-To: Date: Tue, 2 Dec 2014 22:13:49 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> To: Eve Maler Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/m4-y0mfgp9BMW2wzZjgn3QZoK7w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:14:00 -0000 --Apple-Mail-E0357C18-8E5F-4C99-83FB-BA8E3C4BB896 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, but unless there is something new the introspection endpoint in UMA is= tied to the resource. =20 In some cases having the token indicate the introspection endpoint may be us= eful.=20 John B.=20 Sent from my iPhone > On Dec 2, 2014, at 10:02 PM, Eve Maler wrote: >=20 > FWIW, UMA goes ahead and standardizes a good deal about the trust establis= hment between the RS and the AS, and (of course) profiles and wraps the toke= n introspection spec as part of the resulting =E2=80=9Cauthorization API=E2=80= =9D that the AS presents to the RS. A big part of the motivation for this is= to support an n:n relationship between AS and RS entities. >=20 > EVe >=20 >> On 2 Dec 2014, at 12:14 PM, John Bradley wrote: >>=20 >> Many of the proprietary introspection protocols in use return scope, role= or other meta data for the RS to make its access policy decision on. >> One of the reasons for using opaque tokens rather than JWT is to prevent l= eakage of that info. >>=20 >> Making authentication to the introspection endpoint a MUST if additional a= ttributes are present is OK, I might even be inclined to say that authentic= ation of some sort is always required, but that might be going a bit far for= some use cases. >>=20 >> We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.= It would be nice if we could standardize it. Precluding other attributes= would not be helpful for adoption. >>=20 >>=20 >> One issue that we haven=E2=80=99t addressed in this spec is what happens i= f there are multiple AS for the RS and how it would decide what introspectio= n endpoint to use. >> Perhaps that needs to be a extension, leaving this for the simple case. >>=20 >> However having more than on e AS per RS is not as unusual as it once was i= n larger environments. >>=20 >> John B. >>=20 >>=20 >>> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. wrote:= >>>=20 >>> Agreed, which is why we've got space for the "sub" and "user_id" fields b= ut not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that secti= on stronger, I'd appreciate it. >>>=20 >>> -- Justin >>>=20 >>>> On Dec 2, 2014, at 2:25 PM, Bill Mills wrote: >>>>=20 >>>> If introspection returns any other user data beyond what is strictly re= quired to validate the token based solely on possession of the public part i= t would be a mistake. >>>>=20 >>>>=20 >>>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." wrote: >>>>=20 >>>>=20 >>>> That's all fine -- it's all going over TLS anyway (RS->AS) just like th= e original token fetch by the client (C->AS). Doesn't mean you need TLS *int= o* the RS (C->RS) with a good PoP token.=20 >>>>=20 >>>> Can you explain how this is related to "act on behalf of"? I don't see a= ny connection. >>>>=20 >>>> -- Justin >>>>=20 >>>>> On Dec 2, 2014, at 2:09 PM, Bill Mills wrote:= >>>>>=20 >>>>> Fetching the public key for a token might be fine, but what if the int= rospection endpoint returns the symmetric key? Data about the user? Where d= oes this blur the line between this and "act on behalf of"? >>>>>=20 >>>>>=20 >>>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." wrote: >>>>>=20 >>>>>=20 >>>>> The call to introspection has a TLS requirement, but the call to the R= S wouldn't necessarily have that requirement. The signature and the token id= entifier are two different things. The identifier doesn't do an attacker any= good on its own without the verifiable signature that's associated with it a= nd the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>> On Dec 2, 2014, at 1:40 PM, Bill Mills wrote= : >>>>>>=20 >>>>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>>>=20 >>>>>> I don't know if that's true. POP tokens (as yet to be fully defined)= would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think. Otherwise I can as an at= tacker take that toklen and get info about it that might be useful, and I do= n't think that's what we want. >>>>>>=20 >>>>>> -bill >>>=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 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 --Apple-Mail-E0357C18-8E5F-4C99-83FB-BA8E3C4BB896 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes,  but unless there is somethi= ng new the introspection endpoint in UMA is tied to the resource.  &nbs= p;

In some cases having the token indicate the intr= ospection endpoint may be useful. 

John B.&nbs= p;

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve= Maler <eve@xmlgrrl.com> wrote:=

FWIW, UMA goes ahea= d and standardizes a good deal about the trust establishment between the RS a= nd the AS, and (of course) profiles and wraps the token introspection spec a= s part of the resulting =E2=80=9Cauthorization API=E2=80=9D that the AS pres= ents to the RS. A big part of the motivation for this is to support an n:n r= elationship between AS and RS entities.

=
EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
=
Many of the proprietary introspection protocols in u= se return scope, role or other meta data for the RS to make its access polic= y decision on.
One of the reasons for using opaque tokens rat= her than JWT is to prevent leakage of that info.

Making authentication to the introspection en= dpoint a MUST if additional attributes are present is OK,  I might even= be inclined to say that authentication of some sort is always required, but= that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this= from IBM, Layer 7, Ping etc.  It would be nice if we could standardize= it.   Precluding other attributes would not be helpful for adoption.


One issue that we haven=E2=80=99t addressed in this spec i= s what happens if there are multiple AS for the RS and how it would decide w= hat introspection endpoint to use.
Perhaps that needs t= o be a extension, leaving this for the simple case.
However having more than on e AS per RS is= not as unusual as it once was in larger environments.
=
John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P= . <jricher@mitre.org&= gt; wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields but n= ot anything else about the user, and we've got a privacy considerations sect= ion for dealing with that. If you can help make the wording on that section s= tronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
If introspection returns a= ny other user data beyond what is strictly required to validate the token ba= sed solely on possession of the public part it would be a mistake.


On Tu= esday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over T= LS anyway (RS->AS) just like the original token fetch by the client (C-&g= t;AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP to= ken. 

Can you explain how this is related to "act on behalf of"? I= don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf o= f"?




The ca= ll to introspection has a TLS requirement, but the call to the RS wouldn't n= ecessarily have that requirement. The signature and the token identifier are= two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's a= ssociated with it and the request. What I'm saying is that you introspect th= e identifier and get back something that lets you, the RS, check the signatu= re.

 = -- Justin

On Dec= 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I t= hink it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) w= ould then also have a TLS or transport security requirement unless there is t= oken introspection client auth in play I think.  Otherwise I can as an a= ttacker take that toklen and get info about it that might be useful, and I don't think that's what we want.
=

-bill








_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth

____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


Eve Maler  =                      = ;          http://www.xmlgrrl.com/blog
+1 425 345 6756 &nbs= p;                     &nb= sp; http://www.tw= itter.com/xmlgrrl

= --Apple-Mail-E0357C18-8E5F-4C99-83FB-BA8E3C4BB896-- From nobody Tue Dec 2 14:27:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C191A1BFB for ; Tue, 2 Dec 2014 14:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzr1mTagx_mC for ; Tue, 2 Dec 2014 14:26:59 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5671A1B21 for ; Tue, 2 Dec 2014 14:26:59 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E951552E0AA; Tue, 2 Dec 2014 17:26:58 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id DC94852E010; Tue, 2 Dec 2014 17:26:58 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 17:26:58 -0500 From: "Richer, Justin P." To: John Bradley Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Thread-Index: AQHQDiJoqgGZL6bZ70SXEfjMbJe4Jpx8qaoAgABMtwCAAAciAIAAAPSAgAABWoCAAAMSAIAACQgAgAAE5gCAAB4oAIAAAxKAgAAD6YA= Date: Tue, 2 Dec 2014 22:26:57 +0000 Message-ID: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ivzAoNOmjJyaGGufIDhRjcFgPZU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:27:05 -0000 --_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that there's some use in this (and in fact I've deployed a version = that uses a signed JWT to indicate its authorization server), but it should= remain outside the scope of this spec. It's a service discovery problem, i= t's orthogonal. -- Justin On Dec 2, 2014, at 5:13 PM, John Bradley > wrote: Yes, but unless there is something new the introspection endpoint in UMA i= s tied to the resource. In some cases having the token indicate the introspection endpoint may be u= seful. John B. Sent from my iPhone On Dec 2, 2014, at 10:02 PM, Eve Maler > wrote: FWIW, UMA goes ahead and standardizes a good deal about the trust establish= ment between the RS and the AS, and (of course) profiles and wraps the toke= n introspection spec as part of the resulting =93authorization API=94 that = the AS presents to the RS. A big part of the motivation for this is to supp= ort an n:n relationship between AS and RS entities. EVe On 2 Dec 2014, at 12:14 PM, John Bradley > wrote: Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on. One of the reasons for using opaque tokens rather than JWT is to prevent le= akage of that info. Making authentication to the introspection endpoint a MUST if additional at= tributes are present is OK, I might even be inclined to say that authentic= ation of some sort is always required, but that might be going a bit far fo= r some use cases. We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. = It would be nice if we could standardize it. Precluding other attributes = would not be helpful for adoption. One issue that we haven=92t addressed in this spec is what happens if there= are multiple AS for the RS and how it would decide what introspection endp= oint to use. Perhaps that needs to be a extension, leaving this for the simple case. However having more than on e AS per RS is not as unusual as it once was in= larger environments. John B. On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > wrote: Agreed, which is why we've got space for the "sub" and "user_id" fields but= not anything else about the user, and we've got a privacy considerations s= ection for dealing with that. If you can help make the wording on that sect= ion stronger, I'd appreciate it. -- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake. On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." > wrote: That's all fine -- it's all going over TLS anyway (RS->AS) just like the or= iginal token fetch by the client (C->AS). Doesn't mean you need TLS *into* = the RS (C->RS) with a good PoP token. Can you explain how this is related to "act on behalf of"? I don't see any = connection. -- Justin On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? Data about the user? Where does= this blur the line between this and "act on behalf of"? On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." > wrote: The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token identi= fier are two different things. The identifier doesn't do an attacker any go= od on its own without the verifiable signature that's associated with it an= d the request. What I'm saying is that you introspect the identifier and ge= t back something that lets you, the RS, check the signature. -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: "However, I think it's very clear how PoP tokens would work. ..." I don't know if that's true. POP tokens (as yet to be fully defined) would= then also have a TLS or transport security requirement unless there is tok= en introspection client auth in play I think. Otherwise I can as an attack= er take that toklen and get info about it that might be useful, and I don't= think that's what we want. -bill _______________________________________________ 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I agree that there's some use in this (and in fact I've deployed a version = that uses a signed JWT to indicate its authorization server), but it should= remain outside the scope of this spec. It's a service discovery problem, i= t's orthogonal. 

 -- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes,  but unless there is something new the introspection endpoin= t in UMA is tied to the resource.   

In some cases having the token indicate the introspection endpoint may= be useful. 

John B. 

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the= trust establishment between the RS and the AS, and (of course) profiles an= d wraps the token introspection spec as part of the resulting =93authorizat= ion API=94 that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationshi= p between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT = is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST = if additional attributes are present is OK,  I might even be inclined = to say that authentication of some sort is always required, but that might = be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Laye= r 7, Ping etc.  It would be nice if we could standardize it.   Pr= ecluding other attributes would not be helpful for adoption.


One issue that we haven=92t addressed in this spec is what = happens if there are multiple AS for the RS and how it would decide what in= trospection endpoint to use.
Perhaps that needs to be a extension, leaving this for the = simple case.

However having more than on e AS per RS is not as unusual a= s it once was in larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:
Agreed, which is why we've got space for the "sub" and "user= _id" fields but not anything else about the user, and we've got a priv= acy considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:<= /div>
If introspection return= s any other user data beyond what is strictly required to validate the toke= n based solely on possession of the public part it would be a mistake.


On T= uesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:<= br class=3D"">


That's all fine -- it's all going over= TLS anyway (RS->AS) just like the original token fetch by the client (C= ->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good Po= P token. 

Can you explain how this is related to "act on behalf = of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.co= m> wrote:

Fetching the public key for a token might be fine, but what if the intro= spection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between thi= s and "act on behalf of"?


On Tuesday, December 2, 2014 11:05 AM, "R= icher, Justin P." <jricher@mitre.org> wrote:


The c= all to introspection has a TLS requirement, but the call to the RS wouldn't= necessarily have that requirement. The signature and the token identifier = are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signatur= e that's associated with it and the request. What I'm saying is that you in= trospect the identifier and get back something that lets you, the RS, check= the signature.

 = ;-- Justin

On De= c 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"How= ever, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) = would then also have a TLS or transport security requirement unless there i= s token introspection client auth in play I think.  Otherwise I can as= an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








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

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


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


--_000_C62B72064F9F4FB2A7AE6C2EB55C09D1mitreorg_-- From nobody Tue Dec 2 15:39:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470551A1BD2 for ; Tue, 2 Dec 2014 15:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.709 X-Spam-Level: X-Spam-Status: No, score=-3.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7njGXjgYnIVs for ; Tue, 2 Dec 2014 15:38:59 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6DC1A1B8A for ; Tue, 2 Dec 2014 15:38:59 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB2NcwsD007338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Dec 2014 23:38:58 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB2NcvZb001152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Dec 2014 23:38:57 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB2Ncuj1009816; Tue, 2 Dec 2014 23:38:56 GMT Received: from [25.64.176.77] (/72.143.234.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Dec 2014 15:38:56 -0800 References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2BFE1D0A-B933-4D0E-9546-17DB2160D35F Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Tue, 2 Dec 2014 15:38:50 -0800 To: "Richer, Justin P." X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UjgHX0tqah_RSTn1iBsNeF9rT_Q Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 23:39:02 -0000 --Apple-Mail-2BFE1D0A-B933-4D0E-9546-17DB2160D35F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am confused. Why would you call the introspection endpoint if you were not= expecting new information to be disclosed? Phil > On Dec 2, 2014, at 14:26, Richer, Justin P. wrote: >=20 > I agree that there's some use in this (and in fact I've deployed a version= that uses a signed JWT to indicate its authorization server), but it should= remain outside the scope of this spec. It's a service discovery problem, it= 's orthogonal.=20 >=20 > -- Justin >=20 >=20 >> On Dec 2, 2014, at 5:13 PM, John Bradley wrote: >>=20 >> Yes, but unless there is something new the introspection endpoint in UMA= is tied to the resource. =20 >>=20 >> In some cases having the token indicate the introspection endpoint may be= useful.=20 >>=20 >> John B.=20 >>=20 >> Sent from my iPhone >>=20 >> On Dec 2, 2014, at 10:02 PM, Eve Maler wrote: >>=20 >>> FWIW, UMA goes ahead and standardizes a good deal about the trust establ= ishment between the RS and the AS, and (of course) profiles and wraps the to= ken introspection spec as part of the resulting =E2=80=9Cauthorization API=E2= =80=9D that the AS presents to the RS. A big part of the motivation for this= is to support an n:n relationship between AS and RS entities. >>>=20 >>> EVe >>>=20 >>>> On 2 Dec 2014, at 12:14 PM, John Bradley wrote: >>>>=20 >>>> Many of the proprietary introspection protocols in use return scope, ro= le or other meta data for the RS to make its access policy decision on. >>>> One of the reasons for using opaque tokens rather than JWT is to preven= t leakage of that info. >>>>=20 >>>> Making authentication to the introspection endpoint a MUST if additiona= l attributes are present is OK, I might even be inclined to say that authen= tication of some sort is always required, but that might be going a bit far f= or some use cases. >>>>=20 >>>> We have a lot of proprietary ways to do this from IBM, Layer 7, Ping et= c. It would be nice if we could standardize it. Precluding other attribut= es would not be helpful for adoption. >>>>=20 >>>>=20 >>>> One issue that we haven=E2=80=99t addressed in this spec is what happen= s if there are multiple AS for the RS and how it would decide what introspec= tion endpoint to use. >>>> Perhaps that needs to be a extension, leaving this for the simple case.= >>>>=20 >>>> However having more than on e AS per RS is not as unusual as it once wa= s in larger environments. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. wrot= e: >>>>>=20 >>>>> Agreed, which is why we've got space for the "sub" and "user_id" field= s but not anything else about the user, and we've got a privacy consideratio= ns section for dealing with that. If you can help make the wording on that s= ection stronger, I'd appreciate it. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>> On Dec 2, 2014, at 2:25 PM, Bill Mills wrote= : >>>>>>=20 >>>>>> If introspection returns any other user data beyond what is strictly r= equired to validate the token based solely on possession of the public part i= t would be a mistake. >>>>>>=20 >>>>>>=20 >>>>>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." wrote: >>>>>>=20 >>>>>>=20 >>>>>> That's all fine -- it's all going over TLS anyway (RS->AS) just like t= he original token fetch by the client (C->AS). Doesn't mean you need TLS *in= to* the RS (C->RS) with a good PoP token.=20 >>>>>>=20 >>>>>> Can you explain how this is related to "act on behalf of"? I don't se= e any connection. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>>> On Dec 2, 2014, at 2:09 PM, Bill Mills wrot= e: >>>>>>>=20 >>>>>>> Fetching the public key for a token might be fine, but what if the i= ntrospection endpoint returns the symmetric key? Data about the user? Wher= e does this blur the line between this and "act on behalf of"? >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> The call to introspection has a TLS requirement, but the call to the= RS wouldn't necessarily have that requirement. The signature and the token i= dentifier are two different things. The identifier doesn't do an attacker an= y good on its own without the verifiable signature that's associated with it= and the request. What I'm saying is that you introspect the identifier and g= et back something that lets you, the RS, check the signature. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>> On Dec 2, 2014, at 1:40 PM, Bill Mills wro= te: >>>>>>>>=20 >>>>>>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>>>>>=20 >>>>>>>> I don't know if that's true. POP tokens (as yet to be fully define= d) would then also have a TLS or transport security requirement unless there= is token introspection client auth in play I think. Otherwise I can as an a= ttacker take that toklen and get info about it that might be useful, and I d= on't think that's what we want. >>>>>>>>=20 >>>>>>>> -bill >>>>>=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 >>>=20 >>>=20 >>> Eve Maler http://www.xmlgrrl.com/blog >>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2BFE1D0A-B933-4D0E-9546-17DB2160D35F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am confused. Why would you call the i= ntrospection endpoint if you were not expecting new information to be disclo= sed?

Phil

On Dec 2, 2014, at 14:26, Richer, Justin P. &= lt;jricher@mitre.org> wrote:
=
I agree that there's some use in this (and in fact I've deployed a version t= hat uses a signed JWT to indicate its authorization server), but it should r= emain outside the scope of this spec. It's a service discovery problem, it's= orthogonal. 

 -- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes,  but unless there is something new the introspection endpoint= in UMA is tied to the resource.   

In some cases having the token indicate the introspection endpoint may b= e useful. 

John B. 

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the t= rust establishment between the RS and the AS, and (of course) profiles and w= raps the token introspection spec as part of the resulting =E2=80=9Cauthoriz= ation API=E2=80=9D that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationship= between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role or= other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT i= s to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST i= f additional attributes are present is OK,  I might even be inclined to= say that authentication of some sort is always required, but that might be g= oing a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Layer= 7, Ping etc.  It would be nice if we could standardize it.   Prec= luding other attributes would not be helpful for adoption.


One issue that we haven=E2=80=99t addressed in this spec is w= hat happens if there are multiple AS for the RS and how it would decide what= introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the s= imple case.

However having more than on e AS per RS is not as unusual as= it once was in larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:
=
Agreed, which is why we've got space for the "sub" and "user_id" fields but n= ot anything else about the user, and we've got a privacy considerations sect= ion for dealing with that. If you can help make the wording on that section s= tronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
If introspection returns a= ny other user data beyond what is strictly required to validate the token ba= sed solely on possession of the public part it would be a mistake.


On Tu= esday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over T= LS anyway (RS->AS) just like the original token fetch by the client (C-&g= t;AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP to= ken. 

Can you explain how this is related to "act on behalf of"? I= don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this= and "act on behalf of"?




The ca= ll to introspection has a TLS requirement, but the call to the RS wouldn't n= ecessarily have that requirement. The signature and the token identifier are= two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature= that's associated with it and the request. What I'm saying is that you intr= ospect the identifier and get back something that lets you, the RS, check th= e signature.

 = -- Justin

On Dec= 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I t= hink it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) w= ould then also have a TLS or transport security requirement unless there is t= oken introspection client auth in play I think.  Otherwise I can as an a= ttacker take that toklen and get info about it that might be useful, and I don't think that's what we want.
=

-bill








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

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


= Eve Maler                   &nb= sp;              http://www.xmlgrrl.com/blog
+1 425 345 6756                 &nbs= p;       http://www.twitter.com/xmlgrrl


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-2BFE1D0A-B933-4D0E-9546-17DB2160D35F-- From nobody Tue Dec 2 17:05:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1103C1A1AF1 for ; Tue, 2 Dec 2014 17:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY13joTjQjvw for ; Tue, 2 Dec 2014 17:04:55 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73B31A1A69 for ; Tue, 2 Dec 2014 17:04:53 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-fa-547e61b3e070 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.6E.03354.3B16E745; Tue, 2 Dec 2014 20:04:51 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB314pGi020744; Tue, 2 Dec 2014 20:04:51 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB314n74029090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Dec 2014 20:04:50 -0500 Message-ID: <547E61AC.4040100@mit.edu> Date: Tue, 02 Dec 2014 20:04:44 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030109050803020601030007" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixCmqrLs5sS7EYNEhc4uTb1+xWSyY38ju wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGVM+LCateD4HOaKLRNOszYw/l/I2MXIySEh YCIxYf4kVghbTOLCvfVsXYxcHEICi5kkNq5rYIRwNjBKTJ/YxArh3GKS+LO5lwWkhVdATeLx unYwm0VAVeLkn7fsIDYbkD19TQsTiC0qECVx51I/K0S9oMTJmU/A6kUEVCS+Xb0OdgYzUP36 1RfB6oUFnCVuzDzDArFsC7NE8+PnYEM5BewkVtw5yQrRECZxZ+VKxgmMArOQzJ2FJDWLkQPI tpb4trsIIiwvsf3tHGYIW1tiVe9ZJmTxBYxsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIz S/RSU0o3MYLDXpJ/B+O3g0qHGAU4GJV4eB9E14UIsSaWFVfmHmKU5GBSEuVdnQAU4kvKT6nM SCzOiC8qzUktPsQowcGsJMKbZweU401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoE k5Xh4FCS4J0IMlSwKDU9tSItM6cEIc3EwQkynAdo+HqQGt7igsTc4sx0iPwpRkUpcd5wkIQA SCKjNA+uF5aWXjGKA70izPsPpIoHmNLgul8BDWYCGny2oRZkcEkiQkqqgVGUYUV/ksH2Kz82 ZG9w/y59lI/3lFiINHfHN7UzAcbVAvcKVoiqvnGwcIhb/9Ru9vq/T3bNvOXffXZixfnUVod6 t/Itbrcfpz6Rf5KiIHu0hLXuY9rx95JBuXoOgfFpv3tOMbz6utT++r5VtTcdgs44P1ML5OEz rj3P/u35rxZpqcsmtk8WvFFiKc5INNRiLipOBADu/Fs7JgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q3aQ-ViHmGTF_CqjviPWsApc3KY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 01:05:01 -0000 This is a multi-part message in MIME format. --------------030109050803020601030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nothing says you need to pack the same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the information inside the JWT includes an "iss" claim which the client can use to figure out *which* introspection endpoint to call. This is just one of many different ways you could handle multiple AS at a single resource, and so it's definitely orthogonal to the basic introspection concept. -- Justin On 12/2/2014 6:38 PM, Phil Hunt wrote: > I am confused. Why would you call the introspection endpoint if you > were not expecting new information to be disclosed? > > Phil > > On Dec 2, 2014, at 14:26, Richer, Justin P. > wrote: > >> I agree that there's some use in this (and in fact I've deployed a >> version that uses a signed JWT to indicate its authorization server), >> but it should remain outside the scope of this spec. It's a service >> discovery problem, it's orthogonal. >> >> -- Justin >> >> >> On Dec 2, 2014, at 5:13 PM, John Bradley > > wrote: >> >>> Yes, but unless there is something new the introspection endpoint >>> in UMA is tied to the resource. >>> >>> In some cases having the token indicate the introspection endpoint >>> may be useful. >>> >>> John B. >>> >>> Sent from my iPhone >>> >>> On Dec 2, 2014, at 10:02 PM, Eve Maler >> > wrote: >>> >>>> FWIW, UMA goes ahead and standardizes a good deal about the trust >>>> establishment between the RS and the AS, and (of course) profiles >>>> and wraps the token introspection spec as part of the resulting >>>> "authorization API" that the AS presents to the RS. A big part of >>>> the motivation for this is to support an n:n relationship between >>>> AS and RS entities. >>>> >>>> EVe >>>> >>>>> On 2 Dec 2014, at 12:14 PM, John Bradley >>>> > wrote: >>>>> >>>>> Many of the proprietary introspection protocols in use return >>>>> scope, role or other meta data for the RS to make its access >>>>> policy decision on. >>>>> One of the reasons for using opaque tokens rather than JWT is to >>>>> prevent leakage of that info. >>>>> >>>>> Making authentication to the introspection endpoint a MUST if >>>>> additional attributes are present is OK, I might even be inclined >>>>> to say that authentication of some sort is always required, but >>>>> that might be going a bit far for some use cases. >>>>> >>>>> We have a lot of proprietary ways to do this from IBM, Layer 7, >>>>> Ping etc. It would be nice if we could standardize it. >>>>> Precluding other attributes would not be helpful for adoption. >>>>> >>>>> >>>>> One issue that we haven't addressed in this spec is what happens >>>>> if there are multiple AS for the RS and how it would decide what >>>>> introspection endpoint to use. >>>>> Perhaps that needs to be a extension, leaving this for the simple >>>>> case. >>>>> >>>>> However having more than on e AS per RS is not as unusual as it >>>>> once was in larger environments. >>>>> >>>>> John B. >>>>> >>>>> >>>>>> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. >>>>> > wrote: >>>>>> >>>>>> Agreed, which is why we've got space for the "sub" and "user_id" >>>>>> fields but not anything else about the user, and we've got a >>>>>> privacy considerations section for dealing with that. If you can >>>>>> help make the wording on that section stronger, I'd appreciate it. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On Dec 2, 2014, at 2:25 PM, Bill Mills >>>>> > wrote: >>>>>> >>>>>>> If introspection returns any other user data beyond what is >>>>>>> strictly required to validate the token based solely on >>>>>>> possession of the public part it would be a mistake. >>>>>>> >>>>>>> >>>>>>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> That's all fine -- it's all going over TLS anyway (RS->AS) just >>>>>>> like the original token fetch by the client (C->AS). Doesn't >>>>>>> mean you need TLS *into* the RS (C->RS) with a good PoP token. >>>>>>> >>>>>>> Can you explain how this is related to "act on behalf of"? I >>>>>>> don't see any connection. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On Dec 2, 2014, at 2:09 PM, Bill Mills >>>>>> > wrote: >>>>>>> >>>>>>>> Fetching the public key for a token might be fine, but what if >>>>>>>> the introspection endpoint returns the symmetric key? Data >>>>>>>> about the user? Where does this blur the line between this and >>>>>>>> "act on behalf of"? >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> The call to introspection has a TLS requirement, but the call >>>>>>>> to the RS wouldn't necessarily have that requirement. The >>>>>>>> signature and the token identifier are two different things. >>>>>>>> The identifier doesn't do an attacker any good on its own >>>>>>>> without the verifiable signature that's associated with it and >>>>>>>> the request. What I'm saying is that you introspect the >>>>>>>> identifier and get back something that lets you, the RS, check >>>>>>>> the signature. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> On Dec 2, 2014, at 1:40 PM, Bill Mills >>>>>>> > wrote: >>>>>>>> >>>>>>>>> "However, I think it's very clear how PoP tokens would work. ..." >>>>>>>>> >>>>>>>>> I don't know if that's true. POP tokens (as yet to be fully >>>>>>>>> defined) would then also have a TLS or transport security >>>>>>>>> requirement unless there is token introspection client auth in >>>>>>>>> play I think. Otherwise I can as an attacker take that toklen >>>>>>>>> and get info about it that might be useful, and I don't think >>>>>>>>> that's what we want. >>>>>>>>> >>>>>>>>> -bill >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> Eve Maler http://www.xmlgrrl.com/blog >>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>>> >> >> _______________________________________________ >> 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 --------------030109050803020601030007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Nothing says you need to pack the same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the information inside the JWT includes an "iss" claim which the client can use to figure out *which* introspection endpoint to call.

This is just one of many different ways you could handle multiple AS at a single resource, and so it's definitely orthogonal to the basic introspection concept.

 -- Justin

On 12/2/2014 6:38 PM, Phil Hunt wrote:
I am confused. Why would you call the introspection endpoint if you were not expecting new information to be disclosed?

Phil

On Dec 2, 2014, at 14:26, Richer, Justin P. <jricher@mitre.org> wrote:

I agree that there's some use in this (and in fact I've deployed a version that uses a signed JWT to indicate its authorization server), but it should remain outside the scope of this spec. It's a service discovery problem, it's orthogonal. 

 -- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes,  but unless there is something new the introspection endpoint in UMA is tied to the resource.   

In some cases having the token indicate the introspection endpoint may be useful. 

John B. 

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting “authorization API” that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationship between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST if additional attributes are present is OK,  I might even be inclined to say that authentication of some sort is always required, but that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.  It would be nice if we could standardize it.   Precluding other attributes would not be helpful for adoption.


One issue that we haven’t addressed in this spec is what happens if there are multiple AS for the RS and how it would decide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the simple case.

However having more than on e AS per RS is not as unusual as it once was in larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token. 

Can you explain how this is related to "act on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf of"?


On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








_______________________________________________
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


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


_______________________________________________
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

--------------030109050803020601030007-- From nobody Tue Dec 2 17:26:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25E01A1BD7 for ; Tue, 2 Dec 2014 17:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPI8diE4f8NE for ; Tue, 2 Dec 2014 17:26:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A8B1A1BC0 for ; Tue, 2 Dec 2014 17:26:04 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB31Q1wv029989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Dec 2014 01:26:02 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB31Q0Ze017715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2014 01:26:01 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB31Q0kq010076; Wed, 3 Dec 2014 01:26:00 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Dec 2014 17:25:59 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8E98257-2CDB-4927-81C2-7C76E22E17F5" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: <547E61AC.4040100@mit.edu> Date: Tue, 2 Dec 2014 17:25:58 -0800 Message-Id: References: <46D29E35-5A69-4687-BC44-45462DEA8D47@mitre.org> <580238515.3962316.1417548302668.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> <547E61AC.4040100@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1993) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/urPBVwz1wYa1vGQyPrBSdhnAr8A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 01:26:08 -0000 --Apple-Mail=_F8E98257-2CDB-4927-81C2-7C76E22E17F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I was asking in the context of the thread where the comment was made = that you only need to authenticate if more information is provided. This didn=92t make sense to me. Because you would never make the call to = re-confirm (pointless). Even a caller re-confirming is actually checking = for more information - to see if the assertion has been revoked. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 2, 2014, at 5:04 PM, Justin Richer wrote: >=20 > Nothing says you need to pack the same information inside the JWT that = you return from introspection. In our specific case, we don't put scopes = or client IDs inside the JWT, just basic signature/identifier type = stuff, so you need to call introspection to get back this other = information. But the information inside the JWT includes an "iss" claim = which the client can use to figure out *which* introspection endpoint to = call. >=20 > This is just one of many different ways you could handle multiple AS = at a single resource, and so it's definitely orthogonal to the basic = introspection concept. >=20 > -- Justin >=20 > On 12/2/2014 6:38 PM, Phil Hunt wrote: >> I am confused. Why would you call the introspection endpoint if you = were not expecting new information to be disclosed? >>=20 >> Phil >>=20 >> On Dec 2, 2014, at 14:26, Richer, Justin P. > wrote: >>=20 >>> I agree that there's some use in this (and in fact I've deployed a = version that uses a signed JWT to indicate its authorization server), = but it should remain outside the scope of this spec. It's a service = discovery problem, it's orthogonal.=20 >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On Dec 2, 2014, at 5:13 PM, John Bradley > wrote: >>>=20 >>>> Yes, but unless there is something new the introspection endpoint = in UMA is tied to the resource. =20 >>>>=20 >>>> In some cases having the token indicate the introspection endpoint = may be useful.=20 >>>>=20 >>>> John B.=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Dec 2, 2014, at 10:02 PM, Eve Maler > wrote: >>>>=20 >>>>> FWIW, UMA goes ahead and standardizes a good deal about the trust = establishment between the RS and the AS, and (of course) profiles and = wraps the token introspection spec as part of the resulting = =93authorization API=94 that the AS presents to the RS. A big part of = the motivation for this is to support an n:n relationship between AS and = RS entities. >>>>>=20 >>>>> EVe >>>>>=20 >>>>>> On 2 Dec 2014, at 12:14 PM, John Bradley > wrote: >>>>>>=20 >>>>>> Many of the proprietary introspection protocols in use return = scope, role or other meta data for the RS to make its access policy = decision on. >>>>>> One of the reasons for using opaque tokens rather than JWT is to = prevent leakage of that info. >>>>>>=20 >>>>>> Making authentication to the introspection endpoint a MUST if = additional attributes are present is OK, I might even be inclined to = say that authentication of some sort is always required, but that might = be going a bit far for some use cases. >>>>>>=20 >>>>>> We have a lot of proprietary ways to do this from IBM, Layer 7, = Ping etc. It would be nice if we could standardize it. Precluding = other attributes would not be helpful for adoption. >>>>>>=20 >>>>>>=20 >>>>>> One issue that we haven=92t addressed in this spec is what = happens if there are multiple AS for the RS and how it would decide what = introspection endpoint to use. >>>>>> Perhaps that needs to be a extension, leaving this for the simple = case. >>>>>>=20 >>>>>> However having more than on e AS per RS is not as unusual as it = once was in larger environments. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>> On Dec 2, 2014, at 4:56 PM, Richer, Justin P. > wrote: >>>>>>>=20 >>>>>>> Agreed, which is why we've got space for the "sub" and "user_id" = fields but not anything else about the user, and we've got a privacy = considerations section for dealing with that. If you can help make the = wording on that section stronger, I'd appreciate it. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On Dec 2, 2014, at 2:25 PM, Bill Mills > wrote: >>>>>>>=20 >>>>>>>> If introspection returns any other user data beyond what is = strictly required to validate the token based solely on possession of = the public part it would be a mistake. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." = > wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> That's all fine -- it's all going over TLS anyway (RS->AS) just = like the original token fetch by the client (C->AS). Doesn't mean you = need TLS *into* the RS (C->RS) with a good PoP token.=20 >>>>>>>>=20 >>>>>>>> Can you explain how this is related to "act on behalf of"? I = don't see any connection. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On Dec 2, 2014, at 2:09 PM, Bill Mills > wrote: >>>>>>>>=20 >>>>>>>>> Fetching the public key for a token might be fine, but what if = the introspection endpoint returns the symmetric key? Data about the = user? Where does this blur the line between this and "act on behalf = of"? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." = > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The call to introspection has a TLS requirement, but the call = to the RS wouldn't necessarily have that requirement. The signature and = the token identifier are two different = things. The identifier doesn't do an attacker = any good on its own without the verifiable signature that's associated = with it and the request. What I'm saying is that you introspect = the identifier and get = back something that lets you, the RS, check the signature. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>> On Dec 2, 2014, at 1:40 PM, Bill Mills > wrote: >>>>>>>>>=20 >>>>>>>>>> "However, I think it's very clear how PoP tokens would work. = ..." >>>>>>>>>>=20 >>>>>>>>>> I don't know if that's true. POP tokens (as yet to be fully = defined) would then also have a TLS or transport security requirement = unless there is token introspection client auth in play I think. = Otherwise I can as an attacker take that toklen and get info about it = that might be useful, and I don't think that's what we want. >>>>>>>>>>=20 >>>>>>>>>> -bill >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=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 = >>>>>=20 >>>>>=20 >>>>> Eve Maler = http://www.xmlgrrl.com/blog >>>>> +1 425 345 6756 = http://www.twitter.com/xmlgrrl >>>=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 = >=20 --Apple-Mail=_F8E98257-2CDB-4927-81C2-7C76E22E17F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I was asking in the context of the thread where the comment = was made that you only need to authenticate if more information is = provided.

This = didn=92t make sense to me. Because you would never make the call to = re-confirm (pointless). Even a caller re-confirming is actually checking = for more information - to see if the assertion has been = revoked.


On Dec 2, 2014, at 5:04 PM, Justin Richer <jricher@mit.edu> = wrote:

=20 =20
Nothing says you need to pack the = same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the information inside the JWT includes an "iss" claim which the client can use to figure out *which* introspection endpoint to call.

This is just one of many different ways you could handle multiple AS at a single resource, and so it's definitely orthogonal to the basic introspection concept.

 -- Justin

On 12/2/2014 6:38 PM, Phil Hunt wrote:
I am confused. Why would you call the = introspection endpoint if you were not expecting new information to be disclosed?

Phil

On Dec 2, 2014, at 14:26, Richer, Justin P. <jricher@mitre.org> wrote:

I agree that there's some use in this (and in fact I've deployed a version that uses a signed JWT to indicate its authorization server), but it should remain outside the scope of this spec. It's a service discovery problem, it's orthogonal. 

 -- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:

Yes,  but unless there is = something new the introspection endpoint in UMA is tied to the resource.   

In some cases having the token = indicate the introspection endpoint may be useful. 

John B. 

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and = standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting =93authorization API=94 that the AS = presents to the RS. A big part of the motivation for this is to support an n:n relationship between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST if additional attributes are present is OK,  I might even be inclined to say that authentication of some sort is always required, but that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.  It would be nice if we could standardize it.   Precluding other attributes would not be helpful for adoption.


One issue that we haven=92t addressed in this spec is what happens if there are multiple AS for the RS and how it would decide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the simple case.

However having more than on = e AS per RS is not as unusual as it once was in larger environments.

John B.


On Dec 2, 2014, at = 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:

=
Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- = Justin

On Dec 2, = 2014, at 2:25 PM, Bill Mills = <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a = mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token. 

Can you explain how this is related to "act on behalf of"? I don't see any = connection.

 -- Justin

=
On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data = about the user?  Where = does this blur the line between this and "act on behalf = of"?


On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. = ..."

I don't know if that's true. =  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think. =  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill








_______________________________________________
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


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


_______________________________________________
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


= --Apple-Mail=_F8E98257-2CDB-4927-81C2-7C76E22E17F5-- From nobody Tue Dec 2 17:37:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6821A1BD7 for ; Tue, 2 Dec 2014 17:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vocEb3opkMNb for ; Tue, 2 Dec 2014 17:37:09 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171851A1AEB for ; Tue, 2 Dec 2014 17:37:06 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-a7-547e6941f79c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FF.28.03326.1496E745; Tue, 2 Dec 2014 20:37:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB31b44w023512; Tue, 2 Dec 2014 20:37:05 -0500 Received: from [IPv6:2607:fb90:2402:7470:0:44:6067:c801] (ma52536d0.tmodns.net [208.54.37.165]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB31b0c2006326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Dec 2014 20:37:01 -0500 Date: Tue, 02 Dec 2014 20:36:59 -0500 Message-ID: Importance: normal From: Justin Richer To: Phil Hunt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1969588829164290" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrOuYWRdisP+JssXJt6/YLBbMb2R3 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDJ+7ZzBUrBgOkvFu72n2RsYV3SydDFycEgI mEj8ma7TxcgJZIpJXLi3ng3EFhJYzCRxbFd5FyMXkL2BUaKlaRsrhHOBSWLrg83sIFUsAqoS 847fA7OFBZwlbsw8wwJi8wq4SVy9fJEZZAGngJBE1y4JkDAbUPn0NS1MILaIgIrEt6vXGUFs ZqD4lwXvmSBaBSVOznzCAhEPldj24y7zBEa+WUhSs5CkIGx1iT/zLkHZihJTuh+yzwLazCyg JrGsVQlZeAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzg8JXk28H49aDS IUYBDkYlHl6LuLoQIdbEsuLK3EOMkhxMSqK8P5OBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 s5OAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErwV6UCNgkWp6akV aZk5JQhpJg5OkOE8QMOPpYEMLy5IzC3OTIfIn2JUlBLnTQdpFgBJZJTmwfXC0ssrRnGgV4R5 T4JU8QBTE1z3K6DBTECDzzbUggwuSURISTUwtjOcilQ95ju5J+5t0eGLM97qZDrGWF7XEZJX WFJ0ds10tWCWBXb+HDGrJYyuCpw9Yqv+0XaS4t2mrLZKP2Hm2dOZnnBwf5HJvPj5RcnG2V67 /fc903dvFP7zZk3pSc6fq34Ed/xlCUxl/3J2v9ffoNcvv2+L3/rhOf8HttKnfP4bZX3Wssfu U2Ipzkg01GIuKk4EAAsPlQIKAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W1Pke27WXNWyB08IZ_Gk3KlT5_A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 01:37:14 -0000 ----_com.android.email_1969588829164290 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWgsIEkgdGhpbmsgSSBnb3QgbXkgdGhyZWFkcyBjcm9zc2VkLiBUaGVuIHllcywgSSBhZ3JlZSB3 aXRoIHlvdSwgYW5kIEknbSBnb2luZyB0byBiZSBtYWtpbmcgYXV0aG9yaXphdGlvbiBhIE1VU1Qg aW5zdGVhZCBvZiBhIFNIT1VMRC4gV291bGQgbG92ZSB0byBoZWFyIGZlZWRiYWNrIGZyb20gb3Ro ZXIgaW1wbGVtZW50ZXJzIG9uIHRoaXMgcG9pbnQuwqAKCgotLSBKdXN0aW4KCi8gU2VudCBmcm9t IG15IHBob25lIC8KCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+IApEYXRlOjEyLzAyLzIwMTQgIDg6MjUgUE0g IChHTVQtMDU6MDApIApUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiAKQ2M6IG9h dXRoQGlldGYub3JnIApTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZXZpZXcgb2YgZHJhZnQtaWV0 Zi1vYXV0aC1pbnRyb3NwZWN0aW9uLTAxIAoKSSB3YXMgYXNraW5nIGluIHRoZSBjb250ZXh0IG9m IHRoZSB0aHJlYWQgd2hlcmUgdGhlIGNvbW1lbnQgd2FzIG1hZGUgdGhhdCB5b3Ugb25seSBuZWVk IHRvIGF1dGhlbnRpY2F0ZSBpZiBtb3JlIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkLgoKVGhpcyBk aWRu4oCZdCBtYWtlIHNlbnNlIHRvIG1lLiBCZWNhdXNlIHlvdSB3b3VsZCBuZXZlciBtYWtlIHRo ZSBjYWxsIHRvIHJlLWNvbmZpcm0gKHBvaW50bGVzcykuIEV2ZW4gYSBjYWxsZXIgcmUtY29uZmly bWluZyBpcyBhY3R1YWxseSBjaGVja2luZyBmb3IgbW9yZSBpbmZvcm1hdGlvbiAtIHRvIHNlZSBp ZiB0aGUgYXNzZXJ0aW9uIGhhcyBiZWVuIHJldm9rZWQuCgpQaGlsCgpAaW5kZXBlbmRlbnRpZAp3 d3cuaW5kZXBlbmRlbnRpZC5jb20KcGhpbC5odW50QG9yYWNsZS5jb20KCk9uIERlYyAyLCAyMDE0 LCBhdCA1OjA0IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOgoKTm90 aGluZyBzYXlzIHlvdSBuZWVkIHRvIHBhY2sgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW5zaWRlIHRo ZSBKV1QgdGhhdCB5b3UgcmV0dXJuIGZyb20gaW50cm9zcGVjdGlvbi4gSW4gb3VyIHNwZWNpZmlj IGNhc2UsIHdlIGRvbid0IHB1dCBzY29wZXMgb3IgY2xpZW50IElEcyBpbnNpZGUgdGhlIEpXVCwg anVzdCBiYXNpYyBzaWduYXR1cmUvaWRlbnRpZmllciB0eXBlIHN0dWZmLCBzbyB5b3UgbmVlZCB0 byBjYWxsIGludHJvc3BlY3Rpb24gdG8gZ2V0IGJhY2sgdGhpcyBvdGhlciBpbmZvcm1hdGlvbi4g QnV0IHRoZSBpbmZvcm1hdGlvbiBpbnNpZGUgdGhlIEpXVCBpbmNsdWRlcyBhbiAiaXNzIiBjbGFp bSB3aGljaCB0aGUgY2xpZW50IGNhbiB1c2UgdG8gZmlndXJlIG91dCAqd2hpY2gqIGludHJvc3Bl Y3Rpb24gZW5kcG9pbnQgdG8gY2FsbC4KClRoaXMgaXMganVzdCBvbmUgb2YgbWFueSBkaWZmZXJl bnQgd2F5cyB5b3UgY291bGQgaGFuZGxlIG11bHRpcGxlIEFTIGF0IGEgc2luZ2xlIHJlc291cmNl LCBhbmQgc28gaXQncyBkZWZpbml0ZWx5IG9ydGhvZ29uYWwgdG8gdGhlIGJhc2ljIGludHJvc3Bl Y3Rpb24gY29uY2VwdC4KCiAtLSBKdXN0aW4KCk9uIDEyLzIvMjAxNCA2OjM4IFBNLCBQaGlsIEh1 bnQgd3JvdGU6CkkgYW0gY29uZnVzZWQuIFdoeSB3b3VsZCB5b3UgY2FsbCB0aGUgaW50cm9zcGVj dGlvbiBlbmRwb2ludCBpZiB5b3Ugd2VyZSBub3QgZXhwZWN0aW5nIG5ldyBpbmZvcm1hdGlvbiB0 byBiZSBkaXNjbG9zZWQ/CgpQaGlsCgpPbiBEZWMgMiwgMjAxNCwgYXQgMTQ6MjYsIFJpY2hlciwg SnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZz4gd3JvdGU6CgpJIGFncmVlIHRoYXQgdGhlcmUn cyBzb21lIHVzZSBpbiB0aGlzIChhbmQgaW4gZmFjdCBJJ3ZlIGRlcGxveWVkIGEgdmVyc2lvbiB0 aGF0IHVzZXMgYSBzaWduZWQgSldUIHRvIGluZGljYXRlIGl0cyBhdXRob3JpemF0aW9uIHNlcnZl ciksIGJ1dCBpdCBzaG91bGQgcmVtYWluIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlYy4g SXQncyBhIHNlcnZpY2UgZGlzY292ZXJ5IHByb2JsZW0sIGl0J3Mgb3J0aG9nb25hbC4KCiAtLSBK dXN0aW4KCgpPbiBEZWMgMiwgMjAxNCwgYXQgNToxMyBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbT4gd3JvdGU6CgpZZXMsIGJ1dCB1bmxlc3MgdGhlcmUgaXMgc29tZXRoaW5nIG5l dyB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBpbiBVTUEgaXMgdGllZCB0byB0aGUgcmVzb3Vy Y2UuCgpJbiBzb21lIGNhc2VzIGhhdmluZyB0aGUgdG9rZW4gaW5kaWNhdGUgdGhlIGludHJvc3Bl Y3Rpb24gZW5kcG9pbnQgbWF5IGJlIHVzZWZ1bC4KCkpvaG4gQi4KClNlbnQgZnJvbSBteSBpUGhv bmUKCk9uIERlYyAyLCAyMDE0LCBhdCAxMDowMiBQTSwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5j b20+IHdyb3RlOgoKRldJVywgVU1BIGdvZXMgYWhlYWQgYW5kIHN0YW5kYXJkaXplcyBhIGdvb2Qg ZGVhbCBhYm91dCB0aGUgdHJ1c3QgZXN0YWJsaXNobWVudCBiZXR3ZWVuIHRoZSBSUyBhbmQgdGhl IEFTLCBhbmQgKG9mIGNvdXJzZSkgcHJvZmlsZXMgYW5kIHdyYXBzIHRoZSB0b2tlbiBpbnRyb3Nw ZWN0aW9uIHNwZWMgYXMgcGFydCBvZiB0aGUgcmVzdWx0aW5nIOKAnGF1dGhvcml6YXRpb24gQVBJ 4oCdIHRoYXQgdGhlIEFTIHByZXNlbnRzIHRvIHRoZSBSUy4gQSBiaWcgcGFydCBvZiB0aGUgbW90 aXZhdGlvbiBmb3IgdGhpcyBpcyB0byBzdXBwb3J0IGFuIG46biByZWxhdGlvbnNoaXAgYmV0d2Vl biBBUyBhbmQgUlMgZW50aXRpZXMuCgpFVmUKCk9uIDIgRGVjIDIwMTQsIGF0IDEyOjE0IFBNLCBK b2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiB3cm90ZToKCk1hbnkgb2YgdGhlIHByb3By aWV0YXJ5IGludHJvc3BlY3Rpb24gcHJvdG9jb2xzIGluIHVzZSByZXR1cm4gc2NvcGUsIHJvbGUg b3Igb3RoZXIgbWV0YSBkYXRhIGZvciB0aGUgUlMgdG8gbWFrZSBpdHMgYWNjZXNzIHBvbGljeSBk ZWNpc2lvbiBvbi4KT25lIG9mIHRoZSByZWFzb25zIGZvciB1c2luZyBvcGFxdWUgdG9rZW5zIHJh dGhlciB0aGFuIEpXVCBpcyB0byBwcmV2ZW50IGxlYWthZ2Ugb2YgdGhhdCBpbmZvLgoKTWFraW5n IGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGEgTVVTVCBpZiBh ZGRpdGlvbmFsIGF0dHJpYnV0ZXMgYXJlIHByZXNlbnQgaXMgT0ssIEkgbWlnaHQgZXZlbiBiZSBp bmNsaW5lZCB0byBzYXkgdGhhdCBhdXRoZW50aWNhdGlvbiBvZiBzb21lIHNvcnQgaXMgYWx3YXlz IHJlcXVpcmVkLCBidXQgdGhhdCBtaWdodCBiZSBnb2luZyBhIGJpdCBmYXIgZm9yIHNvbWUgdXNl IGNhc2VzLgoKV2UgaGF2ZSBhIGxvdCBvZiBwcm9wcmlldGFyeSB3YXlzIHRvIGRvIHRoaXMgZnJv bSBJQk0sIExheWVyIDcsIFBpbmcgZXRjLiBJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGNvdWxkIHN0 YW5kYXJkaXplIGl0LiBQcmVjbHVkaW5nIG90aGVyIGF0dHJpYnV0ZXMgd291bGQgbm90IGJlIGhl bHBmdWwgZm9yIGFkb3B0aW9uLgoKCk9uZSBpc3N1ZSB0aGF0IHdlIGhhdmVu4oCZdCBhZGRyZXNz ZWQgaW4gdGhpcyBzcGVjIGlzIHdoYXQgaGFwcGVucyBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgQVMg Zm9yIHRoZSBSUyBhbmQgaG93IGl0IHdvdWxkIGRlY2lkZSB3aGF0IGludHJvc3BlY3Rpb24gZW5k cG9pbnQgdG8gdXNlLgpQZXJoYXBzIHRoYXQgbmVlZHMgdG8gYmUgYSBleHRlbnNpb24sIGxlYXZp bmcgdGhpcyBmb3IgdGhlIHNpbXBsZSBjYXNlLgoKSG93ZXZlciBoYXZpbmcgbW9yZSB0aGFuIG9u IGUgQVMgcGVyIFJTIGlzIG5vdCBhcyB1bnVzdWFsIGFzIGl0IG9uY2Ugd2FzIGluIGxhcmdlciBl bnZpcm9ubWVudHMuCgpKb2huIEIuCgoKT24gRGVjIDIsIDIwMTQsIGF0IDQ6NTYgUE0sIFJpY2hl ciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJlLm9yZz4gd3JvdGU6CgpBZ3JlZWQsIHdoaWNoIGlz IHdoeSB3ZSd2ZSBnb3Qgc3BhY2UgZm9yIHRoZSAic3ViIiBhbmQgInVzZXJfaWQiIGZpZWxkcyBi dXQgbm90IGFueXRoaW5nIGVsc2UgYWJvdXQgdGhlIHVzZXIsIGFuZCB3ZSd2ZSBnb3QgYSBwcml2 YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZm9yIGRlYWxpbmcgd2l0aCB0aGF0LiBJZiB5b3Ug Y2FuIGhlbHAgbWFrZSB0aGUgd29yZGluZyBvbiB0aGF0IHNlY3Rpb24gc3Ryb25nZXIsIEknZCBh cHByZWNpYXRlIGl0LgoKIC0tIEp1c3RpbgoKT24gRGVjIDIsIDIwMTQsIGF0IDI6MjUgUE0sIEJp bGwgTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby5jb20+IHdyb3RlOgoKSWYgaW50cm9zcGVjdGlv biByZXR1cm5zIGFueSBvdGhlciB1c2VyIGRhdGEgYmV5b25kIHdoYXQgaXMgc3RyaWN0bHkgcmVx dWlyZWQgdG8gdmFsaWRhdGUgdGhlIHRva2VuIGJhc2VkIHNvbGVseSBvbiBwb3NzZXNzaW9uIG9m IHRoZSBwdWJsaWMgcGFydCBpdCB3b3VsZCBiZSBhIG1pc3Rha2UuCgoKT24gVHVlc2RheSwgRGVj ZW1iZXIgMiwgMjAxNCAxMToxMyBBTSwgIlJpY2hlciwgSnVzdGluIFAuIiA8anJpY2hlckBtaXRy ZS5vcmc+IHdyb3RlOgoKClRoYXQncyBhbGwgZmluZSAtLSBpdCdzIGFsbCBnb2luZyBvdmVyIFRM UyBhbnl3YXkgKFJTLT5BUykganVzdCBsaWtlIHRoZSBvcmlnaW5hbCB0b2tlbiBmZXRjaCBieSB0 aGUgY2xpZW50IChDLT5BUykuIERvZXNuJ3QgbWVhbiB5b3UgbmVlZCBUTFMgKmludG8qIHRoZSBS UyAoQy0+UlMpIHdpdGggYSBnb29kIFBvUCB0b2tlbi4KCkNhbiB5b3UgZXhwbGFpbiBob3cgdGhp cyBpcyByZWxhdGVkIHRvICJhY3Qgb24gYmVoYWxmIG9mIj8gSSBkb24ndCBzZWUgYW55IGNvbm5l Y3Rpb24uCgogLS0gSnVzdGluCgpPbiBEZWMgMiwgMjAxNCwgYXQgMjowOSBQTSwgQmlsbCBNaWxs cyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gd3JvdGU6CgpGZXRjaGluZyB0aGUgcHVibGljIGtl eSBmb3IgYSB0b2tlbiBtaWdodCBiZSBmaW5lLCBidXQgd2hhdCBpZiB0aGUgaW50cm9zcGVjdGlv biBlbmRwb2ludCByZXR1cm5zIHRoZSBzeW1tZXRyaWMga2V5PyBEYXRhIGFib3V0IHRoZSB1c2Vy PyBXaGVyZSBkb2VzIHRoaXMgYmx1ciB0aGUgbGluZSBiZXR3ZWVuIHRoaXMgYW5kICJhY3Qgb24g YmVoYWxmIG9mIj8KCgpPbiBUdWVzZGF5LCBEZWNlbWJlciAyLCAyMDE0IDExOjA1IEFNLCAiUmlj aGVyLCBKdXN0aW4gUC4iIDxqcmljaGVyQG1pdHJlLm9yZz4gd3JvdGU6CgoKVGhlIGNhbGwgdG8g aW50cm9zcGVjdGlvbiBoYXMgYSBUTFMgcmVxdWlyZW1lbnQsIGJ1dCB0aGUgY2FsbCB0byB0aGUg UlMgd291bGRuJ3QgbmVjZXNzYXJpbHkgaGF2ZSB0aGF0IHJlcXVpcmVtZW50LiBUaGUgc2lnbmF0 dXJlIGFuZCB0aGUgdG9rZW4gaWRlbnRpZmllciBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuIFRo ZSBpZGVudGlmaWVyIGRvZXNuJ3QgZG8gYW4gYXR0YWNrZXIgYW55IGdvb2Qgb24gaXRzIG93biB3 aXRob3V0IHRoZSB2ZXJpZmlhYmxlIHNpZ25hdHVyZSB0aGF0J3MgYXNzb2NpYXRlZCB3aXRoIGl0 IGFuZCB0aGUgcmVxdWVzdC4gV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgeW91IGludHJvc3BlY3Qg dGhlIGlkZW50aWZpZXIgYW5kIGdldCBiYWNrIHNvbWV0aGluZyB0aGF0IGxldHMgeW91LCB0aGUg UlMsIGNoZWNrIHRoZSBzaWduYXR1cmUuCgogLS0gSnVzdGluCgpPbiBEZWMgMiwgMjAxNCwgYXQg MTo0MCBQTSwgQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gd3JvdGU6CgoiSG93 ZXZlciwgSSB0aGluayBpdCdzIHZlcnkgY2xlYXIgaG93IFBvUCB0b2tlbnMgd291bGQgd29yay4g Li4uIgoKSSBkb24ndCBrbm93IGlmIHRoYXQncyB0cnVlLiBQT1AgdG9rZW5zIChhcyB5ZXQgdG8g YmUgZnVsbHkgZGVmaW5lZCkgd291bGQgdGhlbiBhbHNvIGhhdmUgYSBUTFMgb3IgdHJhbnNwb3J0 IHNlY3VyaXR5IHJlcXVpcmVtZW50IHVubGVzcyB0aGVyZSBpcyB0b2tlbiBpbnRyb3NwZWN0aW9u IGNsaWVudCBhdXRoIGluIHBsYXkgSSB0aGluay4gT3RoZXJ3aXNlIEkgY2FuIGFzIGFuIGF0dGFj a2VyIHRha2UgdGhhdCB0b2tsZW4gYW5kIGdldCBpbmZvIGFib3V0IGl0IHRoYXQgbWlnaHQgYmUg dXNlZnVsLCBhbmQgSSBkb24ndCB0aGluayB0aGF0J3Mgd2hhdCB3ZSB3YW50LgoKLWJpbGwKCgoK CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0 aCBtYWlsaW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKCgpFdmUgTWFsZXIgaHR0cDovL3d3dy54bWxn cnJsLmNvbS9ibG9nCisxIDQyNSAzNDUgNjc1NiBodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdy cmwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0 aCBtYWlsaW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCk9BdXRoIG1haWxpbmcgbGlzdApPQXV0aEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCgoK ----_com.android.email_1969588829164290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5BaCwgSSB0aGluayBJIGdv dCBteSB0aHJlYWRzIGNyb3NzZWQuIFRoZW4geWVzLCBJIGFncmVlIHdpdGggeW91LCBhbmQgSSdt IGdvaW5nIHRvIGJlIG1ha2luZyBhdXRob3JpemF0aW9uIGEgTVVTVCBpbnN0ZWFkIG9mIGEgU0hP VUxELiBXb3VsZCBsb3ZlIHRvIGhlYXIgZmVlZGJhY2sgZnJvbSBvdGhlciBpbXBsZW1lbnRlcnMg b24gdGhpcyBwb2ludC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LXNpemU6OXB4Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj4t LSBKdXN0aW48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+LyBTZW50IGZyb20gbXkgcGhvbmUgLzwvZGl2Pjwv ZGl2PjxkaXY+PC9kaXY+PGRpdj48L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3Nh Z2UgLS0tLS0tLS08YnI+RnJvbTogUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZn dDsgPGJyPkRhdGU6MTIvMDIvMjAxNCAgODoyNSBQTSAgKEdNVC0wNTowMCkgPGJyPlRvOiBKdXN0 aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7IDxicj5DYzogb2F1dGhAaWV0Zi5vcmcg PGJyPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWlu dHJvc3BlY3Rpb24tMDEgPGJyPjxicj5JIHdhcyBhc2tpbmcgaW4gdGhlIGNvbnRleHQgb2YgdGhl IHRocmVhZCB3aGVyZSB0aGUgY29tbWVudCB3YXMgbWFkZSB0aGF0IHlvdSBvbmx5IG5lZWQgdG8g YXV0aGVudGljYXRlIGlmIG1vcmUgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQuPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5UaGlzIGRpZG7igJl0IG1ha2Ugc2Vu c2UgdG8gbWUuIEJlY2F1c2UgeW91IHdvdWxkIG5ldmVyIG1ha2UgdGhlIGNhbGwgdG8gcmUtY29u ZmlybSAocG9pbnRsZXNzKS4gRXZlbiBhIGNhbGxlciByZS1jb25maXJtaW5nIGlzIGFjdHVhbGx5 IGNoZWNraW5nIGZvciBtb3JlIGluZm9ybWF0aW9uIC0gdG8gc2VlIGlmIHRoZSBhc3NlcnRpb24g aGFzIGJlZW4gcmV2b2tlZC48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48 ZGl2IGNsYXNzPSIiPjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPgo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRv OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7 IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9 ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyBi b3JkZXItc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBu b25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1z cGFjaW5nOiAwcHg7IGJvcmRlci1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9u cy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgYm9yZGVyLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7 IGJvcmRlci1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6 IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5QaGlsPC9k aXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5AaW5kZXBl bmRlbnRpZDwvZGl2PjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVu dGlkLmNvbSIgY2xhc3M9IiI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2PjwvZGl2Pjwv c3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNzPSIiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPjwvZGl2Pjwvc3Bhbj48L2Rpdj48L3NwYW4+PC9kaXY+PC9zcGFu PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pgo8L2Rpdj4KPGJyIGNsYXNzPSIiPjxkaXY+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5PbiBEZWMgMiwg MjAxNCwgYXQgNTowNCBQTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0LmVkdSIgY2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PC9kaXY+ PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2IGNsYXNzPSIiPgogIAog ICAgCiAgCiAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0iIj4K ICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+Tm90aGluZyBzYXlzIHlvdSBuZWVkIHRv IHBhY2sgdGhlIHNhbWUKICAgICAgaW5mb3JtYXRpb24gaW5zaWRlIHRoZSBKV1QgdGhhdCB5b3Ug cmV0dXJuIGZyb20gaW50cm9zcGVjdGlvbi4gSW4KICAgICAgb3VyIHNwZWNpZmljIGNhc2UsIHdl IGRvbid0IHB1dCBzY29wZXMgb3IgY2xpZW50IElEcyBpbnNpZGUgdGhlCiAgICAgIEpXVCwganVz dCBiYXNpYyBzaWduYXR1cmUvaWRlbnRpZmllciB0eXBlIHN0dWZmLCBzbyB5b3UgbmVlZCB0bwog ICAgICBjYWxsIGludHJvc3BlY3Rpb24gdG8gZ2V0IGJhY2sgdGhpcyBvdGhlciBpbmZvcm1hdGlv bi4gQnV0IHRoZQogICAgICBpbmZvcm1hdGlvbiBpbnNpZGUgdGhlIEpXVCBpbmNsdWRlcyBhbiAi aXNzIiBjbGFpbSB3aGljaCB0aGUKICAgICAgY2xpZW50IGNhbiB1c2UgdG8gZmlndXJlIG91dCAq d2hpY2gqIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgdG8KICAgICAgY2FsbC48YnIgY2xhc3M9IiI+ CiAgICAgIDxiciBjbGFzcz0iIj4KICAgICAgVGhpcyBpcyBqdXN0IG9uZSBvZiBtYW55IGRpZmZl cmVudCB3YXlzIHlvdSBjb3VsZCBoYW5kbGUgbXVsdGlwbGUKICAgICAgQVMgYXQgYSBzaW5nbGUg cmVzb3VyY2UsIGFuZCBzbyBpdCdzIGRlZmluaXRlbHkgb3J0aG9nb25hbCB0byB0aGUKICAgICAg YmFzaWMgaW50cm9zcGVjdGlvbiBjb25jZXB0LjxiciBjbGFzcz0iIj4KICAgICAgPGJyIGNsYXNz PSIiPgogICAgICAmbmJzcDstLSBKdXN0aW48YnIgY2xhc3M9IiI+CiAgICAgIDxiciBjbGFzcz0i Ij4KICAgICAgT24gMTIvMi8yMDE0IDY6MzggUE0sIFBoaWwgSHVudCB3cm90ZTo8YnIgY2xhc3M9 IiI+CiAgICA8L2Rpdj4KICAgIDxibG9ja3F1b3RlIGNpdGU9Im1pZDpEMDI2NDhDNS02M0QzLTQ3 QjUtODk5QS1BRUY0MjEyMjlGQzFAb3JhY2xlLmNvbSIgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+CiAg ICAgIAogICAgICA8ZGl2IGNsYXNzPSIiPkkgYW0gY29uZnVzZWQuIFdoeSB3b3VsZCB5b3UgY2Fs bCB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludAogICAgICAgIGlmIHlvdSB3ZXJlIG5vdCBleHBl Y3RpbmcgbmV3IGluZm9ybWF0aW9uIHRvIGJlIGRpc2Nsb3NlZD88YnIgY2xhc3M9IiI+CiAgICAg ICAgPGJyIGNsYXNzPSIiPgogICAgICAgIFBoaWw8L2Rpdj4KICAgICAgPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+CiAgICAgICAgT24gRGVjIDIsIDIwMTQsIGF0IDE0OjI2LCBSaWNoZXIsIEp1 c3RpbiBQLiAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86anJpY2hl ckBtaXRyZS5vcmciIGNsYXNzPSIiPmpyaWNoZXJAbWl0cmUub3JnPC9hPiZndDsKICAgICAgICB3 cm90ZTo8YnIgY2xhc3M9IiI+CiAgICAgICAgPGJyIGNsYXNzPSIiPgogICAgICA8L2Rpdj4KICAg ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+CiAgICAgICAgPGRpdiBjbGFzcz0i Ij4KICAgICAgICAgIEkgYWdyZWUgdGhhdCB0aGVyZSdzIHNvbWUgdXNlIGluIHRoaXMgKGFuZCBp biBmYWN0IEkndmUKICAgICAgICAgIGRlcGxveWVkIGEgdmVyc2lvbiB0aGF0IHVzZXMgYSBzaWdu ZWQgSldUIHRvIGluZGljYXRlIGl0cwogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIpLCBi dXQgaXQgc2hvdWxkIHJlbWFpbiBvdXRzaWRlIHRoZSBzY29wZQogICAgICAgICAgb2YgdGhpcyBz cGVjLiBJdCdzIGEgc2VydmljZSBkaXNjb3ZlcnkgcHJvYmxlbSwgaXQncwogICAgICAgICAgb3J0 aG9nb25hbC4mbmJzcDsKICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgogICAg ICAgICAgPC9kaXY+CiAgICAgICAgICA8ZGl2IGNsYXNzPSIiPiZuYnNwOy0tIEp1c3RpbjwvZGl2 PgogICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CiAgICAgICAgICA8L2Rpdj4K ICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgogICAgICAgICAgICA8ZGl2IGNs YXNzPSIiPgogICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+T24gRGVjIDIsIDIwMTQsIGF0IDU6 MTMgUE0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIGNsYXNzPSIiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZn dDsKICAgICAgICAgICAgICAgIHdyb3RlOjwvZGl2PgogICAgICAgICAgICAgIDxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+CiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICA8ZGl2IGRpcj0iYXV0byIgY2xhc3M9 IiI+CiAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+WWVzLCAmbmJzcDtidXQgdW5sZXNz IHRoZXJlIGlzIHNvbWV0aGluZyBuZXcgdGhlCiAgICAgICAgICAgICAgICAgICAgaW50cm9zcGVj dGlvbiBlbmRwb2ludCBpbiBVTUEgaXMgdGllZCB0byB0aGUKICAgICAgICAgICAgICAgICAgICBy ZXNvdXJjZS4gJm5ic3A7Jm5ic3A7PC9kaXY+CiAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAg ICAgPGRpdiBjbGFzcz0iIj5JbiBzb21lIGNhc2VzIGhhdmluZyB0aGUgdG9rZW4gaW5kaWNhdGUg dGhlCiAgICAgICAgICAgICAgICAgICAgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBtYXkgYmUgdXNl ZnVsLiZuYnNwOzwvZGl2PgogICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4KICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgIDxkaXYgY2xh c3M9IiI+Sm9obiBCLiZuYnNwOzxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICA8YnIg Y2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgU2VudCBmcm9tIG15IGlQaG9uZTwvZGl2Pgog ICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KICAgICAgICAgICAg ICAgICAgICBPbiBEZWMgMiwgMjAxNCwgYXQgMTA6MDIgUE0sIEV2ZSBNYWxlciAmbHQ7PGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZXZlQHhtbGdycmwuY29tIiBjbGFzcz0i Ij5ldmVAeG1sZ3JybC5jb208L2E+Jmd0OwogICAgICAgICAgICAgICAgICAgIHdyb3RlOjxiciBj bGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAg ICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPkZXSVcsIFVNQSBnb2VzIGFo ZWFkIGFuZCBzdGFuZGFyZGl6ZXMKICAgICAgICAgICAgICAgICAgICAgIGEgZ29vZCBkZWFsIGFi b3V0IHRoZSB0cnVzdCBlc3RhYmxpc2htZW50IGJldHdlZW4KICAgICAgICAgICAgICAgICAgICAg IHRoZSBSUyBhbmQgdGhlIEFTLCBhbmQgKG9mIGNvdXJzZSkgcHJvZmlsZXMgYW5kCiAgICAgICAg ICAgICAgICAgICAgICB3cmFwcyB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiBzcGVjIGFzIHBhcnQg b2YgdGhlCiAgICAgICAgICAgICAgICAgICAgICByZXN1bHRpbmcg4oCcYXV0aG9yaXphdGlvbiBB UEnigJ0gdGhhdCB0aGUgQVMgcHJlc2VudHMKICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBS Uy4gQSBiaWcgcGFydCBvZiB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcwogICAgICAgICAgICAgICAg ICAgICAgaXMgdG8gc3VwcG9ydCBhbiBuOm4gcmVsYXRpb25zaGlwIGJldHdlZW4gQVMgYW5kCiAg ICAgICAgICAgICAgICAgICAgICBSUyBlbnRpdGllcy48L2Rpdj4KICAgICAgICAgICAgICAgICAg ICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4K ICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkVWZTwvZGl2PgogICAgICAgICAg ICAgICAgICAgIDxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIi PgogICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ CiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+T24gMiBEZWMgMjAxNCwgYXQg MTI6MTQgUE0sIEpvaG4KICAgICAgICAgICAgICAgICAgICAgICAgICBCcmFkbGV5ICZsdDs8YSBt b3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgY2xh c3M9IiI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPgogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIi PgogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hbnkg b2YgdGhlIHByb3ByaWV0YXJ5IGludHJvc3BlY3Rpb24KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHByb3RvY29scyBpbiB1c2UgcmV0dXJuIHNjb3BlLCByb2xlIG9yIG90aGVyCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtZXRhIGRhdGEgZm9yIHRoZSBSUyB0byBtYWtlIGl0cyBhY2Nl c3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvbGljeSBkZWNpc2lvbiBvbi4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+T25lIG9mIHRoZSByZWFzb25zIGZv ciB1c2luZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGFxdWUgdG9rZW5zIHJhdGhl ciB0aGFuIEpXVCBpcyB0bwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcmV2ZW50IGxl YWthZ2Ugb2YgdGhhdCBpbmZvLjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp dj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+TWFraW5nIGF1dGhl bnRpY2F0aW9uIHRvIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRyb3NwZWN0 aW9uIGVuZHBvaW50IGEgTVVTVCBpZgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRp dGlvbmFsIGF0dHJpYnV0ZXMgYXJlIHByZXNlbnQgaXMgT0ssCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZuYnNwO0kgbWlnaHQgZXZlbiBiZSBpbmNsaW5lZCB0byBzYXkgdGhhdAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBvZiBzb21lIHNvcnQgaXMg YWx3YXlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcXVpcmVkLCBidXQgdGhhdCBt aWdodCBiZSBnb2luZyBhIGJpdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYXIgZm9y IHNvbWUgdXNlIGNhc2VzLjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+V2UgaGF2ZSBhIGxvdCBv ZiBwcm9wcmlldGFyeQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3YXlzIHRvIGRvIHRo aXMgZnJvbSBJQk0sIExheWVyIDcsIFBpbmcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZXRjLiAmbmJzcDtJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGNvdWxkCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0YW5kYXJkaXplIGl0LiAmbmJzcDsgUHJlY2x1ZGluZyBvdGhlcgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhdHRyaWJ1dGVzIHdvdWxkIG5vdCBiZSBoZWxwZnVs IGZvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZG9wdGlvbi48L2Rpdj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj5PbmUgaXNzdWUg dGhhdCB3ZSBoYXZlbuKAmXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzc2Vk IGluIHRoaXMgc3BlYyBpcyB3aGF0IGhhcHBlbnMgaWYKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlcmUgYXJlIG11bHRpcGxlIEFTIGZvciB0aGUgUlMgYW5kIGhvdwogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpdCB3b3VsZCBkZWNpZGUgd2hhdCBpbnRyb3NwZWN0aW9uCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVuZHBvaW50IHRvIHVzZS48L2Rpdj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+UGVyaGFwcyB0aGF0IG5lZWRzIHRv IGJlIGEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9uLCBsZWF2aW5nIHRo aXMgZm9yIHRoZSBzaW1wbGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZS48L2Rp dj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIgaGF2aW5nIG1vcmUgdGhhbiBvbiBlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFTIHBlciBSUyBpcyBub3QgYXMgdW51c3VhbCBhcyBp dCBvbmNlIHdhcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiBsYXJnZXIgZW52aXJv bm1lbnRzLjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+Sm9obiBCLjwvZGl2PgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp diBjbGFzcz0iIj5PbiBEZWMgMiwgMjAxNCwgYXQgNDo1NgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQTSwgUmljaGVyLCBKdXN0aW4gUC4gJmx0OzxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiBjbGFzcz0iIj5qcmljaGVy QG1pdHJlLm9yZzwvYT4mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdy b3RlOjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC1saW5lLWJyZWFrOgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWdyZWVkLCB3aGljaCBpcyB3aHkgd2Un dmUgZ290CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BhY2UgZm9yIHRo ZSAic3ViIiBhbmQgInVzZXJfaWQiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZmllbGRzIGJ1dCBub3QgYW55dGhpbmcgZWxzZSBhYm91dAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRoZSB1c2VyLCBhbmQgd2UndmUgZ290IGEgcHJpdmFjeQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g Zm9yIGRlYWxpbmcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIHRo YXQuIElmIHlvdSBjYW4gaGVscCBtYWtlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlIHdvcmRpbmcgb24gdGhhdCBzZWN0aW9uCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3Ryb25nZXIsIEknZCBhcHByZWNpYXRlIGl0LgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+Jm5ic3A7LS0gSnVzdGluPC9kaXY+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNs YXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNs YXNzPSIiPk9uIERlYyAyLCAyMDE0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGF0IDI6MjUgUE0sIEJpbGwgTWlsbHMgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSIgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20iIGNsYXNzPSIiPndtaWxs c185MjEwNUB5YWhvby5jb208L2E+Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHdyb3RlOjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmdiKDI1NSwgMjU1LCAyNTUpOwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIZWx2ZXRpY2FOZXVlLCAnSGVsdmV0aWNhCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXVlJywgSGVsdmV0 aWNhLCBBcmlhbCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICdMdWNpZGEgR3JhbmRlJywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDEycHg7IiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiIGlkPSJ5dWlfM18xNl8wXzFf MTQxNzQ3OTkzMzMxOV8xMzgxNzAiIGNsYXNzPSIiPjxzcGFuIGlkPSJ5dWlfM18xNl8wXzFfMTQx NzQ3OTkzMzMxOV8xMzgxNjkiIGNsYXNzPSIiPklmCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaW50cm9zcGVjdGlvbiByZXR1cm5zCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW55IG90aGVyIHVzZXIgZGF0 YQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJleW9u ZCB3aGF0IGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3RyaWN0bHkgcmVxdWlyZWQgdG8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB2YWxpZGF0ZSB0aGUgdG9rZW4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiYXNlZCBzb2xlbHkgb24KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3NzZXNzaW9uIG9mIHRoZQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHB1YmxpYyBw YXJ0IGl0IHdvdWxkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYmUgYSBtaXN0YWtlLjwvc3Bhbj48L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9InF0ZFNlcGFyYXRlQlIiPjxiciBjbGFz cz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJy IGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IGNsYXNzPSJ5YWhvb19xdW90ZWQiIHN0eWxlPSJkaXNwbGF5OiBibG9jazsiPgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LWZh bWlseToKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBI ZWx2ZXRpY2FOZXVlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEhlbHZldGljYSBOZXVlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEhlbHZldGljYSwgQXJpYWwsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTHVjaWRhIEdyYW5kZSwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlmOyBmb250LXNpemU6 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTJweDsi IGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSGVsdmV0aWNhTmV1ZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhlbHZldGljYSBOZXVlLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGVsdmV0aWNhLCBB cmlhbCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEx1Y2lkYSBHcmFuZGUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxNnB4OyIgY2xhc3M9IiI+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+T24KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUdWVzZGF5LAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERl Y2VtYmVyIDIsIDIwMTQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAxMToxMyBBTSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAiUmljaGVyLCBKdXN0aW4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQLiIgJmx0OzxhIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnIiBjbGFzcz0iIj5q cmljaGVyQG1pdHJlLm9yZzwvYT4mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PGJyIGNsYXNzPSIiPgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2ZvbnQ+PC9kaXY+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xh c3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8ZGl2IGNsYXNzPSJ5X21zZ19jb250YWluZXIiPgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSJ5aXYwMzgyMjU1 MjE1IiBjbGFzcz0iIj5UaGF0J3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhbGwgZmluZSAtLSBpdCdzCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsIGdvaW5nIG92ZXIKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUTFMgYW55 d2F5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKFJTLSZndDtBUykganVzdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGxpa2UgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3JpZ2luYWwgdG9rZW4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmZXRjaCBieSB0aGUKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGll bnQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoQy0mZ3Q7QVMpLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIERvZXNuJ3QgbWVhbiB5b3UKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZWVkIFRMUyAqaW50byoKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgUlMKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoQy0mZ3Q7 UlMpIHdpdGgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhIGdvb2QgUG9QCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdG9rZW4uJm5ic3A7CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiIg Y2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+Q2FuCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3UgZXhwbGFpbgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaG93IHRo aXMgaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlbGF0ZWQgdG8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICJhY3Qgb24gYmVoYWxmCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiI/IEkgZG9uJ3QKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlZSBhbnkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbm5lY3Rpb24uPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiIgY2xlYXI9Im5vbmUi PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXYgY2xhc3M9IiI+Jm5ic3A7LS0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1c3RpbjwvZGl2PgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9Inlp djAzODIyNTUyMTV5cXQzMTEwODAxODU5IiBpZD0ieWl2MDM4MjI1NTIxNXlxdDI3NDc1Ij48YnIg Y2xhc3M9IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+T24K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IERlYyAyLCAyMDE0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXQgMjowOSBQTSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJpbGwgTWlsbHMKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDs8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIHJlbD0ibm9mb2xsb3ciIHNoYXBlPSJyZWN0IiB5bWFpbHRvPSJtYWlsdG86 d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzp3bWls bHNfOTIxMDVAeWFob28uY29tIiBjbGFzcz0iIj53bWlsbHNfOTIxMDVAeWFob28uY29tPC9hPiZn dDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHdyb3RlOjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSJ5aXYwMzgyMjU1MjE1QXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyNTUsCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyNTUpO2Zv bnQtZmFtaWx5OkhlbHZldGljYU5ldWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAnSGVsdmV0aWNhCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXVlJywKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhlbHZldGljYSwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFyaWFsLCAnTHVjaWRhCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHcmFuZGUnLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Fucy1zZXJpZjtmb250LXNpemU6MTJweDsiIGNs YXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGRpdiBkaXI9Imx0ciIgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQx NzQ3OTkzMzMxOV8xMTYyODAiIGNsYXNzPSIiPjxzcGFuIGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNf MTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2MjgzIiBjbGFzcz0iIj5GZXRjaGluZwogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHB1Ymxp YyBrZXkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGZvciBhIHRva2VuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtaWdodCBiZSBmaW5lLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnV0IHdoYXQgaWYKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50 cm9zcGVjdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZW5kcG9pbnQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJldHVybnMgdGhlCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzeW1tZXRyaWMga2V5PwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm5ic3A7 RGF0YSBhYm91dAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlIHVzZXI/CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmbmJzcDtXaGVyZSBkb2VzCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIGJsdXIgdGhlCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs aW5lIGJldHdlZW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoaXMgYW5kICJhY3QKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9uIGJlaGFsZiBvZiI/PC9zcGFuPjwvZGl2Pgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpdiBjbGFzcz0ieWl2MDM4MjI1NTIxNXF0ZFNlcGFyYXRlQlIiIGlkPSJ5aXYwMzgyMjU1MjE1 eXVpXzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2Mjc5Ij4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIiBjbGVhcj0i bm9uZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8YnIgY2xhc3M9IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJ5 aXYwMzgyMjU1MjE1eWFob29fcXVvdGVkIiBpZD0ieWl2MDM4MjI1NTIxNXl1aV8zXzE2XzBfMV8x NDE3NDc5OTMzMzE5XzExNjI1MCIgc3R5bGU9ImRpc3BsYXk6CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBibG9jazsiPgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBpZD0i eWl2MDM4MjI1NTIxNXl1aV8zXzE2XzBfMV8xNDE3NDc5OTMzMzE5XzExNjI0OSIgc3R5bGU9ImZv bnQtZmFtaWx5OkhlbHZldGljYU5ldWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBIZWx2ZXRpY2EKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldWUsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIZWx2ZXRpY2EsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB cmlhbCwgTHVjaWRhCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBHcmFuZGUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB4OyIgY2xhc3M9 IiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2IGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2 MjQ4IiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhTmV1ZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhlbHZldGljYQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV1ZSwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEhlbHZldGljYSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEFyaWFsLCBMdWNpZGEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyYW5kZSwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNhbnMtc2VyaWY7Zm9udC1zaXpl OjE2cHg7IiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiIGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNf MTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2Mjc4IiBjbGFzcz0iIj48Zm9udCBpZD0ieWl2MDM4MjI1 NTIxNXl1aV8zXzE2XzBfMV8xNDE3NDc5OTMzMzE5XzExNjI3NyIgY2xhc3M9IiIgZmFjZT0iQXJp YWwiIHNpemU9IjIiPk9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBUdWVzZGF5LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTQgMTE6MDUgQU0sCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi UmljaGVyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSnVzdGluIFAuIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgcmVsPSJu b2ZvbGxvdyIgc2hhcGU9InJlY3QiIHltYWlsdG89Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgY2xhc3M9IiI+ anJpY2hlckBtaXRyZS5vcmc8L2E+Jmd0OwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxiciBjbGFzcz0iIiBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L2ZvbnQ+PC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNz PSIiIGNsZWFyPSJub25lIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9InlpdjAzODIyNTUyMTV5X21zZ19jb250YWlu ZXIiIGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2MjQ3Ij4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYgaWQ9InlpdjAzODIyNTUyMTUiIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBpZD0ieWl2MDM4MjI1NTIx NXl1aV8zXzE2XzBfMV8xNDE3NDc5OTMzMzE5XzExNjI0NiIgY2xhc3M9IiI+VGhlCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYWxsIHRv CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbnRyb3NwZWN0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBoYXMgYSBUTFMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcXVpcmVtZW50LAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnV0IHRoZSBjYWxsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 byB0aGUgUlMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdvdWxkbid0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBuZWNlc3NhcmlseQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSB0aGF0CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlbWVudC4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRoZSBzaWduYXR1cmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFuZCB0aGUgdG9rZW4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlkZW50aWZpZXIgYXJlCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0d28gZGlmZmVy ZW50CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0aGluZ3MuIFRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaWRlbnRpZmllcgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9lc24ndCBkbyBhbgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXR0YWNrZXIgYW55 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBnb29kIG9uIGl0cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgb3duIHdpdGhvdXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSB2ZXJpZmlhYmxlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWduYXR1cmUKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo YXQncwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYXNzb2NpYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2l0aCBpdCBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSByZXF1ZXN0LgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hhdCBJJ20KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNh eWluZyBpcyB0aGF0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB5b3UgaW50cm9zcGVjdAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGlkZW50aWZpZXIKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBnZXQgYmFj awogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc29tZXRoaW5nIHRoYXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGxldHMgeW91LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJTLCBjaGVjayB0aGUKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25hdHVy ZS4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQxNzQ3OTkzMzMxOV8xMTYy NzYiIGNsYXNzPSIiPjxiciBjbGFzcz0iIiBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9 InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQxNzQ3OTkzMzMxOV8xMTYyNzUiIGNsYXNzPSIi PiZuYnNwOy0tCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKdXN0aW48L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8w XzFfMTQxNzQ3OTkzMzMxOV8xMTYyNDUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIiBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8ZGl2IGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfMTE2 MjQ0IiBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9InlpdjAzODIyNTUyMTV5cXQ3NDAyNDM2OTg5IiBp ZD0ieWl2MDM4MjI1NTIxNXlxdDIxNTU2Ij4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18x Nl8wXzFfMTQxNzQ3OTkzMzMxOV8xMTYyNzQiIGNsYXNzPSIiPk9uCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWMgMiwgMjAxNCwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0 IDE6NDAgUE0sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCaWxsIE1pbGxzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiByZWw9 Im5vZm9sbG93IiBzaGFwZT0icmVjdCIgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQx NzQ3OTkzMzMxOV8xMTYyNzMiIHltYWlsdG89Im1haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29t IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20iIGNs YXNzPSIiPndtaWxsc185MjEwNUB5YWhvby5jb208L2E+Jmd0OwoKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjwvZGl2PgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJy IGNsYXNzPSJ5aXYwMzgyMjU1MjE1QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSIgY2xlYXI9Im5v bmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGJsb2NrcXVvdGUgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQxNzQ3OTkz MzMxOV8xMTYyNDMiIHR5cGU9ImNpdGUiIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBpZD0ieWl2MDM4MjI1NTIx NXl1aV8zXzE2XzBfMV8xNDE3NDc5OTMzMzE5XzExNjI0MiIgc3R5bGU9ImJhY2tncm91bmQtY29s b3I6cmdiKDI1NSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDI1NSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDI1NSk7Zm9udC1mYW1pbHk6SGVsdmV0aWNhTmV1ZSwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdIZWx2 ZXRpY2EKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE5ldWUnLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSGVsdmV0aWNhLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJpYWwsICdMdWNpZGEKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyYW5kZScsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxMnB4OyIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSJ5aXYwMzgyMjU1MjE1 eXVpXzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfODI0ODEiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PiI8L3NwYW4+PHNwYW4gY2xhc3M9InlpdjAzODIyNTUyMTUiIGlkPSJ5aXYwMzgyMjU1MjE1eXVp XzNfMTZfMF8xXzE0MTc0Nzk5MzMzMTlfODM2MDEiIHN0eWxlPSJmb250LXNpemU6MTUuNTU1NTU2 Mjk3MzAyMnB4OyI+SG93ZXZlciwgSSB0aGluayBpdCdzIHZlcnkgY2xlYXIKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhvdyBQb1AgdG9r ZW5zCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB3b3VsZCB3b3JrLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uIjwvc3Bhbj48L2Rpdj4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9InlpdjAzODIy NTUyMTVxdGRTZXBhcmF0ZUJSIiBpZD0ieWl2MDM4MjI1NTIxNXl1aV8zXzE2XzBfMV8xNDE3NDc5 OTMzMzE5XzgyNDgwIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIiBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg Y2xhc3M9InlpdjAzODIyNTUyMTVxdGRTZXBhcmF0ZUJSIiBkaXI9Imx0ciIgaWQ9InlpdjAzODIy NTUyMTV5dWlfM18xNl8wXzFfMTQxNzQ3OTkzMzMxOV84MjQ4MCI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIGRvbid0IGtub3cKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlm IHRoYXQncwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdHJ1ZS4gJm5ic3A7UE9QCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0b2tlbnMgKGFzIHlldAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gYmUgZnVsbHkKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRl ZmluZWQpIHdvdWxkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0aGVuIGFsc28gaGF2ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYSBUTFMgb3IKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRyYW5zcG9ydAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VjdXJp dHkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHJlcXVpcmVtZW50CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1bmxlc3MgdGhlcmUKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIHRva2VuCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRyb3NwZWN0aW9uCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj bGllbnQgYXV0aCBpbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGxheSBJIHRoaW5rLgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm5ic3A7T3RoZXJ3aXNlIEkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhbiBhcyBh bgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYXR0YWNrZXIgdGFrZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhhdCB0b2tsZW4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBnZXQgaW5mbwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJvdXQgaXQgdGhh dAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbWlnaHQgYmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHVzZWZ1bCwgYW5kIEkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbid0IHRoaW5rCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0J3Mgd2hhdCB3ZQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg d2FudC48L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXYgY2xhc3M9InlpdjAzODIyNTUyMTVxdGRTZXBhcmF0ZUJSIiBkaXI9 Imx0ciIgaWQ9InlpdjAzODIyNTUyMTV5dWlfM18xNl8wXzFfMTQxNzQ3OTkzMzMxOV84MjQ4MCI+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8YnIgY2xhc3M9IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJ5aXYwMzgy MjU1MjE1cXRkU2VwYXJhdGVCUiIgZGlyPSJsdHIiIGlkPSJ5aXYwMzgyMjU1MjE1eXVpXzNfMTZf MF8xXzE0MTc0Nzk5MzMzMTlfODI0ODAiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLWJpbGw8L2Rpdj4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9InlpdjAz ODIyNTUyMTVxdGRTZXBhcmF0ZUJSIiBpZD0ieWl2MDM4MjI1NTIxNXl1aV8zXzE2XzBfMV8xNDE3 NDc5OTMzMzE5XzgyNDgwIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIiBjbGVhcj0ibm9uZSI+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXYgY2xhc3M9InlpdjAzODIyNTUyMTVxdGRTZXBhcmF0ZUJSIiBpZD0ieWl2MDM4MjI1NTIxNXl1 aV8zXzE2XzBfMV8xNDE3NDc5OTMzMzE5XzgyNDgwIj4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIiBjbGVhcj0ibm9u ZSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8YnIgY2xhc3M9IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2tx dW90ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9 IiIgY2xlYXI9Im5vbmUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvYmxvY2txdW90ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiIGNsZWFyPSJub25lIj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9k aXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvYmxvY2txdW90ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIi PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAg ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAgICAgICAgICAg ICBPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4KICAgICAgICAgICAgICAg ICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPgogICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+ CiAgICAgICAgICAgICAgICAgICAgPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xh c3M9IiI+CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXN0eWxlOgogICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDoKICAgICAgICAgICAgICAgICAgICAgICAgbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDoKICAgICAgICAgICAgICAg ICAgICAgICAgbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87CiAg ICAgICAgICAgICAgICAgICAgICAgIHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOwogICAgICAgICAgICAgICAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7IHdvcmQtc3BhY2luZzoKICAgICAgICAgICAgICAgICAgICAgICAgMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDoKICAgICAgICAgICAgICAgICAgICAgICAg YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOwogICAgICAgICAgICAgICAgICAg ICAgICAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+CiAg ICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9udC1mYW1pbHk6CiAgICAgICAgICAgICAg ICAgICAgICAgICAgSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDoK ICAgICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOgogICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogMjsKICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LWFs aWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgYm9yZGVyLXNw YWNpbmc6CiAgICAgICAgICAgICAgICAgICAgICAgICAgMHB4OyAtd2Via2l0LXRleHQtZGVjb3Jh dGlvbnMtaW4tZWZmZWN0OiBub25lOwogICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz dHlsZT0iZm9udC1mYW1pbHk6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb3VyaWVyOyAi PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBFdmUgTWFsZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0i aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nIiBjbGFzcz0iIj5odHRwOi8vd3d3LnhtbGdycmwu Y29tL2Jsb2c8L2E+PGJyIGNsYXNzPSIiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgKzEg NDI1IDM0NSA2NzU2ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7PGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmwiIGNsYXNz PSIiPmh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybDwvYT48L3NwYW4+PC9zcGFuPjwvZGl2 PgogICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgIDxiciBjbGFz cz0iIj4KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICAgICAgPC9k aXY+CiAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICA8L2Rpdj4KICAgICAg ICAgICAgPGJyIGNsYXNzPSIiPgogICAgICAgICAgPC9kaXY+CiAgICAgICAgPC9kaXY+CiAgICAg IDwvYmxvY2txdW90ZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+CiAg ICAgICAgPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgY2xhc3M9IiI+CiAgICAgICAgICA8 c3BhbiBjbGFzcz0iIj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIGNsYXNzPSIiPgogICAg ICAgICAgPHNwYW4gY2xhc3M9IiI+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnIg Y2xhc3M9IiI+CiAgICAgICAgICA8c3BhbiBjbGFzcz0iIj48YSBtb3otZG8tbm90LXNlbmQ9InRy dWUiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIGNs YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9z cGFuPjxiciBjbGFzcz0iIj4KICAgICAgICA8L2Rpdj4KICAgICAgPC9ibG9ja3F1b3RlPgogICAg ICA8YnIgY2xhc3M9IiI+CiAgICAgIDxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFk ZXIiPjwvZmllbGRzZXQ+CiAgICAgIDxiciBjbGFzcz0iIj4KICAgICAgPHByZSB3cmFwPSIiIGNs YXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9B dXRoIG1haWxpbmcgbGlzdAo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPgo8YSBjbGFzcz0ibW96 LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPgo8L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIDxiciBjbGFzcz0iIj4KICA8L2Rpdj4K CjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnIgY2xhc3M9IiI+PC9kaXY+PC9ib2R5PjwvaHRt bD4= ----_com.android.email_1969588829164290-- From nobody Wed Dec 3 03:17:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E49A1A0AF7 for ; Wed, 3 Dec 2014 03:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3RdkEsUkZwv for ; Wed, 3 Dec 2014 03:17:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843821A0461 for ; Wed, 3 Dec 2014 03:17:29 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAgzj-1XkpPJ30Y7-00BpVp for ; Wed, 03 Dec 2014 12:17:26 +0100 Message-ID: <547EF145.5030501@gmx.net> Date: Wed, 03 Dec 2014 12:17:25 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HCWbhVFNNUJUourBcf0jPdCo2t0FuB7rN" X-Provags-ID: V03:K0:h77EUFiNgvxci2/6mVs/P/ugaXzm5moUoyBwYS5sCcUnLY80Ej2 Sfkv8WG/XJjD3HVuBhK48QVrx7Zu1izlL0i7uyT0/73joT+1rRwa3PHHynb70avhT9v1tOj sesQLWiRpVU1qw9Iy528m/9rPJ2IjeNl9QMhmJiByer4QWg1EvR3duc4sAGU3iy7mHX6nbG 2T/kn0/zq0vl/bAvb7arw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/w5Sw68T-ZmovK3-IRnQrwOumMxw Subject: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:17:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HCWbhVFNNUJUourBcf0jPdCo2t0FuB7rN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I am trying to figure out how to progress the SPOP document and therefore I read through the discussion about the code challenge, see I wanted to share my view about this topic. As a summary, the mechanism works as follows: C: Compute code_verifier:=3Drand() C: Compute code_challenge:=3Dfunc(code_verifier) (For this discussion, the function func() is SHA-256.) C: Send(Authz Request + code_challenge,S) S: store code_challenge S: Send(Authz Grant,C) C: Send(Access Token Request || code_verifier, S) S: Compute code_challenge':=3Dfunc(code_verifier) S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. The document currently does not say how much entropy the random number has to have. The text only talks about the output size and SHA-256 indeed produces a 256 bit output. Here is the relevant text: " NOTE: code verifier SHOULD have enough entropy to make it impractical to guess the value. It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence. " I suggest to recommend at least 128 bits, which is inline with the recommendations for symmetric ciphers in http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I would also suggest to reference RFC 4086 concerning the creation of random numbers. Furthermore, since you allow other hash functions to be used as well it would be good to give guidance about what the properties of those hash functions should be. You definitely want a cryptographic hash function that provides pre-image resistance, second pre-image resistance, and collision resistance. Given the size of the input and output it is impractical to compute a table that maps code_verifies to code_challenges. This mechanism provides better properties than the "plain" mechanism since it deals with an attacker that can see responses as well as requests (but cannot modify them). It does not provide any protection against a true man-in-the-middle attacker. Ciao Hannes --HCWbhVFNNUJUourBcf0jPdCo2t0FuB7rN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfvFFAAoJEGhJURNOOiAtFxMH/3/kl1/QN6Fq4RuE1WhfuV12 e27gWRBW5AAVXndJfZwdmeNXChv4L+3S3VK40ZOCjdT9+3p3zE0KeyjD1psxo00C SKAA/4sDYkE7iTaNx6qFx3qFD4HW7iG5/2GSjKctm3TvxeVEVP6SkKO1M4PKAPVF h0IqBwH0/cyckK3U9/1tR2LELplgkDzDHFRQ/ijoKx7aa3l7LdjU7x/jtBrs4ndG MvnPWVA0KtYiUEyJxaXYZpWp1SX6vndeIWEBShsv/bYQXL3Ilgc71+7vvIIHsQT8 8IEp6eNrAHqogqiKPInin7OdmOOvV3OBqYW9d9vuDWfWJuEAYvsid+KetJgxvYo= =NeFP -----END PGP SIGNATURE----- --HCWbhVFNNUJUourBcf0jPdCo2t0FuB7rN-- From nobody Wed Dec 3 03:37:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A621A1A48 for ; Wed, 3 Dec 2014 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z58Lw5wqF_Wh for ; Wed, 3 Dec 2014 03:37:18 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D18F1A1A68 for ; Wed, 3 Dec 2014 03:37:18 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so31104073wiw.1 for ; Wed, 03 Dec 2014 03:37:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qAfLqYn0UfhmUFA5zWclhWMkxwe5oWMWRo5+HdYBPd8=; b=g2Z6XAHiCmMWPAAdB+NACBMeqzbh0zmXZ4VWY0QvFqtqfxH0R/rmH1nXNxcuht8wSy bcmPztGBceGYxVXoqZalo1NvjSh9dAA3bFA2dC0qTcuFl/VKyl+ZwhD4gZI+/tif74Ie 9vWoteRSdxTin6cU/yusD9zvH75fijLp8TtdSHfh5j/wBuueg+DoWGzDKmYKuGhGxfyq +5SHvRP0zQ5zTNceqKPLrlPUZTECnLGeJT9hqTXMjuRVHzCHGPWoyAUVyZ2tFxFxENUC cIKPqxWLBgsuz3LNr8i36oKbaSRrVmY6iZJDvVfyCXIyw7Bg58woVpp3T9RE6EF+C8qK CVbA== X-Gm-Message-State: ALoCoQkgnuACve6jwNQZXlEBLGS/KCy2kApmcDLAgacbGLgtBFf290MmOqtR1NbkZDGXdbaQ6OC/ X-Received: by 10.180.20.163 with SMTP id o3mr102540593wie.12.1417606637244; Wed, 03 Dec 2014 03:37:17 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id ud1sm35912826wjc.7.2014.12.03.03.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 03:37:15 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9B240F07-FDAE-4366-BCFA-216F8C745E36"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547EF145.5030501@gmx.net> Date: Wed, 3 Dec 2014 08:37:14 -0300 Message-Id: References: <547EF145.5030501@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QfXgcLfOrKoUm15X3fdGfCgRKe0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:37:20 -0000 --Apple-Mail=_9B240F07-FDAE-4366-BCFA-216F8C745E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Hannes. Other methods such as different hashes need to be added via extension = specs. =20 Are you saying that we should set minimum recommendations for them. It is also possible that those methods might use something other than = hashing. Key agreement might be a possibility. Those properties would all be requirements for selecting a different = hash function. We could add that as a requirement for extensions if = you think that is appropriate. John B. > On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I am trying to figure out how to progress the SPOP document and > therefore I read through the discussion about the code challenge, see >=20 > I wanted to share my view about this topic. >=20 > As a summary, the mechanism works as follows: >=20 > C: Compute code_verifier:=3Drand() > C: Compute code_challenge:=3Dfunc(code_verifier) >=20 > (For this discussion, the function func() is SHA-256.) >=20 > C: Send(Authz Request + code_challenge,S) >=20 > S: store code_challenge > S: Send(Authz Grant,C) >=20 > C: Send(Access Token Request || code_verifier, S) >=20 > S: Compute code_challenge':=3Dfunc(code_verifier) > S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >=20 > The document currently does not say how much entropy the random number > has to have. >=20 > The text only talks about the output size and SHA-256 indeed produces = a > 256 bit output. >=20 > Here is the relevant text: >=20 > " > NOTE: code verifier SHOULD have enough entropy to make it = impractical > to guess the value. It is RECOMMENDED that the output of a suitable > random number generator be used to create a 32-octet sequence. > " >=20 > I suggest to recommend at least 128 bits, which is inline with the > recommendations for symmetric ciphers in > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >=20 > I would also suggest to reference RFC 4086 concerning the creation of > random numbers. >=20 > Furthermore, since you allow other hash functions to be used as well = it > would be good to give guidance about what the properties of those hash > functions should be. You definitely want a cryptographic hash function > that provides pre-image resistance, second pre-image resistance, and > collision resistance. >=20 > Given the size of the input and output it is impractical to compute a > table that maps code_verifies to code_challenges. >=20 > This mechanism provides better properties than the "plain" mechanism > since it deals with an attacker that can see responses as well as > requests (but cannot modify them). It does not provide any protection > against a true man-in-the-middle attacker. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9B240F07-FDAE-4366-BCFA-216F8C745E36 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDMxMTM3MTRaMCMGCSqGSIb3DQEJBDEWBBSN4+gn4KWXiltClOvORwkw +CDvkDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBx+f8hx0vMF9Te50V20DP88edrFfkH0MKwCxmS5BCJ5au9eJWdJArk SdBKgdTNQRKA3a1l71+HCF0L1ZiNhDTOa9fuP/ifr++ii0CrE1uYdgb3fJWSH8KUrTb5B/VMNIwm SFmpH4Pv/sQxMN6awfLzzf6RsuWKAlMaZ8PoEHwa4fs7i/Mw0QiyiiMfXPApUQPoog/u5YHyxlaG Km0xiTegMOvgbNCHjGBdD4oZPvZ/JGfWzDvzy/40KzAxXI/0f51cJ4YAsi+jt0n4S3hzcdMg5MwE rasoWUzYhYCHN1NJPqpWTYXssOqReCsXTbkUI8yUgQxTJ5BUDrCfXN/5p9FiAAAAAAAA --Apple-Mail=_9B240F07-FDAE-4366-BCFA-216F8C745E36-- From nobody Wed Dec 3 03:44:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104FA1A1A74 for ; Wed, 3 Dec 2014 03:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m-Yg5Z4_5-y for ; Wed, 3 Dec 2014 03:44:15 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17241A1A4E for ; Wed, 3 Dec 2014 03:44:14 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id tp5so13436322ieb.40 for ; Wed, 03 Dec 2014 03:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=e495ACgo3Iu1SdCuO/ql9lsOEUR0VHUbLIcXTq8uNtM=; b=jEkUDT1M+qZJadWft1CNaLoiTWwObrwh6F6P8yeOmlXDC4DhPFwqJJV2YxrEdbFlXp 7ZXOQBgvGR7I0++taQr0VGjBzABe2lHjyym/OF0Wswu9Tp9dKzMyx+jj3tNCfK7ztngV 00oMuICAYiCygjImbTkREFB8Y/futkB1NJ41qwEDDrzqMTPg77hBj8GnS3bpzHenozjP 9vQ4sPhNy4yISBVvrM4PjmxGNAzKdf3CJ3EJJzFSPGAOkBHO+MvANfIzcCqRPznEoyzl 2jKFhsGi7LYd7aGXJHLDlrpSTM3HMBgYCu9HA2OKic0l0BVUPj/gKHONQtmW8KsSfbPI ZyCA== X-Received: by 10.107.16.130 with SMTP id 2mr3924328ioq.81.1417607054128; Wed, 03 Dec 2014 03:44:14 -0800 (PST) MIME-Version: 1.0 References: <547EF145.5030501@gmx.net> From: Nat Sakimura Date: Wed, 03 Dec 2014 11:44:13 +0000 Message-ID: To: John Bradley , Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113fbe2ee47dd305094e5c35 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HJLlnp41bhjXpSPxBbm6HHDIHb8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:44:17 -0000 --001a113fbe2ee47dd305094e5c35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes. One question: we are recommending 32 octetes=3D256 bits to fill the sha256 range. Is there a reason for asking for a lesser entropy? On 2014=E5=B9=B412=E6=9C=883=E6=97=A5(=E6=B0=B4) at 20:37 John Bradley wrote: > Thanks Hannes. > > Other methods such as different hashes need to be added via extension > specs. > > Are you saying that we should set minimum recommendations for them. > > It is also possible that those methods might use something other than > hashing. Key agreement might be a possibility. > > Those properties would all be requirements for selecting a different hash > function. We could add that as a requirement for extensions if you thin= k > that is appropriate. > > John B. > > > On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig > wrote: > > > > Hi all, > > > > I am trying to figure out how to progress the SPOP document and > > therefore I read through the discussion about the code challenge, see > > > > I wanted to share my view about this topic. > > > > As a summary, the mechanism works as follows: > > > > C: Compute code_verifier:=3Drand() > > C: Compute code_challenge:=3Dfunc(code_verifier) > > > > (For this discussion, the function func() is SHA-256.) > > > > C: Send(Authz Request + code_challenge,S) > > > > S: store code_challenge > > S: Send(Authz Grant,C) > > > > C: Send(Access Token Request || code_verifier, S) > > > > S: Compute code_challenge':=3Dfunc(code_verifier) > > S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. > > > > The document currently does not say how much entropy the random number > > has to have. > > > > The text only talks about the output size and SHA-256 indeed produces a > > 256 bit output. > > > > Here is the relevant text: > > > > " > > NOTE: code verifier SHOULD have enough entropy to make it impractical > > to guess the value. It is RECOMMENDED that the output of a suitable > > random number generator be used to create a 32-octet sequence. > > " > > > > I suggest to recommend at least 128 bits, which is inline with the > > recommendations for symmetric ciphers in > > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 > > > > I would also suggest to reference RFC 4086 concerning the creation of > > random numbers. > > > > Furthermore, since you allow other hash functions to be used as well it > > would be good to give guidance about what the properties of those hash > > functions should be. You definitely want a cryptographic hash function > > that provides pre-image resistance, second pre-image resistance, and > > collision resistance. > > > > Given the size of the input and output it is impractical to compute a > > table that maps code_verifies to code_challenges. > > > > This mechanism provides better properties than the "plain" mechanism > > since it deals with an attacker that can see responses as well as > > requests (but cannot modify them). It does not provide any protection > > against a true man-in-the-middle attacker. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > 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 > --001a113fbe2ee47dd305094e5c35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes.

One question: we are recommending 32 octetes=3D256 b= its to fill the sha256 range. Is there a reason for asking for a lesser ent= ropy?
On 2014=E5=B9=B412=E6=9C=883=E6=97=A5(= =E6=B0=B4) at 20:37 John Bradley <v= e7jtb@ve7jtb.com> wrote:
Thanks H= annes.

Other methods such as different hashes need to be added via extension specs= .

Are you saying that we should set minimum recommendations for them.

It is also possible that those methods might use something other than hashi= ng.=C2=A0 Key agreement might be a possibility.

Those properties would all be requirements for selecting a different hash f= unction.=C2=A0 =C2=A0We could add that as a requirement for extensions if y= ou think that is appropriate.

John B.

> On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
>
> Hi all,
>
> I am trying to figure out how to progress the SPOP document and
> therefore I read through the discussion about the code challenge, see<= br> >
> I wanted to share my view about this topic.
>
> As a summary, the mechanism works as follows:
>
> C: Compute code_verifier:=3Drand()
> C: Compute code_challenge:=3Dfunc(code_verifier)
>
> (For this discussion, the function func() is SHA-256.)
>
> C: Send(Authz Request + code_challenge,S)
>
> S: store code_challenge
> S: Send(Authz Grant,C)
>
> C: Send(Access Token Request || code_verifier, S)
>
> S: Compute code_challenge':=3Dfunc(code_verifier)
> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS EL= SE FAIL.
>
> The document currently does not say how much entropy the random number=
> has to have.
>
> The text only talks about the output size and SHA-256 indeed produces = a
> 256 bit output.
>
> Here is the relevant text:
>
> "
>=C2=A0 =C2=A0NOTE: code verifier SHOULD have enough entropy to make it = impractical
>=C2=A0 =C2=A0to guess the value.=C2=A0 It is RECOMMENDED that the outpu= t of a suitable
>=C2=A0 =C2=A0random number generator be used to create a 32-octet seque= nce.
> "
>
> I suggest to recommend at least 128 bits, which is inline with the
> recommendations for symmetric ciphers in
> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07
>
> I would also suggest to reference RFC 4086 concerning the creation of<= br> > random numbers.
>
> Furthermore, since you allow other hash functions to be used as well i= t
> would be good to give guidance about what the properties of those hash=
> functions should be. You definitely want a cryptographic hash function=
> that provides pre-image resistance, second pre-image resistance, and > collision resistance.
>
> Given the size of the input and output it is impractical to compute a<= br> > table that maps code_verifies to code_challenges.
>
> This mechanism provides better properties than the "plain" m= echanism
> since it deals with an attacker that can see responses as well as
> requests (but cannot modify them). It does not provide any protection<= br> > against a true man-in-the-middle attacker.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a113fbe2ee47dd305094e5c35-- From nobody Wed Dec 3 03:46:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3411A1A74 for ; Wed, 3 Dec 2014 03:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnowo2eOUCst for ; Wed, 3 Dec 2014 03:46:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BCF1A1A40 for ; Wed, 3 Dec 2014 03:46:54 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MJjvw-1Xv2St2HeW-0019f7; Wed, 03 Dec 2014 12:46:51 +0100 Message-ID: <547EF82A.1050505@gmx.net> Date: Wed, 03 Dec 2014 12:46:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <547EF145.5030501@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DgWdj7kIQFACJcBV0R7JuKfapefQbTn7R" X-Provags-ID: V03:K0:VxRU/pHzkR8ls1PGBJoKT8Q8BmwKLfuHV8zMym8e6yfxJXNH85C nJDklUNKvwFtFz0PkCBP1htvCbQexqekYXPcI0TkoCOQ/xG0USoGylfm7X4XWQJs8nMZFIb t9LfM503O0uC4uMYCfK3+oOsq/uPErtMREiM4Mm6GIbn9zXCoazjYliJUY4uoDPbgNJoDqW TGXT7PcJqqTcVR8MLZbHw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Bs6IshOEPrStCE5m7mP1eK3ZWF4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:46:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DgWdj7kIQFACJcBV0R7JuKfapefQbTn7R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, I believe it makes sense to give recommendations for extensions (if you envision them). Of course, I hope that we do not see a flood of extensions that all use different hash functions. Changing the mechanism to something that provides even stronger security properties would definitely require a new specification and review. Ciao Hannes On 12/03/2014 12:37 PM, John Bradley wrote: > Thanks Hannes. >=20 > Other methods such as different hashes need to be added via extension s= pecs. =20 >=20 > Are you saying that we should set minimum recommendations for them. >=20 > It is also possible that those methods might use something other than h= ashing. Key agreement might be a possibility. >=20 > Those properties would all be requirements for selecting a different ha= sh function. We could add that as a requirement for extensions if you t= hink that is appropriate. >=20 > John B. >=20 >> On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig wrote: >> >> Hi all, >> >> I am trying to figure out how to progress the SPOP document and >> therefore I read through the discussion about the code challenge, see >> >> I wanted to share my view about this topic. >> >> As a summary, the mechanism works as follows: >> >> C: Compute code_verifier:=3Drand() >> C: Compute code_challenge:=3Dfunc(code_verifier) >> >> (For this discussion, the function func() is SHA-256.) >> >> C: Send(Authz Request + code_challenge,S) >> >> S: store code_challenge >> S: Send(Authz Grant,C) >> >> C: Send(Access Token Request || code_verifier, S) >> >> S: Compute code_challenge':=3Dfunc(code_verifier) >> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >> >> The document currently does not say how much entropy the random number= >> has to have. >> >> The text only talks about the output size and SHA-256 indeed produces = a >> 256 bit output. >> >> Here is the relevant text: >> >> " >> NOTE: code verifier SHOULD have enough entropy to make it impractica= l >> to guess the value. It is RECOMMENDED that the output of a suitable= >> random number generator be used to create a 32-octet sequence. >> " >> >> I suggest to recommend at least 128 bits, which is inline with the >> recommendations for symmetric ciphers in >> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >> >> I would also suggest to reference RFC 4086 concerning the creation of >> random numbers. >> >> Furthermore, since you allow other hash functions to be used as well i= t >> would be good to give guidance about what the properties of those hash= >> functions should be. You definitely want a cryptographic hash function= >> that provides pre-image resistance, second pre-image resistance, and >> collision resistance. >> >> Given the size of the input and output it is impractical to compute a >> table that maps code_verifies to code_challenges. >> >> This mechanism provides better properties than the "plain" mechanism >> since it deals with an attacker that can see responses as well as >> requests (but cannot modify them). It does not provide any protection >> against a true man-in-the-middle attacker. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --DgWdj7kIQFACJcBV0R7JuKfapefQbTn7R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfvgqAAoJEGhJURNOOiAtfPYH/3oq70Pl2kI4durGTEx0hdMk QAKFO2ie9JDHDtTcLgeLKw0YafTbn9FyFRiIwIrsN7X0EcG3eGQnJwxuA4x/03Fj Zk+L/Ho/LNLQV8w1V8Zs334uaxrP3Ad13/FNNKpW4wmCHPUtzmVq4WyRVD+RR8Qm AR/jYkkOm9Vgnu4OEHJBqA9EjLqdHjr2pcFKwRshqvr/l05iH2aYpaCUJv9y9G+p fLc5FMrR0wtXZGzgazzPqhXor+ZpO/wHxuDBvp4ktrLoiBZQVcY3LM1M3jpez9jp gFesrQm+KrmlA4knM0GezgpwarAzUqhVLAlzkQB38t4RQ6wxDsfFqCyW4p9f8aQ= =JGUG -----END PGP SIGNATURE----- --DgWdj7kIQFACJcBV0R7JuKfapefQbTn7R-- From nobody Wed Dec 3 04:01:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7211A1A82 for ; Wed, 3 Dec 2014 04:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9G4ouhjjeIV for ; Wed, 3 Dec 2014 04:01:46 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BEA1A1AC6 for ; Wed, 3 Dec 2014 04:01:10 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so19469534wgh.38 for ; Wed, 03 Dec 2014 04:01:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=niyFLNiUMv2tOVvO69zHiIebq1VPDbTedOAKaTEfzUM=; b=ixc6WqMl24kC882omWTIfnmrps5YVq6OEPaxfpdarmDlihpEQ5RXD6acO/npcSu7+N jfjIkAshxl9V9s3spKkxLblvgzxoM6ovEWjJdd6z52k2c5qX0ycHZrck/QcV/ed4l5dw RJLU2Y3DMIlL24PC5Q37Pwbe6si8D4TCK189Z4QHTqmA93mzfY9U90Aqinuy4Ubzos0e tvyoAxAQ6Tey6/Y/fWU3acB+aYJw4x4wEuQMwW+IQaQR3cNwPOgmAQeIjuAyeoZjoVRm ef1YErwqlfe4QvsZJDp9zQa/aNVWVlpU3diMKxHAfsW5olNd6vA6kYUBS0kY/tbIxxR2 PIiw== X-Gm-Message-State: ALoCoQkCNJKJLlWl/tX8Y+xKURixauwWwRfu80IwIOhIQZW4TX88B+mTazzlA4YKDii4aM+c+N1+ X-Received: by 10.180.99.163 with SMTP id er3mr12768411wib.18.1417608068955; Wed, 03 Dec 2014 04:01:08 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id j1sm35992140wjw.25.2014.12.03.04.01.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 04:01:07 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_87EB200F-0AA3-4792-A3D4-FB8A343B0436"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547EF82A.1050505@gmx.net> Date: Wed, 3 Dec 2014 09:01:06 -0300 Message-Id: References: <547EF145.5030501@gmx.net> <547EF82A.1050505@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZdF0lOdnWhu7zL6rPmgPYaH-Knw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:01:48 -0000 --Apple-Mail=_87EB200F-0AA3-4792-A3D4-FB8A343B0436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We have been thinking that new hash functions and new mechanisms (eg = ECDH-ES) would be treated the same and require a spec and review.=20 (At some point I will do a asymmetric extension so that the key can also = be used to encrypt POP keys back to the client, but I don't want to = make this spec look to complicated) Any mechanism using a challenge & verifier approach could fit in to the = defined parameters, a different hash like SHA3 is simple in that it = just be a replacement of the hash function. I think guidance id fine as long as it doesn't limit future options. John B. > On Dec 3, 2014, at 8:46 AM, Hannes Tschofenig = wrote: >=20 > Hi John, >=20 > I believe it makes sense to give recommendations for extensions (if = you > envision them). Of course, I hope that we do not see a flood of > extensions that all use different hash functions. >=20 > Changing the mechanism to something that provides even stronger = security > properties would definitely require a new specification and review. >=20 > Ciao > Hannes >=20 >=20 > On 12/03/2014 12:37 PM, John Bradley wrote: >> Thanks Hannes. >>=20 >> Other methods such as different hashes need to be added via extension = specs. =20 >>=20 >> Are you saying that we should set minimum recommendations for them. >>=20 >> It is also possible that those methods might use something other than = hashing. Key agreement might be a possibility. >>=20 >> Those properties would all be requirements for selecting a different = hash function. We could add that as a requirement for extensions if = you think that is appropriate. >>=20 >> John B. >>=20 >>> On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> I am trying to figure out how to progress the SPOP document and >>> therefore I read through the discussion about the code challenge, = see >>>=20 >>> I wanted to share my view about this topic. >>>=20 >>> As a summary, the mechanism works as follows: >>>=20 >>> C: Compute code_verifier:=3Drand() >>> C: Compute code_challenge:=3Dfunc(code_verifier) >>>=20 >>> (For this discussion, the function func() is SHA-256.) >>>=20 >>> C: Send(Authz Request + code_challenge,S) >>>=20 >>> S: store code_challenge >>> S: Send(Authz Grant,C) >>>=20 >>> C: Send(Access Token Request || code_verifier, S) >>>=20 >>> S: Compute code_challenge':=3Dfunc(code_verifier) >>> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >>>=20 >>> The document currently does not say how much entropy the random = number >>> has to have. >>>=20 >>> The text only talks about the output size and SHA-256 indeed = produces a >>> 256 bit output. >>>=20 >>> Here is the relevant text: >>>=20 >>> " >>> NOTE: code verifier SHOULD have enough entropy to make it = impractical >>> to guess the value. It is RECOMMENDED that the output of a = suitable >>> random number generator be used to create a 32-octet sequence. >>> " >>>=20 >>> I suggest to recommend at least 128 bits, which is inline with the >>> recommendations for symmetric ciphers in >>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>>=20 >>> I would also suggest to reference RFC 4086 concerning the creation = of >>> random numbers. >>>=20 >>> Furthermore, since you allow other hash functions to be used as well = it >>> would be good to give guidance about what the properties of those = hash >>> functions should be. You definitely want a cryptographic hash = function >>> that provides pre-image resistance, second pre-image resistance, and >>> collision resistance. >>>=20 >>> Given the size of the input and output it is impractical to compute = a >>> table that maps code_verifies to code_challenges. >>>=20 >>> This mechanism provides better properties than the "plain" mechanism >>> since it deals with an attacker that can see responses as well as >>> requests (but cannot modify them). It does not provide any = protection >>> against a true man-in-the-middle attacker. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_87EB200F-0AA3-4792-A3D4-FB8A343B0436 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDMxMjAxMDZaMCMGCSqGSIb3DQEJBDEWBBTm7t1sXO2X3yfcydEUlDhL Fs9rSTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBv7oME2zJebMgEe/ghBTVMvSOdzYJTYeMz0Tkav24ASWbTZpA59Y/g uvCqFIlGh+3/+nOfN7dTV0QuCm3ZzYpbIRmJlOxS+CCm3hje2Y6azwQBK5xd3VtWiNR97cdLCYFQ bAZsLVi9KebDveQBDgpErmZefSOyOwqAE6ImAurbgarC3TSctpsFp1kQp8hJyc8DOLhGs/bEV8XL 3pV05FiiCFJkobyp8j3kkf2rJ03nI1MxpS6p8aG8Owpr+I0rr+gHjvOt8qMPHJKykLsT4Z/WZotb WWSPB4Wah7EvI1hyqF2C/MwevYlTetI5EwR3Pkyo89W8KWvpvBY4XcCZpoTtAAAAAAAA --Apple-Mail=_87EB200F-0AA3-4792-A3D4-FB8A343B0436-- From nobody Wed Dec 3 04:10:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB211A1AE1 for ; Wed, 3 Dec 2014 04:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNkE2hdnRLFQ for ; Wed, 3 Dec 2014 04:10:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422D61A1AE0 for ; Wed, 3 Dec 2014 04:10:03 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Mey7N-1XY7aD02gb-00OTd4; Wed, 03 Dec 2014 13:10:00 +0100 Message-ID: <547EFD97.2040708@gmx.net> Date: Wed, 03 Dec 2014 13:09:59 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <547EF145.5030501@gmx.net> <547EF82A.1050505@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RQJDFVg935OhOR0cjgfHL0f0NxdPnp1T6" X-Provags-ID: V03:K0:G/iAUJ/prQb1GxRwHwn25Ig8S/Hz2adFDulqSM6Cw9LTbxgUlkT mKHo/7W8NK9NPPg5+xI8QqXW3RLet9eB3vYL72N2A/vXLRbwupDKN7QkTkMTFFhoBICbWIh laetRNEKSmE7XawLl7CR97+z1W0pLha70yiRv5JWTa4bKLnKXArMwjakbedRBO8rQvc9tXG zEJOXZFThDApEmNVqZwkw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3aeP4Vusa8GNK-Jz-e330ry8ShY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:10:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RQJDFVg935OhOR0cjgfHL0f0NxdPnp1T6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just looked at the IANA consideration section and I noticed that there is no policy defined for adding, or deprecating values from various registries, such as the code_challenge_method. So, you can essentially decide about how easy or difficult you can make it for yourself. I would think that 'Specification Required' would be appropriate. You can copy the relevant text from https://tools.ietf.org/html/rfc6749#section-11 and adjust it accordingly.= Ciao Hannes On 12/03/2014 01:01 PM, John Bradley wrote: > We have been thinking that new hash functions and new mechanisms (eg EC= DH-ES) would be treated the same and require a spec and review.=20 >=20 > (At some point I will do a asymmetric extension so that the key can als= o be used to encrypt POP keys back to the client, but I don't want to ma= ke this spec look to complicated) >=20 > Any mechanism using a challenge & verifier approach could fit in to the= defined parameters, a different hash like SHA3 is simple in that it jus= t be a replacement of the hash function. >=20 > I think guidance id fine as long as it doesn't limit future options. >=20 > John B. >=20 >=20 >> On Dec 3, 2014, at 8:46 AM, Hannes Tschofenig wrote: >> >> Hi John, >> >> I believe it makes sense to give recommendations for extensions (if yo= u >> envision them). Of course, I hope that we do not see a flood of >> extensions that all use different hash functions. >> >> Changing the mechanism to something that provides even stronger securi= ty >> properties would definitely require a new specification and review. >> >> Ciao >> Hannes >> >> >> On 12/03/2014 12:37 PM, John Bradley wrote: >>> Thanks Hannes. >>> >>> Other methods such as different hashes need to be added via extension= specs. =20 >>> >>> Are you saying that we should set minimum recommendations for them. >>> >>> It is also possible that those methods might use something other than= hashing. Key agreement might be a possibility. >>> >>> Those properties would all be requirements for selecting a different = hash function. We could add that as a requirement for extensions if you= think that is appropriate. >>> >>> John B. >>> >>>> On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig wrote: >>>> >>>> Hi all, >>>> >>>> I am trying to figure out how to progress the SPOP document and >>>> therefore I read through the discussion about the code challenge, se= e >>>> >>>> I wanted to share my view about this topic. >>>> >>>> As a summary, the mechanism works as follows: >>>> >>>> C: Compute code_verifier:=3Drand() >>>> C: Compute code_challenge:=3Dfunc(code_verifier) >>>> >>>> (For this discussion, the function func() is SHA-256.) >>>> >>>> C: Send(Authz Request + code_challenge,S) >>>> >>>> S: store code_challenge >>>> S: Send(Authz Grant,C) >>>> >>>> C: Send(Access Token Request || code_verifier, S) >>>> >>>> S: Compute code_challenge':=3Dfunc(code_verifier) >>>> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >>>> >>>> The document currently does not say how much entropy the random numb= er >>>> has to have. >>>> >>>> The text only talks about the output size and SHA-256 indeed produce= s a >>>> 256 bit output. >>>> >>>> Here is the relevant text: >>>> >>>> " >>>> NOTE: code verifier SHOULD have enough entropy to make it impractic= al >>>> to guess the value. It is RECOMMENDED that the output of a suitabl= e >>>> random number generator be used to create a 32-octet sequence. >>>> " >>>> >>>> I suggest to recommend at least 128 bits, which is inline with the >>>> recommendations for symmetric ciphers in >>>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>>> >>>> I would also suggest to reference RFC 4086 concerning the creation o= f >>>> random numbers. >>>> >>>> Furthermore, since you allow other hash functions to be used as well= it >>>> would be good to give guidance about what the properties of those ha= sh >>>> functions should be. You definitely want a cryptographic hash functi= on >>>> that provides pre-image resistance, second pre-image resistance, and= >>>> collision resistance. >>>> >>>> Given the size of the input and output it is impractical to compute = a >>>> table that maps code_verifies to code_challenges. >>>> >>>> This mechanism provides better properties than the "plain" mechanism= >>>> since it deals with an attacker that can see responses as well as >>>> requests (but cannot modify them). It does not provide any protectio= n >>>> against a true man-in-the-middle attacker. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >=20 --RQJDFVg935OhOR0cjgfHL0f0NxdPnp1T6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfv2XAAoJEGhJURNOOiAtDYcH/i/ZHtck82R2WtZxnaJ6yx8f ahiqRkN2R4jvHMVI79ydT5GPNFu/dz8oHhk3a2NxpGCm+p5b5iNtOfCi1qGoJDJA OaF81gl1kR5522Iva9wX/K0aZZHIYfSBzAxu13zN0VwjfHp7LkBUVICdjG6t7dyq WcUky3Y/+tTsFaKbk2s7eaw9m3nmBLINrtKXO2yvEoL0erB90HTnXGpskprs0bjk M887VVNga1TW4coAUfglBJhGdqcvZk0jLTtnNrW4ZO3Y9b/wDPoC6chNOfZTjjVw /DFe8NNe5K+kYh5qme/Y3QHL2BZWz/ToTzMeEwxDDEZvOiEVihUHBvPpWsWlcfc= =C47s -----END PGP SIGNATURE----- --RQJDFVg935OhOR0cjgfHL0f0NxdPnp1T6-- From nobody Wed Dec 3 04:14:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61981A1A82 for ; Wed, 3 Dec 2014 04:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS42i_996LTP for ; Wed, 3 Dec 2014 04:14:32 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664201A1A80 for ; Wed, 3 Dec 2014 04:14:32 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so31155809wib.4 for ; Wed, 03 Dec 2014 04:14:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IKNMKv0UWxtMaPtIIFA/PLrHVqyCTrg1/BNpunpVQK8=; b=MoyZkfJ+y8A+PXWK0lkOpofMN8LbhNmUusuCzwy9tf2TcFMhYUZWVg+jZA7II6PNgk jpbqzyGvtVPkD49qtJ/KcJ5LpZHMsch9FhSV/WAqV3b+hjWvRvL4PMWuIKhmOtmci1Hr vPO+/y4W7MPtuwFoH4tvakNC9fQDTvuoZnGTewhKYgVcRWtfysvwcSdzW+6qiXMQZXIT RqZtrK9FO8HgxTmekWtlkTwOz2seHq02MzmCf5pV/A0dlCcePAXnoH+64rXJxxmCdon1 xu1NuGNeNk5wwhbY4mmBWoTOm4ZGc/Hm7abtyUGNd9CKYa2SvnDtciYCsYwvcVnYHVEN HBYw== X-Gm-Message-State: ALoCoQn2mR2GL+ZuMpGE6vDLKO2QEmLG16pnGhEVtOiutgimoIKL278qfIFBzEbw5Zzw03JPoZk3 X-Received: by 10.180.11.97 with SMTP id p1mr13254406wib.22.1417608871128; Wed, 03 Dec 2014 04:14:31 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id gy8sm12038214wib.23.2014.12.03.04.14.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 04:14:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_93F15B81-3682-4C30-9DEF-F8383B368C42"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <547EFD97.2040708@gmx.net> Date: Wed, 3 Dec 2014 09:14:28 -0300 Message-Id: <5E44E18E-8BE2-4CE3-AD07-543D9A7619DE@ve7jtb.com> References: <547EF145.5030501@gmx.net> <547EF82A.1050505@gmx.net> <547EFD97.2040708@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TpuX71iyUeiTyn87lkZVLlVwgbA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:14:35 -0000 --Apple-Mail=_93F15B81-3682-4C30-9DEF-F8383B368C42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The only question is if the OAuth ext review list is the correct place = for review. =20 I don't have a problem with re using an existing review process for a = new registry, if that works for people. John B. > On Dec 3, 2014, at 9:09 AM, Hannes Tschofenig = wrote: >=20 > I just looked at the IANA consideration section and I noticed that = there > is no policy defined for adding, or deprecating values from various > registries, such as the code_challenge_method. >=20 > So, you can essentially decide about how easy or difficult you can = make > it for yourself. >=20 > I would think that 'Specification Required' would be appropriate. > You can copy the relevant text from > https://tools.ietf.org/html/rfc6749#section-11 and adjust it = accordingly. >=20 > Ciao > Hannes >=20 > On 12/03/2014 01:01 PM, John Bradley wrote: >> We have been thinking that new hash functions and new mechanisms (eg = ECDH-ES) would be treated the same and require a spec and review.=20 >>=20 >> (At some point I will do a asymmetric extension so that the key can = also be used to encrypt POP keys back to the client, but I don't want = to make this spec look to complicated) >>=20 >> Any mechanism using a challenge & verifier approach could fit in to = the defined parameters, a different hash like SHA3 is simple in that it = just be a replacement of the hash function. >>=20 >> I think guidance id fine as long as it doesn't limit future options. >>=20 >> John B. >>=20 >>=20 >>> On Dec 3, 2014, at 8:46 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi John, >>>=20 >>> I believe it makes sense to give recommendations for extensions (if = you >>> envision them). Of course, I hope that we do not see a flood of >>> extensions that all use different hash functions. >>>=20 >>> Changing the mechanism to something that provides even stronger = security >>> properties would definitely require a new specification and review. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On 12/03/2014 12:37 PM, John Bradley wrote: >>>> Thanks Hannes. >>>>=20 >>>> Other methods such as different hashes need to be added via = extension specs. =20 >>>>=20 >>>> Are you saying that we should set minimum recommendations for them. >>>>=20 >>>> It is also possible that those methods might use something other = than hashing. Key agreement might be a possibility. >>>>=20 >>>> Those properties would all be requirements for selecting a = different hash function. We could add that as a requirement for = extensions if you think that is appropriate. >>>>=20 >>>> John B. >>>>=20 >>>>> On Dec 3, 2014, at 8:17 AM, Hannes Tschofenig = wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I am trying to figure out how to progress the SPOP document and >>>>> therefore I read through the discussion about the code challenge, = see >>>>>=20 >>>>> I wanted to share my view about this topic. >>>>>=20 >>>>> As a summary, the mechanism works as follows: >>>>>=20 >>>>> C: Compute code_verifier:=3Drand() >>>>> C: Compute code_challenge:=3Dfunc(code_verifier) >>>>>=20 >>>>> (For this discussion, the function func() is SHA-256.) >>>>>=20 >>>>> C: Send(Authz Request + code_challenge,S) >>>>>=20 >>>>> S: store code_challenge >>>>> S: Send(Authz Grant,C) >>>>>=20 >>>>> C: Send(Access Token Request || code_verifier, S) >>>>>=20 >>>>> S: Compute code_challenge':=3Dfunc(code_verifier) >>>>> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE = FAIL. >>>>>=20 >>>>> The document currently does not say how much entropy the random = number >>>>> has to have. >>>>>=20 >>>>> The text only talks about the output size and SHA-256 indeed = produces a >>>>> 256 bit output. >>>>>=20 >>>>> Here is the relevant text: >>>>>=20 >>>>> " >>>>> NOTE: code verifier SHOULD have enough entropy to make it = impractical >>>>> to guess the value. It is RECOMMENDED that the output of a = suitable >>>>> random number generator be used to create a 32-octet sequence. >>>>> " >>>>>=20 >>>>> I suggest to recommend at least 128 bits, which is inline with the >>>>> recommendations for symmetric ciphers in >>>>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>>>>=20 >>>>> I would also suggest to reference RFC 4086 concerning the creation = of >>>>> random numbers. >>>>>=20 >>>>> Furthermore, since you allow other hash functions to be used as = well it >>>>> would be good to give guidance about what the properties of those = hash >>>>> functions should be. You definitely want a cryptographic hash = function >>>>> that provides pre-image resistance, second pre-image resistance, = and >>>>> collision resistance. >>>>>=20 >>>>> Given the size of the input and output it is impractical to = compute a >>>>> table that maps code_verifies to code_challenges. >>>>>=20 >>>>> This mechanism provides better properties than the "plain" = mechanism >>>>> since it deals with an attacker that can see responses as well as >>>>> requests (but cannot modify them). It does not provide any = protection >>>>> against a true man-in-the-middle attacker. >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_93F15B81-3682-4C30-9DEF-F8383B368C42 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDMxMjE0MjlaMCMGCSqGSIb3DQEJBDEWBBSqRImQnLUSeAKHuQ0W3ueK kvPglzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAsq7HB8ItbnM0FZYB9REQmR/WToeRMVIdPKEsMa5bzAS9s/pDocoGc ZjqG5hCpvcjWbfUZ3je2Mdvhv4YgHHlHHM56grAoIigXgX32N4Sf+s1noXGqBJ+q8PEZG6obT0d4 qbNpioTC/wpXfc+BOK6VGPU6IRiIc1TPwTu5T3epbpBVXwG3uu0paGbK2KtDQbv+pS7EVpxlxQxt TELQIu+CXO2emX300Sy/G5PTRKRXaucxyPx1PjiaiAoaY2olcWfcepzvaxVYZAQowL9kXAzW0nd2 WnsG9hs1mpyGkyBO/eyw5X3e+JTd3bs63D+Oi4F3XYvzza6O/rTkTYMljQL1AAAAAAAA --Apple-Mail=_93F15B81-3682-4C30-9DEF-F8383B368C42-- From nobody Wed Dec 3 04:22:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2971A1A93 for ; Wed, 3 Dec 2014 04:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8joL1tuT9NV for ; Wed, 3 Dec 2014 04:22:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3F81A0174 for ; Wed, 3 Dec 2014 04:22:28 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKcdH-1XuE4c39CJ-0021Ib for ; Wed, 03 Dec 2014 13:22:25 +0100 Message-ID: <547F0081.2050200@gmx.net> Date: Wed, 03 Dec 2014 13:22:25 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7NrRRgHjlhBVQ4e1Ub6mRXhNjsvfoTgOm" X-Provags-ID: V03:K0:0mM3upVJ/Pn5XT14RBVThZ9NIpT43+yuQ/XytA3qXcRU61MB5Q5 GBEXRNCPduOYoB6dHsV7pGR6cElC77xL+QeU6w/XeO0w8fdRIHh7V4QHKMUwDW/ZusbYaiM RsXlxc+zunWgxhGZ8m+0mgPVDvKj9vQfWKLovllYf99KJVuw9fSulqltjreGsSORFPlnL+i Icwn//Ip8E0GUO0msRc7Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/V1C9zc483WhnIzrfMJDUcl-QOzc Subject: [OAUTH-WG] SPOP: Salt & other ideas X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:22:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7NrRRgHjlhBVQ4e1Ub6mRXhNjsvfoTgOm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I also wanted to respond to various ideas that were entertained, including adding salt into the hash function and also for including other parameters in the hash. Before adding new functionality we have to talk about the threats we are trying to address. For example, adding salt just makes the server do more computation. That wouldn't be useful as such. Adding other parameters into the hash function (such as the client/server identifiers) is indeed a common technique with key derivation functions. Here I wasn't able to come up with the attack that we would prevent by doing so. Ciao Hannes --7NrRRgHjlhBVQ4e1Ub6mRXhNjsvfoTgOm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfwCBAAoJEGhJURNOOiAtS10H/jSJVhv5ld2gorBMrbGSXjLx K8nzizLh+q9gcOzGQTy+7+QPCfm8NFp38rXoRjpT4kGikbve8ViU07Zj/PCktsHZ n05QWzxqEM5DYclM9J08PV04PcMbxdlbHnWeEeIKii64o5qTUC2j+IHIVtIV+jjQ TA6zzWFkBRy0but4Dfm7n3CyAFmANj7K61HAfWkplj3Tily54VyyPoDTleaHVlS1 lHFC+4SHcjcq0rA88+66Iyl8D7Sw2NIyPUPxPwCgT9TEnMHdE9DRGBqEIuSSrCs5 5LV7CGrIZjCH55igyJa3KpeRULmapIfW1r8Ty1tfhBrlOibbgzsEFLSbSlU+bC0= =lTxp -----END PGP SIGNATURE----- --7NrRRgHjlhBVQ4e1Ub6mRXhNjsvfoTgOm-- From nobody Wed Dec 3 04:22:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCAE1A1AAA for ; Wed, 3 Dec 2014 04:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qxFhz_ztfpW for ; Wed, 3 Dec 2014 04:22:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55A11A0174 for ; Wed, 3 Dec 2014 04:22:53 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MTwYX-1XVZhC0iZt-00QjsE; Wed, 03 Dec 2014 13:22:51 +0100 Message-ID: <547F009A.70408@gmx.net> Date: Wed, 03 Dec 2014 13:22:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <547EF145.5030501@gmx.net> <547EF82A.1050505@gmx.net> <547EFD97.2040708@gmx.net> <5E44E18E-8BE2-4CE3-AD07-543D9A7619DE@ve7jtb.com> In-Reply-To: <5E44E18E-8BE2-4CE3-AD07-543D9A7619DE@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GI6X8JmnIQgcK1i3XRsM3t4hLgLbkF0vo" X-Provags-ID: V03:K0:+vuKCL5ys9goi1murAFi5LOj4iAHdvfj78Ts9/KPXL3wsh+BaBn Ubr8f/HjX8Z4WhVZukUKlam6icCiTP7A1epezzTvOTtUqfnjYBPqWTWBoOC793f92lA9A6I uDfFrnJt7GOIfvbXRHPgESh5f+MZ5zNAnwOT+gZHiKO2QCAywO+F6EyryfwwSbhVL+UXhon 0ACoqlRF15+VLQ750A8dQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oAsq6xxNx8PVRwyECrmsmG7m5gE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:22:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GI6X8JmnIQgcK1i3XRsM3t4hLgLbkF0vo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/03/2014 01:14 PM, John Bradley wrote: > The only question is if the OAuth ext review list is the correct place = for review. =20 I think it is. --GI6X8JmnIQgcK1i3XRsM3t4hLgLbkF0vo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUfwCaAAoJEGhJURNOOiAtdyIIAJAG9a9Ojh4IO19lzSeGkB55 HR/Gdy9ZJZbS91kP7szK1T1SHXae89lSmtO+smfNgkHYt0Ke5ZmE0JzAlfcjAXM0 qIh/AeOFwL2scuMakj9lE/yLB5JrJ01cpAKRwHVYvTKiGxd54VAXk3Uxag/u3h8B fGjK9h8GrLpLJ1BXdvvnRc6joJC3EzY8gvOxumZGjrgGqefbkxa8g7zqhjS2HyZb XExdbfF/c+kZCkVVO8VVfNtvGpihMS6EjxLoHhdepPKBqONbBSsEo7NXAJAwMUZG frVjkD/D+YAxcEHi05dzED1d4YCc+3RRd4LDprz733+IjmI3Ym5nwLzXehZAErs= =NRdl -----END PGP SIGNATURE----- --GI6X8JmnIQgcK1i3XRsM3t4hLgLbkF0vo-- From nobody Wed Dec 3 06:03:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496371A1B34 for ; Wed, 3 Dec 2014 06:03:55 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6EiyhzTDlG4 for ; Wed, 3 Dec 2014 06:03:52 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0D71A0461 for ; Wed, 3 Dec 2014 06:03:51 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so12234112lbi.2 for ; Wed, 03 Dec 2014 06:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=ZCP5l2Px8KqV5JoO9U8CgE7pU7L6KYeqJTYnW8VFEC4=; b=kvLdE3Gjpnjy7w8HGPpS9mBjrwJYIy35WbmXSYV90ubJaeezLwk5xHfXWPPxXaj0dh XZx5xYsoA7kvsdk9vZPgmauUkUXzLt0N/Jdas2CgtOXdBeQnOEHQRDcj7e9aOy8Po2Ej UI1L8vPtg4YqMMrF4EKTqezJC4zNFLU9ZDbVMWo4OCxhT+PYRh/4G0asdYvfTbp5xTKP I0A3gJXB0pVwo2ziXKXCfeDpUyXStlj/FkEoLq1I2sWIVde2CIkn6oV8fZB+oeXfASjy axjt/XkMsdOMtR8fNYlf0rSTscauDh8L4BJxLw/WHb9rSJz72Sgnd8yQ8cweQE1kt63C w3dA== X-Received: by 10.152.238.1 with SMTP id vg1mr4429074lac.83.1417615429906; Wed, 03 Dec 2014 06:03:49 -0800 (PST) MIME-Version: 1.0 References: From: Thomas Broyer Date: Wed, 03 Dec 2014 14:03:49 +0000 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=001a1134930e20b996050950507e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rJ6ePRhi1boF5iOBb45B2pT8dJ4 Cc: "" Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 14:03:55 -0000 --001a1134930e20b996050950507e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue Dec 02 2014 at 19:53:27 Richer, Justin P. wrote: > Thomas, thanks for the review. Responses inline. > > On Dec 2, 2014, at 11:08 AM, Thomas Broyer wrote: > > > The methods of managing and > validating these authentication credentials are out of scope of this > specification, though it is RECOMMENDED that these credentials be > distinct from those used at an authorization server's token endpoint. > > > and later in the Security Considerations section: > > The authorization server SHOULD issue credentials to any > protected resources that need to access the introspection endpoint, > SHOULD require protected resources to be specifically authorized to > call the introspection endpoint, and SHOULD NOT allow a single piece > of software acting as both a client and a protected resource to re- > use the same credentials between the token endpoint and the > introspection endpoint. > > > Could you expand on the RECOMMENDED and SHOULD NOT here? > What would be the problem with using the same credentials? What's the > trade-off? > > > Different credentials for different purposes, and it lets you manage > things separately at the server. In other words, you've got one class of > thing that *gets* tokens, and one class of thing that *accepts* tokens. T= he > dynamic resource registration draft doesn't presume client credentials at > all, since a resource might not (and in many cases is not) also an OAuth > client. This draft even uses tokens to authorize its calls to the > introspection endpoint, which was suggested as MTI in another thread. > > Additionally, and this may be getting unnecessarily colored by our own > implementation and deployment of pre-WG drafts: we have it currently > implemented such that both are clients (and Ping does something similar > with their own method of accomplishing the same thing), and we want to > start to keep these classes separate. We've found that developers get > confused about whether they're a client or a resource or whatnot as it is= . > This recommendation helps keep the roles separate logically, though serve= rs > are of course free to throw everyone in the same bucket if they so choose= . > That explains why you *could* use different credentials, not why you should do it. Until June this year, we were issuing distinct credentials for the "client" and "resource server" parts of applications (what we used to call "service provider" vs. "data provider"), and people didn't understand what each "part" meant (and that's knowing that most of them don't currently expose APIs themselves!) We thus moved to a single set of credentials that's shared between all the clients (e.g. "front office" vs. "back office") and resource servers (TBH, having distinct credentials for the distinct clients could be challenging in some cases, so that "simplification" was also needed for other reasons). > > The response MAY be cached by the protected resource, and the > authorization server SHOULD communicate appropriate cache controls > using applicable HTTP headers. > > > Reading through https://tools.ietf.org/html/rfc7234 (and > https://tools.ietf.org/html/rfc7231), it's not clear to me how cache > headers would really help, given that the requests to the introspection > endpoint are mostly using the POST method ("optionally" a GET method, and > the Security Considerations section somehow discourages it). > You'd want to check with the HTTPWG but maybe this text should define > what the cache-key would be (it would at least include the token and > resource_id if provided, maybe also the token_type_hint), and that the > response SHOULD NOT have Cache-Control:public or even s-maxage (for the > same reason that it should be protected by authentication). > I'd actually rather say that the RS may cache the response (we're talking > about an "application-level cache" here, not an HTTP cache), and probably > should do it for a small amount of time; and possibly (not sure how well > that would fit here) hint that the AS could very well return an HTTP 429 > (Too Many Requests) if it somehow > detects that the RS doesn't use a (application-level) cache (e.g. asks ma= ny > times for the same token in a very short time frame). This is the kind of > things I could very well add to my implementation later on if we ever see= a > very high number of requests on our introspection endpoint (because looki= ng > up a key-value store using the token as key is much faster than validatin= g > the token =E2=80=93 our tokens are base64url-encoded JSON structures cont= aining an > ID and a salt, and we store the ID and a hash in our datastore; validatin= g > a token thus involves decoding base64url, parsing JSON and computing a > hash, in addition to looking it up in the datastore and validating "iat" > and "exp"). > > > All that we're really trying to say here is that the protected resource > is allowed to cache the response if it wants to, and that the AS could gi= ve > some hints as to how to do it. I can pull out the HTTP-cache-mechanism > language if it's just confusing the matter (which I suspect it is). > Yes please. > In one deployment profile I've written of this, we say that the RS can > cache the introspection result for up to half the token lifetime, given b= y > the 'exp' claim (which we also require in the profile). > Caching the response on the RS is a trade-off between accuracy (and thus security, as you might detect a revoked token long after it's been revoked) and performance (HTTP roundtrips, putting too much pressure on the AS, etc.). This trade-off has to be considered on a per-RS basis, depending on the kind (and sensitivity) of data being managed by the RS. For very sensitive data, you'd likely have a very short cache TTL (or no cache at all, apart from avoiding concurrent requests to the AS for the same token), whereas for "semi-public" data you'd likely trade security for performance (e.g. data is likely to be accessed in several =E2=80=93possibly many=E2=80=93 re= quests, and/or you're using authentication mostly to trace accesses =E2=80=93and possibly = charge for them=E2=80=93, or to check "who" has access, but you don't really care = "when" it has access). This trade-off should probably be mentioned in the Security Considerations, but I don't think giving guidance about how long to cache an introspection response would be useful (could even be harmful as people could just follow the suggestion without really thinking about the implications). --001a1134930e20b996050950507e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue Dec 02 2014 at 19:53:27 Richer, Justin P.= <jricher@mitre.org> wrote:<= br>
Thomas, thanks for the review. Responses inline.

On Dec 2, 2014, at 11:08 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

   The methods of managing and
   validating these authentication credentials are out of scope of this
   specification, though it is RECOMMENDED that these credentials be
   distinct from those used at an authorization server's token endpoint=
.

and later in the Security Considerations section:

   The authorization server SHOULD issue credentials to any
   protected resources that need to access the introspection endpoint,
   SHOULD require protected resources to be specifically authorized to
   call the introspection endpoint, and SHOULD NOT allow a single piece
   of software acting as both a client and a protected resource to re-
   use the same credentials between the token endpoint and the
   introspection endpoint.

Could you expand on the RECOMMENDED and SHOULD NOT here?
What would be the problem with using the same credentials? What's = the trade-off?

Differ= ent credentials for different purposes, and it lets you manage things separ= ately at the server. In other words, you've got one class of thing that= *gets* tokens, and one class of thing that *accepts* tokens. The dynamic r= esource registration draft doesn't presume client credentials at all, since a resource might not = (and in many cases is not) also an OAuth client. This draft even uses token= s to authorize its calls to the introspection endpoint, which was suggested= as MTI in another thread.

Additionally, and this may be getting unnecessarily colored by our own= implementation and deployment of pre-WG drafts: we have it currently imple= mented such that both are clients (and Ping does something similar with the= ir own method of accomplishing the same thing), and we want to start to keep these classes separate. We'v= e found that developers get confused about whether they're a client or = a resource or whatnot as it is. This recommendation helps keep the roles se= parate logically, though servers are of course free to throw everyone in the same bucket if they so choose.
<= /div>

That explains why you *co= uld* use different credentials, not why you should do it.

Until June this year, we were issuing distinct credentials for the = "client" and "resource server" parts of applications (w= hat we used to call "service provider" vs. "data provider&qu= ot;), and people didn't understand what each "part" meant (an= d that's knowing that most of them don't currently expose APIs them= selves!)
We thus moved to a single set of credentials that's = shared between all the clients (e.g. "front office" vs. "bac= k office") and resource servers (TBH, having distinct credentials for = the distinct clients could be challenging in some cases, so that "simp= lification" was also needed for other reasons).
=C2=A0
= 

   The response MAY be cached by the protected resource, and the
   authorization server SHOULD communicate appropriate cache controls
   using applicable HTTP headers.

Reading through https://tools.ietf.org/html/rfc7234 (and=C2=A0https://tools.ietf.org= /html/rfc7231), it's not clear to me how cache headers would really= help, given that the requests to the introspection endpoint are mostly using the= POST method ("optionally" a GET method, and the Security Conside= rations section somehow discourages it).
You'd want to check with the HTTPWG but maybe this text should def= ine what the cache-key would be (it would at least include the token and re= source_id if provided, maybe also the token_type_hint), and that the respon= se SHOULD NOT have Cache-Control:public=C2=A0or even s-maxage=C2=A0(for the same reason that it should be protected by aut= hentication).
I'd actually rather say that the RS may cache the response (we'= ;re talking about an "application-level cache" here, not an HTTP = cache), and probably should do it for a small amount of time; and possibly = (not sure how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) <https://tools.ie= tf.org/html/rfc6585> if it somehow detects that the RS doesn't u= se a (application-level) cache (e.g. asks many times for the same token in a very short time frame). This is the kind of things I could very= well add to my implementation later on if we ever see a very high number o= f requests on our introspection endpoint (because looking up a key-value st= ore using the token as key is much faster than validating the token =E2=80=93 our tokens are base64url-encode= d JSON structures containing an ID and a salt, and we store the ID and a ha= sh in our datastore; validating a token thus involves decoding base64url, p= arsing JSON and computing a hash, in addition to looking it up in the datastore and validating "iat" and "= ;exp").

All th= at we're really trying to say here is that the protected resource is al= lowed to cache the response if it wants to, and that the AS could give some= hints as to how to do it. I can pull out the HTTP-cache-mechanism language= if it's just confusing the matter (which I suspect it is).
<= br>
Yes please.
=C2=A0
In one deployment pr= ofile I've written of this, we say that the RS can cache the introspect= ion result for up to half the token lifetime, given by the 'exp' cl= aim (which we also require in the profile).

Caching the response on the RS is a trade-off betw= een accuracy (and thus security, as you might detect a revoked token long a= fter it's been revoked) and performance (HTTP roundtrips, putting too m= uch pressure on the AS, etc.).
This trade-off has to be considere= d on a per-RS basis, depending on the kind (and sensitivity) of data being = managed by the RS. For very sensitive data, you'd likely have a very sh= ort cache TTL (or no cache at all, apart from avoiding concurrent requests = to the AS for the same token), whereas for "semi-public" data you= 'd likely trade security for performance (e.g. data is likely to be acc= essed in several =E2=80=93possibly many=E2=80=93 requests, and/or you'r= e using authentication mostly to trace accesses =E2=80=93and possibly charg= e for them=E2=80=93, or to check "who" has access, but you don= 9;t really care "when" it has access).
This trade-off s= hould probably be mentioned in the Security Considerations, but I don't= think giving guidance about how long to cache an introspection response wo= uld be useful (could even be harmful as people could just follow the sugges= tion without really thinking about the implications).
--001a1134930e20b996050950507e-- From nobody Wed Dec 3 07:55:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD31A1B86 for ; Wed, 3 Dec 2014 07:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twPK2X9OrPBN for ; Wed, 3 Dec 2014 07:55:02 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id A0D371A1B48 for ; Wed, 3 Dec 2014 07:55:01 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3102536E001; Wed, 3 Dec 2014 10:55:01 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 24DEC3AE034; Wed, 3 Dec 2014 10:55:01 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Wed, 3 Dec 2014 10:55:00 -0500 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: Notes on draft-ietf-oauth-introspection-01 Thread-Index: AQHQDkpJKmFk6MGa7kiP8hZWrsiWypx8+fSAgADte4OAAHMsAA== Date: Wed, 3 Dec 2014 15:54:59 +0000 Message-ID: <88248A2F-F80A-4144-8E69-567BD039DB0B@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_88248A2FF80A41448E69567BD039DB0Bmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/L1hHpT6abty7XJUxGHRw2yr8vE0 Cc: "" Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:55:06 -0000 --_000_88248A2FF80A41448E69567BD039DB0Bmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 3, 2014, at 9:03 AM, Thomas Broyer > wrote: On Tue Dec 02 2014 at 19:53:27 Richer, Justin P. > wrote: Thomas, thanks for the review. Responses inline. On Dec 2, 2014, at 11:08 AM, Thomas Broyer > wrote: The methods of managing and validating these authentication credentials are out of scope of this specification, though it is RECOMMENDED that these credentials be distinct from those used at an authorization server's token endpoint. and later in the Security Considerations section: The authorization server SHOULD issue credentials to any protected resources that need to access the introspection endpoint, SHOULD require protected resources to be specifically authorized to call the introspection endpoint, and SHOULD NOT allow a single piece of software acting as both a client and a protected resource to re- use the same credentials between the token endpoint and the introspection endpoint. Could you expand on the RECOMMENDED and SHOULD NOT here? What would be the problem with using the same credentials? What's the trade= -off? Different credentials for different purposes, and it lets you manage things= separately at the server. In other words, you've got one class of thing th= at *gets* tokens, and one class of thing that *accepts* tokens. The dynamic= resource registration draft doesn't presume client credentials at all, sin= ce a resource might not (and in many cases is not) also an OAuth client. Th= is draft even uses tokens to authorize its calls to the introspection endpo= int, which was suggested as MTI in another thread. Additionally, and this may be getting unnecessarily colored by our own impl= ementation and deployment of pre-WG drafts: we have it currently implemente= d such that both are clients (and Ping does something similar with their ow= n method of accomplishing the same thing), and we want to start to keep the= se classes separate. We've found that developers get confused about whether= they're a client or a resource or whatnot as it is. This recommendation he= lps keep the roles separate logically, though servers are of course free to= throw everyone in the same bucket if they so choose. That explains why you *could* use different credentials, not why you should= do it. Until June this year, we were issuing distinct credentials for the "client"= and "resource server" parts of applications (what we used to call "service= provider" vs. "data provider"), and people didn't understand what each "pa= rt" meant (and that's knowing that most of them don't currently expose APIs= themselves!) We thus moved to a single set of credentials that's shared between all the = clients (e.g. "front office" vs. "back office") and resource servers (TBH, = having distinct credentials for the distinct clients could be challenging i= n some cases, so that "simplification" was also needed for other reasons). OK, that's fair. We can back off the first RECOMMENDED easily enough but I = would like to keep some kind of note in the security considerations section= . I don't want to necessarily encourage people to conflate clients and prot= ected resources. Can you help with wording this so that it's not too prescr= iptive? The response MAY be cached by the protected resource, and the authorization server SHOULD communicate appropriate cache controls using applicable HTTP headers. Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf= .org/html/rfc7231), it's not clear to me how cache headers would really hel= p, given that the requests to the introspection endpoint are mostly using t= he POST method ("optionally" a GET method, and the Security Considerations = section somehow discourages it). You'd want to check with the HTTPWG but maybe this text should define what = the cache-key would be (it would at least include the token and resource_id= if provided, maybe also the token_type_hint), and that the response SHOULD= NOT have Cache-Control:public or even s-maxage (for the same reason that i= t should be protected by authentication). I'd actually rather say that the RS may cache the response (we're talking a= bout an "application-level cache" here, not an HTTP cache), and probably sh= ould do it for a small amount of time; and possibly (not sure how well that= would fit here) hint that the AS could very well return an HTTP 429 (Too M= any Requests) if it somehow detects t= hat the RS doesn't use a (application-level) cache (e.g. asks many times fo= r the same token in a very short time frame). This is the kind of things I = could very well add to my implementation later on if we ever see a very hig= h number of requests on our introspection endpoint (because looking up a ke= y-value store using the token as key is much faster than validating the tok= en =96 our tokens are base64url-encoded JSON structures containing an ID an= d a salt, and we store the ID and a hash in our datastore; validating a tok= en thus involves decoding base64url, parsing JSON and computing a hash, in = addition to looking it up in the datastore and validating "iat" and "exp"). All that we're really trying to say here is that the protected resource is = allowed to cache the response if it wants to, and that the AS could give so= me hints as to how to do it. I can pull out the HTTP-cache-mechanism langua= ge if it's just confusing the matter (which I suspect it is). Yes please. Will do, thanks. In one deployment profile I've written of this, we say that the RS can cach= e the introspection result for up to half the token lifetime, given by the = 'exp' claim (which we also require in the profile). Caching the response on the RS is a trade-off between accuracy (and thus se= curity, as you might detect a revoked token long after it's been revoked) a= nd performance (HTTP roundtrips, putting too much pressure on the AS, etc.)= . This trade-off has to be considered on a per-RS basis, depending on the kin= d (and sensitivity) of data being managed by the RS. For very sensitive dat= a, you'd likely have a very short cache TTL (or no cache at all, apart from= avoiding concurrent requests to the AS for the same token), whereas for "s= emi-public" data you'd likely trade security for performance (e.g. data is = likely to be accessed in several =96possibly many=96 requests, and/or you'r= e using authentication mostly to trace accesses =96and possibly charge for = them=96, or to check "who" has access, but you don't really care "when" it = has access). This trade-off should probably be mentioned in the Security Considerations,= but I don't think giving guidance about how long to cache an introspection= response would be useful (could even be harmful as people could just follo= w the suggestion without really thinking about the implications). Yes, that's exactly the tradeoff. We can move the discussion to the securit= y considerations, and just mention that the response MAY be cached up above= . Would you be willing to contribute text for this item as well? And, thanks for your thorough review. Feedback from real implementors is al= ways best, and it helps ensure a spec doesn't devolve into hand-waving. -- Justin --_000_88248A2FF80A41448E69567BD039DB0Bmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2B0B63F3268F2347ADD7FD2D1767E9CB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
On Dec 3, 2014, at 9:03 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

On Tue Dec 02 2014 at 19:53:27 Richer, Justin P.= <jricher@mitre.org> wrote:<= br>
Thomas, thanks for the review. Response= s inline.

On Dec 2, 2014, at 11:08 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

   The methods of managing and
   validating these authentication credentials are out of scope of this
   specification, though it is RECOMMENDED that these credentials be
   distinct from those used at an authorization server's token endpoint.

and later in the Security Considerations section:

   The authorization server SHOULD issue credentials to any
   protected resources that need to access the introspection endpoint,
   SHOULD require protected resources to be specifically authorized to
   call the introspection endpoint, and SHOULD NOT allow a single piece
   of software acting as both a client and a protected resource to re-
   use the same credentials between the token endpoint and the
   introspection endpoint.

Could you expand on the RECOMMENDED and SHOULD NOT here?
What would be the problem with using the same credentials? What's the = trade-off?

Different credentials for different purposes, and it lets you manage t= hings separately at the server. In other words, you've got one class of thi= ng that *gets* tokens, and one class of thing that *accepts* tokens. The dy= namic resource registration draft doesn't presume client credentials at all, since a resource might not (and= in many cases is not) also an OAuth client. This draft even uses tokens to= authorize its calls to the introspection endpoint, which was suggested as = MTI in another thread.

Additionally, and this may be getting unnecessarily colored by our own= implementation and deployment of pre-WG drafts: we have it currently imple= mented such that both are clients (and Ping does something similar with the= ir own method of accomplishing the same thing), and we want to start to keep these classes separate. We've fo= und that developers get confused about whether they're a client or a resour= ce or whatnot as it is. This recommendation helps keep the roles separate l= ogically, though servers are of course free to throw everyone in the same bucket if they so choose.

That explains why you *could* use different credentials, not why you s= hould do it.

Until June this year, we were issuing distinct credentials for the &qu= ot;client" and "resource server" parts of applications (what= we used to call "service provider" vs. "data provider"= ), and people didn't understand what each "part" meant (and that'= s knowing that most of them don't currently expose APIs themselves!)
We thus moved to a single set of credentials that's shared between all= the clients (e.g. "front office" vs. "back office") an= d resource servers (TBH, having distinct credentials for the distinct clien= ts could be challenging in some cases, so that "simplification" was also needed for other reasons).

OK, that's fair. We can back off the first RECOMMENDED easily enough b= ut I would like to keep some kind of note in the security considerations se= ction. I don't want to necessarily encourage people to conflate clients and= protected resources. Can you help with wording this so that it's not too prescriptive?

 

   The response MAY be cached by the protected resource, and the
   authorization server SHOULD communicate appropriate cache controls
   using applicable HTTP headers.

Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf.org/html/rfc723= 1), it's not clear to me how cache headers would really help, given tha= t the requests to the introspection endpoint are mostly using the POST method ("optionally" a GET method, and= the Security Considerations section somehow discourages it).
You'd want to check with the HTTPWG but maybe this text should define = what the cache-key would be (it would at least include the token and resour= ce_id if provided, maybe also the token_type_hint), and that the response S= HOULD NOT have Cache-Control:public or even s-maxage (for the same reason that it should be protected by aut= hentication).
I'd actually rather say that the RS may cache the response (we're talk= ing about an "application-level cache" here, not an HTTP cache), = and probably should do it for a small amount of time; and possibly (not sur= e how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) <https://tools.ie= tf.org/html/rfc6585> if it somehow detects that the RS doesn't use a= (application-level) cache (e.g. asks many times for the same token in a very short time frame). This is the kind of = things I could very well add to my implementation later on if we ever see a= very high number of requests on our introspection endpoint (because lookin= g up a key-value store using the token as key is much faster than validating the token =96 our tokens are b= ase64url-encoded JSON structures containing an ID and a salt, and we store = the ID and a hash in our datastore; validating a token thus involves decodi= ng base64url, parsing JSON and computing a hash, in addition to looking it up in the datastore and validating "= ;iat" and "exp").

All that we're really trying to say her= e is that the protected resource is allowed to cache the response if it wan= ts to, and that the AS could give some hints as to how to do it. I can pull= out the HTTP-cache-mechanism language if it's just confusing the matter (which I suspect it is).

Yes please.

Will do, thanks.

 
In one deployment profile I've written = of this, we say that the RS can cache the introspection result for up to ha= lf the token lifetime, given by the 'exp' claim (which we also require in t= he profile).

Caching the response on the RS is a trade-off between accuracy (and th= us security, as you might detect a revoked token long after it's been revok= ed) and performance (HTTP roundtrips, putting too much pressure on the AS, = etc.).
This trade-off has to be considered on a per-RS basis, depending on th= e kind (and sensitivity) of data being managed by the RS. For very sensitiv= e data, you'd likely have a very short cache TTL (or no cache at all, apart= from avoiding concurrent requests to the AS for the same token), whereas for "semi-public" data yo= u'd likely trade security for performance (e.g. data is likely to be access= ed in several =96possibly many=96 requests, and/or you're using authenticat= ion mostly to trace accesses =96and possibly charge for them=96, or to check "who" has access, but you don't really = care "when" it has access).
This trade-off should probably be mentioned in the Security Considerat= ions, but I don't think giving guidance about how long to cache an introspe= ction response would be useful (could even be harmful as people could just = follow the suggestion without really thinking about the implications).

Yes, that's exactly the tradeoff. We can move the discussion to the se= curity considerations, and just mention that the response MAY be cached up = above. Would you be willing to contribute text for this item as well?

And, thanks for your thorough review. Feedback from real implementors = is always best, and it helps ensure a spec doesn't devolve into hand-waving= .

 -- Justin
--_000_88248A2FF80A41448E69567BD039DB0Bmitreorg_-- From nobody Wed Dec 3 10:10:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64B41A8BC2 for ; Wed, 3 Dec 2014 10:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkDk-BRYlZb7 for ; Wed, 3 Dec 2014 10:10:15 -0800 (PST) Received: from nm48-vm10.bullet.mail.bf1.yahoo.com (nm48-vm10.bullet.mail.bf1.yahoo.com [216.109.114.235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36FC1A8AAD for ; Wed, 3 Dec 2014 10:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417630208; bh=JApnr05dTfG8NMqJiBejqM1ZYex5k3/xzet89AGb3vs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=EI2YvhUnMXthqzlDz94te7x4Ad59CY9MgHXMXGbqdRdRLJDccC6YjW4AI99syfV4A3JrhGNCdqLW+AGOUH2xR91CKf13uRv2HAvc7J4PgF4T1+RkZBZ8MK/WavHncSKvdPeLp3ULLBkJV0aj93NA+w5V9xSuUrMWmNDK5SV1RcJRemhpoO9MgHwCUBFV2UXfb0CI3hKctPjqZ2QoAndrIu1m3sVf/jevPo/7uEHo6IjNd0JMqd+7UK1l0QRwVBkz0wRlYDlrZ/L2L4Qykh3EazL3FJg4+lc6Ml1jLpz72sFe46hHH9ooAEYFXCEViXu2PpRuhTWYHr34otdqojJPAA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=sBJlBq2EFlaoGeZcSYGNbF9GcP/qHKydcMzu7gMbhCpEPzwhx5swbCOGFzp4PV2u/R1ZeKhqfZAPlF3g42v386Vfy/mQGGgvl43stTJaw7w3tMrBy5F5KjEFigcSZBPtKGbc7faIhlRR3QE90kSGSvYSRYuO/HCQ+1kLvhMsnrWDtFnweUltF03I7CHvpWC2BsdXRHeWBaUcio7QeGoNcEtQfCfp7wEku52Isj/qgIVO5LvA+QYg5oy1TnbL3fCPSUdpnAiR/+kVfI4SvMVCiKBbzzcQ6MBrfJ1N049VniGzZzeGdW61nZq2/FkCd802WKppgBHjcZZnARPjqvd9eg==; Received: from [66.196.81.172] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2014 18:10:08 -0000 Received: from [98.139.212.211] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 03 Dec 2014 18:10:08 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 03 Dec 2014 18:10:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 120177.78814.bm@omp1020.mail.bf1.yahoo.com X-YMail-OSG: FbxnU3IVM1lN7Ivh_FTT.noFw0lSDjptXhQwKE8sfjEtmuq5MlTiZ8SPACGvMFN _pc_1NCqbCfebC_b96wJ9QKhhY0eP1KoTsmF5zBQ7OGlQg416zbB1I3i866VQLGIDLspBfFnXUNx 6goDFLTn3YAkm7IbugibYvCpsAUZnQqd6iLPu3L4NqHjUoCupn7Eif4xIHAofP0FXKaq3EqOWjJS t2DHyoLSArKqzG3vt0gI7_jntZoKvN2LLaPSywFXW09YwIRbrO37.i2sebYINTS67X2blnz_jAoF 4Pfbx8XICUq_Gz8zfebV7VW2iJf5PwwMq8V_skKDETkT1iOogtc_1Il7etjpdT58zvkDjGh.dO24 Gm3m5DslgseZ.GMKPibWHLuhqIFZo4YWyV1yGGWVfx8fB8TvGhbJ8.sWb4uTMkoD1KVKZp0b.skc 0dWh6oTHVY5tqvP4vxjzljH_dPkv.M07ogLk.SsfuAwI_DiWtLJPbzMWE77_vZ2HbCaBx4UAk Received: by 76.13.27.35; Wed, 03 Dec 2014 18:10:07 +0000 Date: Wed, 3 Dec 2014 18:10:07 +0000 (UTC) From: Bill Mills To: Hannes Tschofenig , "oauth@ietf.org" Message-ID: <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> In-Reply-To: <547EF145.5030501@gmx.net> References: <547EF145.5030501@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4544891_579265890.1417630207266" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YMkC6hIj6bdGlYzOKZ52aVe54Hg Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 18:10:17 -0000 ------=_Part_4544891_579265890.1417630207266 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quoting from 7.1=C2=A0 "It is RECOMMENDED that the output of a suitable random number=C2=A0generat= or be used to create a 32-octet sequence." So the spec is already recommending 256 bits of randomness, is that languag= e not clear enough?=20 On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig wrote: =20 Hi all, I am trying to figure out how to progress the SPOP document and therefore I read through the discussion about the code challenge, see I wanted to share my view about this topic. As a summary, the mechanism works as follows: C: Compute code_verifier:=3Drand() C: Compute code_challenge:=3Dfunc(code_verifier) (For this discussion, the function func() is SHA-256.) C: Send(Authz Request + code_challenge,S) S: store code_challenge S: Send(Authz Grant,C) C: Send(Access Token Request || code_verifier, S) S: Compute code_challenge':=3Dfunc(code_verifier) S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. The document currently does not say how much entropy the random number has to have. The text only talks about the output size and SHA-256 indeed produces a 256 bit output. Here is the relevant text: " =C2=A0 NOTE: code verifier SHOULD have enough entropy to make it impractica= l =C2=A0 to guess the value.=C2=A0 It is RECOMMENDED that the output of a sui= table =C2=A0 random number generator be used to create a 32-octet sequence. " I suggest to recommend at least 128 bits, which is inline with the recommendations for symmetric ciphers in http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I would also suggest to reference RFC 4086 concerning the creation of random numbers. Furthermore, since you allow other hash functions to be used as well it would be good to give guidance about what the properties of those hash functions should be. You definitely want a cryptographic hash function that provides pre-image resistance, second pre-image resistance, and collision resistance. Given the size of the input and output it is impractical to compute a table that maps code_verifies to code_challenges. This mechanism provides better properties than the "plain" mechanism since it deals with an attacker that can see responses as well as requests (but cannot modify them). It does not provide any protection against a true man-in-the-middle attacker. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4544891_579265890.1417630207266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Quoting fr= om 7.1 

"It is RECOMMENDED that the output of a suitable ra= ndom number 
generator be used to create a 32-octet sequence."

So the spec is already recommending 256 bits of ran= domness, is that language not clear enough?


On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig &l= t;hannes.tschofenig@gmx.net> wrote:


Hi all,
=
I am trying to figure out how to progress the SPOP document and
ther= efore I read through the discussion about the code challenge, see

I = wanted to share my view about this topic.

As a summary, the mechanis= m works as follows:

C: Compute code_verifier:=3Drand()
C: Compute= code_challenge:=3Dfunc(code_verifier)

(For this discussion, the fun= ction func() is SHA-256.)

C: Send(Authz Request + code_challenge,S)<= br>
S: store code_challenge
S: Send(Authz Grant,C)

C: Send(Acc= ess Token Request || code_verifier, S)

S: Compute code_challenge':= =3Dfunc(code_verifier)
S: IF (code_challenge'=3D=3Dcode_challenge) THEN = SUCCESS ELSE FAIL.

The document currently does not say how much entr= opy the random number
has to have.

The text only talks about the = output size and SHA-256 indeed produces a
256 bit output.

Here is= the relevant text:

"
  NOTE: code verifier SHOULD have eno= ugh entropy to make it impractical
  to guess the value.  It = is RECOMMENDED that the output of a suitable
  random number gener= ator be used to create a 32-octet sequence.
"

I suggest to recomm= end at least 128 bits, which is inline with the
recommendations for symm= etric ciphers in
http://tools.ietf.org/html/draft-ietf-uta-tls-b= cp-07

I would also suggest to reference RFC 4086 concerning the = creation of
random numbers.

Furthermore, since you allow other ha= sh functions to be used as well it
would be good to give guidance about = what the properties of those hash
functions should be. You definitely wa= nt a cryptographic hash function
that provides pre-image resistance, sec= ond pre-image resistance, and
collision resistance.

Given the siz= e of the input and output it is impractical to compute a
table that maps= code_verifies to code_challenges.

This mechanism provides better pr= operties than the "plain" mechanism
since it deals with an attacker that= can see responses as well as
requests (but cannot modify them). It does= not provide any protection
against a true man-in-the-middle attacker.
Ciao
Hannes


___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth


------=_Part_4544891_579265890.1417630207266-- From nobody Wed Dec 3 16:01:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368851ACEB9; Wed, 3 Dec 2014 16:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvzQMaIaiCob; Wed, 3 Dec 2014 16:01:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9769F1ACF69; Wed, 3 Dec 2014 15:59:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 15:59:37 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/N8V22nnJCpCypp_fDb3ZkSKtaFo Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:01:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-02.txt Pages : 11 Date : 2014-12-03 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 3 16:04:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7321ACF70 for ; Wed, 3 Dec 2014 16:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2GvojTUjQw7 for ; Wed, 3 Dec 2014 16:04:50 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2BF1A6F2A for ; Wed, 3 Dec 2014 16:04:50 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7C6452E024 for ; Wed, 3 Dec 2014 19:04:49 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 2EADC52E1B5 for ; Wed, 3 Dec 2014 19:04:48 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Wed, 3 Dec 2014 19:04:47 -0500 From: "Richer, Justin P." To: "" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt Thread-Index: AQHQD1WE7TfAWu1mH0SVOqzin8wav5x+4W2A Date: Thu, 4 Dec 2014 00:04:47 +0000 Message-ID: <1CC6F891-189D-416F-8C34-281997F8A1B7@mitre.org> References: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> In-Reply-To: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <23623283B619A44FB647533DC59B551F@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nWSSTTE57Gvbkzu2MCZWvSAezWM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:04:53 -0000 Small update to the Introspection draft incorporating comments from the pas= t couple days. I haven't put together the IANA considerations section that = will tie the introspection claims to the JWT registry yet, but that's the i= ntent. Please check the diffs, read the new version, and continue to send c= omments to the list. Thanks, -- Justin On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-02.txt > Pages : 11 > Date : 2014-12-03 >=20 > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Dec 4 01:50:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0951A0117 for ; Thu, 4 Dec 2014 01:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwy8nXbqc8Dv for ; Thu, 4 Dec 2014 01:50:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6CE1A0145 for ; Thu, 4 Dec 2014 01:50:03 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSduu-1YNznI3whg-00RZnp; Thu, 04 Dec 2014 10:50:01 +0100 Message-ID: <54802E48.4050509@gmx.net> Date: Thu, 04 Dec 2014 10:50:00 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bill Mills , "oauth@ietf.org" References: <547EF145.5030501@gmx.net> <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> In-Reply-To: <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hk6IKx51xkWbsTD9gisxViIxTg27NKg17" X-Provags-ID: V03:K0:WqFYAO07FuhyF/BLzYwXe9108j3FBqNRFxMdEJ0h49ReEAjEsw2 KOHPIBS/pMSPmP8ZXJdmPdNkt6QqEwZCB78L5LEXr2ja57H2RDxrcCkxUpSBqVMegpTa/QY MORIH4hD1hYL91ma1efoOnu+APFmBv2zVAU/2FcMyyyGmXNNsev+jeR0UfTtSQVJHlDIFl8 c2l8tKiCpa/lTmwhkajBQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uudu9Vs5skmQr9wu1zyAHDcWG6A Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 09:50:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hk6IKx51xkWbsTD9gisxViIxTg27NKg17 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bill, I actually wasn't quite sure what this sentence meant. What I want is that the input to the hash is a 128-bit (or larger) random number. The output will be determined by the hash function and, in case of SHA-256 (as suggested in the document) that output will be 32-octets. Ciao Hannes On 12/03/2014 07:10 PM, Bill Mills wrote: > Quoting from 7.1=20 >=20 > "It is RECOMMENDED that the output of a suitable random number=20 > generatorbe used to create a 32-octet sequence." >=20 > So the spec is already recommending 256 bits of randomness, is that > language not clear enough? >=20 >=20 > On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig > wrote: >=20 >=20 > Hi all, >=20 > I am trying to figure out how to progress the SPOP document and > therefore I read through the discussion about the code challenge, see >=20 > I wanted to share my view about this topic. >=20 > As a summary, the mechanism works as follows: >=20 > C: Compute code_verifier:=3Drand() > C: Compute code_challenge:=3Dfunc(code_verifier) >=20 > (For this discussion, the function func() is SHA-256.) >=20 > C: Send(Authz Request + code_challenge,S) >=20 > S: store code_challenge > S: Send(Authz Grant,C) >=20 > C: Send(Access Token Request || code_verifier, S) >=20 > S: Compute code_challenge':=3Dfunc(code_verifier) > S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >=20 > The document currently does not say how much entropy the random number > has to have. >=20 > The text only talks about the output size and SHA-256 indeed produces a= > 256 bit output. >=20 > Here is the relevant text: >=20 > " > NOTE: code verifier SHOULD have enough entropy to make it impractical= > to guess the value. It is RECOMMENDED that the output of a suitable > random number generator be used to create a 32-octet sequence. > " >=20 > I suggest to recommend at least 128 bits, which is inline with the > recommendations for symmetric ciphers in > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >=20 > I would also suggest to reference RFC 4086 concerning the creation of > random numbers. >=20 > Furthermore, since you allow other hash functions to be used as well it= > would be good to give guidance about what the properties of those hash > functions should be. You definitely want a cryptographic hash function > that provides pre-image resistance, second pre-image resistance, and > collision resistance. >=20 > Given the size of the input and output it is impractical to compute a > table that maps code_verifies to code_challenges. >=20 > This mechanism provides better properties than the "plain" mechanism > since it deals with an attacker that can see responses as well as > requests (but cannot modify them). It does not provide any protection > against a true man-in-the-middle attacker. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --hk6IKx51xkWbsTD9gisxViIxTg27NKg17 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUgC5JAAoJEGhJURNOOiAtIbIIAJNqmAs4ikjYYqBaT4y820uY YOHgGIw8SAHkUcFAcQWX7oZPrJhKaJFaBqpGnP8LPXFIyGwXFkXK5HvX6fXV6AJn +i8axp4DZcomBo3OLCu2NGVCZUYqvuPafLE9KgTE4hO83oFM+OSk2i+EeUvW8wPW tE/Bt0eJUcfIeU3xA5jY8+1UpbDTe8bUdLwiz5Lul8Q7Zx6sPG7v3Gah6igTYnDh Fo/pbQW8mjt2Z+8OI2mdjXSjXuW7HyHjkYWIBF/ZA//EzvElxtLe5evPkzt2gVB+ D4btLr4y2Lq6fQVn/Kt1lgrEbQQQ0r3u9nYcX2JSt8S5W0KAwl5aD6yt3rag2v0= =Vh9S -----END PGP SIGNATURE----- --hk6IKx51xkWbsTD9gisxViIxTg27NKg17-- From nobody Thu Dec 4 02:35:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F11A0171 for ; Thu, 4 Dec 2014 02:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAkquQ1iZEQA for ; Thu, 4 Dec 2014 02:34:56 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC281A0137 for ; Thu, 4 Dec 2014 02:34:55 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so14955685lbj.23 for ; Thu, 04 Dec 2014 02:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=+6SIyGygR307A3nU+x3iaPaGDS+J3H/DCLrAye9wLyI=; b=O9iGQWMZPkiGhTBciiK/n/Po9fJYV4hznAbK6a4gFXOb/okNAEzyo0QevhscgG6tDv T6S7XTxBTeW+4xzJlqWKPReofgTjsz+xMQvjIAtDFM6bY5fXhrnRVaFk7vdn5FKkBp9o FSATnPyQX3OnT4NcfZKL7wW8yX3mWAv/rnucj+VwlmYBs8KTTgoAxVa/76FOn2nHCcDw wzD8xK/QLjE9A8PiXWCr2poHjOFvs0tqXIdyItSo63Zd6pC3eoTiAJXJ/LkBLkXVEWjz JnfqagP1YbXjgCxg8w+9Ug9lIxeDAaoCNS1DHen759u747jny/r71bNnblXMxc8orcLy VnWQ== X-Received: by 10.112.185.68 with SMTP id fa4mr8816800lbc.84.1417689294079; Thu, 04 Dec 2014 02:34:54 -0800 (PST) MIME-Version: 1.0 References: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> <1CC6F891-189D-416F-8C34-281997F8A1B7@mitre.org> From: Thomas Broyer Date: Thu, 04 Dec 2014 10:34:53 +0000 Message-ID: To: "Richer, Justin P." , "" Content-Type: multipart/alternative; boundary=001a11c3caa4c68d870509618275 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sBoJgIex8jg5JAOipwWBxynCNH0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 10:35:01 -0000 --001a11c3caa4c68d870509618275 Content-Type: text/plain; charset=UTF-8 A few notes on the "form" only (not the "content"): HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actually replacing 2617). Specifically, the GET and POST methods are defined in RFC 7231. application/x-www-form-urlencoded refers to RFC 1866; the same media type is said to be defined in HTML 4 in RFC 6749 and RFC 6750; and HTML 5 is now a thing. RFC 7009 uses the media type too but doesn't refer to any other RFC defining it. I think this draft should either refer to RFC 6749, Appendix B < https://tools.ietf.org/html/rfc6749#appendix-B> or to HTML 4 (for consistency with RFC6750) or to HTML 5 < http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html5-20141028.xml> (because HTML 5 supersedes HTML 4). I'd go with HTML 5, given that the IANA registration has been updated in that sense (see http://www.w3.org/TR/2014/REC-html5-20141028/iana.html#application/x-www-form-urlencoded and https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded); but given that RFC 6749, Appendix B algorithm is a subset of the HTML 5 one (enforces the use of UTF-8, ignoring the special key "_charset_"), and for consistency with other OAuth 2.0 specs, then maybe it'd be wiser to use the RFC 6749, Appendix B algorithm. References to sections of other specs form broken links in the rfcmarkup version, because of the name of the other spec appearing between "section N of" and the bracketed reference. For example, in section 2.3, "section 5.2 of OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]" There's a dangling "These parameters" in section 2.1. This lacks at least a verb and a colon ("These parameters are:"). A last note on the content itself: +1, I don't think I have any further comment to make. On Thu Dec 04 2014 at 01:05:07 Richer, Justin P. wrote: > Small update to the Introspection draft incorporating comments from the > past couple days. I haven't put together the IANA considerations section > that will tie the introspection claims to the JWT registry yet, but that's > the intent. Please check the diffs, read the new version, and continue to > send comments to the list. > > Thanks, > -- Justin > > On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > > > Title : OAuth 2.0 Token Introspection > > Author : Justin Richer > > Filename : draft-ietf-oauth-introspection-02.txt > > Pages : 11 > > Date : 2014-12-03 > > > > Abstract: > > This specification defines a method for a protected resource to query > > an OAuth 2.0 authorization server to determine the active state of an > > OAuth 2.0 token and to determine meta-information about this token. > > OAuth 2.0 deployments can use this method to convey information about > > the authorization context of the token from the authorization server > > to the protected resource. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-oauth-introspection-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-02 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --001a11c3caa4c68d870509618275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A few notes on the "form" only (not the "content"):
=
HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 72= 36 actually replacing 2617). Specifically, the GET and POST methods are def= ined in RFC 7231.

application/x-www-form-urlencoded refe= rs to RFC 1866; the same media type is said to be defined in HTML 4 in RFC = 6749 and RFC 6750; and HTML 5 is now a thing. RFC 7009 uses the media type = too but doesn't refer to any other RFC defining it.
I think t= his draft should either refer to RFC 6749, Appendix B <https://tools.ietf.org/html/rfc67= 49#appendix-B> or to HTML 4 (for consistency with RFC6750) or to HTM= L 5 <http://xml2rfc.ietf.org/public/rfc/bibxml4/referen= ce.W3C.REC-html5-20141028.xml> (because HTML 5 supersedes HTML 4).
I'd go with HTML 5, given that the IANA registration has been = updated in that sense (see http://www.w3.org/TR/2= 014/REC-html5-20141028/iana.html#application/x-www-form-urlencoded and = https://www.iana.org/assignments/media-types/application/x-= www-form-urlencoded); but given that RFC 6749, Appendix B algorithm is = a subset of the HTML 5 one (enforces the use of UTF-8, ignoring the special= key "_charset_"), and for consistency with other OAuth 2.0 specs= , then maybe it'd be wiser to use the RFC 6749, Appendix B algorithm.
References to sections of other specs form broken links in the rfcmar= kup version, because of the name of the other spec appearing between "= section N of" and the bracketed reference. For example, in section 2.3= , "section 5.2 of OAuth 2.0 [RFC6749]" should instead read "= section 5.2 of [RFC6749]"

There's a dangl= ing "These parameters" in section 2.1. This lacks at least a verb= and a colon ("These parameters are:").

= A last note on the content itself:=C2=A0+1, I don't think I have any fu= rther comment to make.

On Thu Dec 04 2014= at 01:05:07 Richer, Justin P. <jricher@mitre.org> wrote:
Small update to the Introspection draft incorporating comments from = the past couple days. I haven't put together the IANA considerations se= ction that will tie the introspection claims to the JWT registry yet, but t= hat's the intent. Please check the diffs, read the new version, and con= tinue to send comments to the list.

Thanks,
=C2=A0-- Justin

On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Token Introspection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-introspection-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-12-03
>
> Abstract:
>=C2=A0 =C2=A0This specification defines a method for a protected resour= ce to query
>=C2=A0 =C2=A0an OAuth 2.0 authorization server to determine the active = state of an
>=C2=A0 =C2=A0OAuth 2.0 token and to determine meta-information about th= is token.
>=C2=A0 =C2=A0OAuth 2.0 deployments can use this method to convey inform= ation about
>=C2=A0 =C2=A0the authorization context of the token from the authorizat= ion server
>=C2=A0 =C2=A0to the protected resource.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dra= ft-ietf-oauth-introspection/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oa= uth-introspection-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-oauth-introspection-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a11c3caa4c68d870509618275-- From nobody Thu Dec 4 02:56:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BAA1A0211 for ; Thu, 4 Dec 2014 02:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc3MhO2QZOmH for ; Thu, 4 Dec 2014 02:56:35 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A021D1A01F6 for ; Thu, 4 Dec 2014 02:56:34 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so22071855wgh.23 for ; Thu, 04 Dec 2014 02:56:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ingjTSFP99YHVYtTyPohWUr36KZqBQS4AaSoCKe48oA=; b=Uu0z88RBhQpD/4WEDN+IVXyxi++rVRfrLzyIJ2oL9R2KYXkzuBp4vCFxcR8vzTmpe0 veQrE4J6lMoQOHtLMt0fYjgZiGQDXXFgh5r6+mm0CfKPxI/FFaXQglh7cG8Suw4QAURZ yW3z/aMaTowxRqB6o+M4/btbARLWB7kU0dUAebnNlrcuT6AScxxyXuMWmUTBTssgrZ+v u5UruiqD9sYlMukLWVI5fWk2vVcHB2cJugc7ZoVA6UzcIZI3JcSZfAe8mn1IhIlDkVX3 JwYYBrxw/k3rPtCdO1BYZ7hjOFnt4cOOv2l/ZoJBFA3zE3xRqBvO9UVqDHJ3o1B1y4wZ OedA== X-Gm-Message-State: ALoCoQmsaIonBxNDV5oVMbX4CRs68RIcej6JuHBhOvfGMZLcWZ4GKhBbz5ahST3gs1Dez5CCOfnn X-Received: by 10.180.101.200 with SMTP id fi8mr108428871wib.77.1417690593237; Thu, 04 Dec 2014 02:56:33 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id d16sm32522815wib.4.2014.12.04.02.56.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 02:56:32 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A9B28722-AE77-46E5-8439-8A1DE7BF2C82"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <54802E48.4050509@gmx.net> Date: Thu, 4 Dec 2014 07:56:30 -0300 Message-Id: References: <547EF145.5030501@gmx.net> <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> <54802E48.4050509@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_xKfoSJJBl9FSblJsRhAH9HRvdc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 10:56:36 -0000 --Apple-Mail=_A9B28722-AE77-46E5-8439-8A1DE7BF2C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hannes, 7.1 is talking about the generation of the code verifier you are = thinking of the code challenge, that is the output of the hash.=20 The verifier is the value that is hashed 32 octets is 256bits, so you = are recommending half the entropy already recommended.=20 Also see the text in 4.1=20 NOTE: code verifier SHOULD have enough entropy to make it impractical to guess the value. It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence. The Octet sequence is then BASE64URL encoded to produce a 42-octet URL safe string to use as the code verifier. If "It is RECOMMENDED that the output of a suitable random number = generator be used to create a 32-octet sequence." is not clear then we = need to work on that. John B. > On Dec 4, 2014, at 6:50 AM, Hannes Tschofenig = wrote: >=20 > Hi Bill, >=20 > I actually wasn't quite sure what this sentence meant. >=20 > What I want is that the input to the hash is a 128-bit (or larger) > random number. The output will be determined by the hash function and, > in case of SHA-256 (as suggested in the document) that output will be > 32-octets. >=20 > Ciao > Hannes >=20 >=20 > On 12/03/2014 07:10 PM, Bill Mills wrote: >> Quoting from 7.1=20 >>=20 >> "It is RECOMMENDED that the output of a suitable random number=20 >> generatorbe used to create a 32-octet sequence." >>=20 >> So the spec is already recommending 256 bits of randomness, is that >> language not clear enough? >>=20 >>=20 >> On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig >> wrote: >>=20 >>=20 >> Hi all, >>=20 >> I am trying to figure out how to progress the SPOP document and >> therefore I read through the discussion about the code challenge, see >>=20 >> I wanted to share my view about this topic. >>=20 >> As a summary, the mechanism works as follows: >>=20 >> C: Compute code_verifier:=3Drand() >> C: Compute code_challenge:=3Dfunc(code_verifier) >>=20 >> (For this discussion, the function func() is SHA-256.) >>=20 >> C: Send(Authz Request + code_challenge,S) >>=20 >> S: store code_challenge >> S: Send(Authz Grant,C) >>=20 >> C: Send(Access Token Request || code_verifier, S) >>=20 >> S: Compute code_challenge':=3Dfunc(code_verifier) >> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >>=20 >> The document currently does not say how much entropy the random = number >> has to have. >>=20 >> The text only talks about the output size and SHA-256 indeed produces = a >> 256 bit output. >>=20 >> Here is the relevant text: >>=20 >> " >> NOTE: code verifier SHOULD have enough entropy to make it = impractical >> to guess the value. It is RECOMMENDED that the output of a suitable >> random number generator be used to create a 32-octet sequence. >> " >>=20 >> I suggest to recommend at least 128 bits, which is inline with the >> recommendations for symmetric ciphers in >> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>=20 >> I would also suggest to reference RFC 4086 concerning the creation of >> random numbers. >>=20 >> Furthermore, since you allow other hash functions to be used as well = it >> would be good to give guidance about what the properties of those = hash >> functions should be. You definitely want a cryptographic hash = function >> that provides pre-image resistance, second pre-image resistance, and >> collision resistance. >>=20 >> Given the size of the input and output it is impractical to compute a >> table that maps code_verifies to code_challenges. >>=20 >> This mechanism provides better properties than the "plain" mechanism >> since it deals with an attacker that can see responses as well as >> requests (but cannot modify them). It does not provide any protection >> against a true man-in-the-middle attacker. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A9B28722-AE77-46E5-8439-8A1DE7BF2C82 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDQxMDU2MzFaMCMGCSqGSIb3DQEJBDEWBBRGNBdZm5F1EcA9V3Y1PkED kzW+TDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA34MJOUv90/75aV6+0UpQ2dJxvObyAWx/irlE6MP5d/mxgV1zeBH6G gv3jxJg8BQL6CcXy2M02xSzMBGyfKt78QR92aJPyXN7MBv0Wabv8EVfS29N5XaV6QnKNpIJ09BSE 6fKyKBiD7K5UNUmb3VRd/QMJ6JYq/m7owBeTZLMHjGL6Xaq6bh3SWHbQ0dJ3RpxopBeRYBmyL1QW jl1bhqtopWBAFUWF4+yzYiSR1KaaK0O70Dk4AgU4orugBnYW9uq0GdnT5ApdKc6Vp7A/qq0f84Lu o3/TptSp8V4H99IWpc7YugLk/CgqCecCxxRiXN1pUH2FTfYTeeYXLg6zzlBJAAAAAAAA --Apple-Mail=_A9B28722-AE77-46E5-8439-8A1DE7BF2C82-- From nobody Thu Dec 4 06:07:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1221A1ADF for ; Thu, 4 Dec 2014 06:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwxByvsj2sVY for ; Thu, 4 Dec 2014 06:07:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994E01AD3A5 for ; Thu, 4 Dec 2014 06:07:10 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWwp6-1YSLhQ0hqm-00Vv7o; Thu, 04 Dec 2014 15:07:08 +0100 Message-ID: <54806A8A.207@gmx.net> Date: Thu, 04 Dec 2014 15:07:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <547EF145.5030501@gmx.net> <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> <54802E48.4050509@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xn05jKxmKoWuNofwxRpAARgP4fq2U3QNi" X-Provags-ID: V03:K0:HFPzXQbySnJstCRuOdupHT8CiO6ktEHTmfCHPdJ/WWJJM+s6LlN 6xfX/0JtcMxCVf6H5/s0i8yTj/jk9h6rSeo77fS7f66BE5B2F7NxST6A0WmuZYzK62t40+Y +IDqy52tav8Va/bXjUtou/YLPML118qWOOwA4S+fFhAq429nCLl3tiy8GVC0TgQZMXnYoB4 sbEE4eGKm5gqQTnhCsv5g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Vbar_HiOgcLfQtxqTFu99dZGsKY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 14:07:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xn05jKxmKoWuNofwxRpAARgP4fq2U3QNi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for pointing me to Section 7.1. To avoid this SHOULD and RECOMMENDED language I would suggest that you say that "The code_verifier value MUST have randomly generated with at least 128-bits of entropy. Guidelines for producing high quality random numbers can be found in RFC 4086." 256-bit is nice as well but far exceeds what is currently recommended and might actually be difficult on certain types of devices (I am thinking more about the IoT space here). On 12/04/2014 11:56 AM, John Bradley wrote: > Hannes, >=20 > 7.1 is talking about the generation of the code verifier you are thinki= ng of the code challenge, that is the output of the hash.=20 >=20 > The verifier is the value that is hashed 32 octets is 256bits, so you = are recommending half the entropy already recommended.=20 >=20 > Also see the text in 4.1=20 > NOTE: code verifier SHOULD have enough entropy to make it impractical > to guess the value. It is RECOMMENDED that the output of a suitable= > random number generator be used to create a 32-octet sequence. The > Octet sequence is then BASE64URL encoded to produce a 42-octet URL > safe string to use as the code verifier. >=20 > If "It is RECOMMENDED that the output of a suitable random number gener= ator be used to create a 32-octet sequence." is not clear then we need to= work on that. >=20 > John B. >=20 >> On Dec 4, 2014, at 6:50 AM, Hannes Tschofenig wrote: >> >> Hi Bill, >> >> I actually wasn't quite sure what this sentence meant. >> >> What I want is that the input to the hash is a 128-bit (or larger) >> random number. The output will be determined by the hash function and,= >> in case of SHA-256 (as suggested in the document) that output will be >> 32-octets. >> >> Ciao >> Hannes >> >> >> On 12/03/2014 07:10 PM, Bill Mills wrote: >>> Quoting from 7.1=20 >>> >>> "It is RECOMMENDED that the output of a suitable random number=20 >>> generatorbe used to create a 32-octet sequence." >>> >>> So the spec is already recommending 256 bits of randomness, is that >>> language not clear enough? >>> >>> >>> On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig >>> wrote: >>> >>> >>> Hi all, >>> >>> I am trying to figure out how to progress the SPOP document and >>> therefore I read through the discussion about the code challenge, see= >>> >>> I wanted to share my view about this topic. >>> >>> As a summary, the mechanism works as follows: >>> >>> C: Compute code_verifier:=3Drand() >>> C: Compute code_challenge:=3Dfunc(code_verifier) >>> >>> (For this discussion, the function func() is SHA-256.) >>> >>> C: Send(Authz Request + code_challenge,S) >>> >>> S: store code_challenge >>> S: Send(Authz Grant,C) >>> >>> C: Send(Access Token Request || code_verifier, S) >>> >>> S: Compute code_challenge':=3Dfunc(code_verifier) >>> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >>> >>> The document currently does not say how much entropy the random numbe= r >>> has to have. >>> >>> The text only talks about the output size and SHA-256 indeed produces= a >>> 256 bit output. >>> >>> Here is the relevant text: >>> >>> " >>> NOTE: code verifier SHOULD have enough entropy to make it impractica= l >>> to guess the value. It is RECOMMENDED that the output of a suitable= >>> random number generator be used to create a 32-octet sequence. >>> " >>> >>> I suggest to recommend at least 128 bits, which is inline with the >>> recommendations for symmetric ciphers in >>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>> >>> I would also suggest to reference RFC 4086 concerning the creation of= >>> random numbers. >>> >>> Furthermore, since you allow other hash functions to be used as well = it >>> would be good to give guidance about what the properties of those has= h >>> functions should be. You definitely want a cryptographic hash functio= n >>> that provides pre-image resistance, second pre-image resistance, and >>> collision resistance. >>> >>> Given the size of the input and output it is impractical to compute a= >>> table that maps code_verifies to code_challenges. >>> >>> This mechanism provides better properties than the "plain" mechanism >>> since it deals with an attacker that can see responses as well as >>> requests (but cannot modify them). It does not provide any protection= >>> against a true man-in-the-middle attacker. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> 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 --xn05jKxmKoWuNofwxRpAARgP4fq2U3QNi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUgGqLAAoJEGhJURNOOiAt2ewH/RJuoXPffYehnc2BsnI2sQFS j735kLCk3NZ9ykb5Sajm/DGMf6V+7h5k91PdT9KGqEy3CyRkzavD7WzW2TMdkAzm 8irW8DOf5UCuCbhIROfKF1ZgZJaprgNxBz7LQqN7LpQbfyWV9h8IK8CLD9Qlbt1P vYQo2W7lHZQtkEZID6HuPzcy+oJF54jhoiWSjo57VcVuq/srV0fVgSkPOmIgezWK 0UmgAIuH27rYdWad4chGKpf/r7ZyvYCeA9+Hvc4/MjN7cDgJimgAzi5f0WFMOKdm NkiIYHwvskIF6yylj1Ovb7TmhVuETA8cqpGzb4Y3Hk9TxPpgGG+21qJcrZBK6Rw= =FBQS -----END PGP SIGNATURE----- --xn05jKxmKoWuNofwxRpAARgP4fq2U3QNi-- From nobody Thu Dec 4 07:05:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9E1AD412 for ; Thu, 4 Dec 2014 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZM0kgC_vbGJ for ; Thu, 4 Dec 2014 07:04:52 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id F214C1AD410 for ; Thu, 4 Dec 2014 07:04:45 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C46952E1DE; Thu, 4 Dec 2014 10:04:45 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 6D48C33205B; Thu, 4 Dec 2014 10:04:45 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Thu, 4 Dec 2014 10:04:44 -0500 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt Thread-Index: AQHQD1WE7TfAWu1mH0SVOqzin8wav5x+4W2AgABbzJ2AAJ/EAA== Date: Thu, 4 Dec 2014 15:04:44 +0000 Message-ID: <0A1A0CA9-C342-4BA1-82AC-A4D455A7FE16@mitre.org> References: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> <1CC6F891-189D-416F-8C34-281997F8A1B7@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uTwxicG8DvH4m99NRjHbsiCHmBY Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 15:05:10 -0000 --_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 4, 2014, at 5:34 AM, Thomas Broyer > wrote: A few notes on the "form" only (not the "content"): HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actua= lly replacing 2617). Specifically, the GET and POST methods are defined in = RFC 7231. Thanks, will update the reference there. application/x-www-form-urlencoded refers to RFC 1866; the same media type i= s said to be defined in HTML 4 in RFC 6749 and RFC 6750; and HTML 5 is now = a thing. RFC 7009 uses the media type too but doesn't refer to any other RF= C defining it. I think this draft should either refer to RFC 6749, Appendix B or to HTML 4 (for consistency with RFC= 6750) or to HTML 5 (because HTML 5 supersedes HTML 4). I'd go with HTML 5, given that the IANA registration has been updated in th= at sense (see http://www.w3.org/TR/2014/REC-html5-20141028/iana.html#applic= ation/x-www-form-urlencoded and https://www.iana.org/assignments/media-type= s/application/x-www-form-urlencoded); but given that RFC 6749, Appendix B a= lgorithm is a subset of the HTML 5 one (enforces the use of UTF-8, ignoring= the special key "_charset_"), and for consistency with other OAuth 2.0 spe= cs, then maybe it'd be wiser to use the RFC 6749, Appendix B algorithm. I'll just go with HTML5 as that's the canonical spec for this mime type now= . No need to make it complicated, and any updates of 6749/6750 will likely = do the same I would imagine. References to sections of other specs form broken links in the rfcmarkup ve= rsion, because of the name of the other spec appearing between "section N o= f" and the bracketed reference. For example, in section 2.3, "section 5.2 o= f OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]" I've seen this happen before, and I think it's a tool artifact. There's a dangling "These parameters" in section 2.1. This lacks at least a= verb and a colon ("These parameters are:"). Thanks, good catch! I think I was in the middle of rewriting that part when= I got distracted. -- Justin A last note on the content itself: +1, I don't think I have any further com= ment to make. On Thu Dec 04 2014 at 01:05:07 Richer, Justin P. > wrote: Small update to the Introspection draft incorporating comments from the pas= t couple days. I haven't put together the IANA considerations section that = will tie the introspection claims to the JWT registry yet, but that's the i= ntent. Please check the diffs, read the new version, and continue to send c= omments to the list. Thanks, -- Justin On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-02.txt > Pages : 11 > Date : 2014-12-03 > > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-02 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <986D59257FF4E343885AA035D38A39F4@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
On Dec 4, 2014, at 5:34 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

A few notes on the "form" only (not the= "content"):

HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actua= lly replacing 2617). Specifically, the GET and POST methods are defined in = RFC 7231.

Thanks, will update the reference there.


application/x-www-form-urlencoded refers to RFC 1866; the same media t= ype is said to be defined in HTML 4 in RFC 6749 and RFC 6750; and HTML 5 is= now a thing. RFC 7009 uses the media type too but doesn't refer to any oth= er RFC defining it.
I think this draft should either refer to RFC 6749, Appendix B <https://tools.ietf.= org/html/rfc6749#appendix-B> or to HTML 4 (for consistency with RFC6= 750) or to HTML 5 <http://xml2rfc.ietf.org/public/rfc/b= ibxml4/reference.W3C.REC-html5-20141028.xml> (because HTML 5 supersedes HTML 4).
I'd go with HTML 5, given that the IANA registration has been updated = in that sense (see http://www.w3.org/TR/2014/REC-html5-20141028/iana.html#application/x-www-fo= rm-urlencoded and https://www.iana.org/assignments/media-types/application/x-www-form-urlenco= ded); but given that RFC 6749, Appendix B algorithm is a subset of the = HTML 5 one (enforces the use of UTF-8, ignoring the special key "_char= set_"), and for consistency with other OAuth 2.0 specs, then maybe it'd be wiser to use the RFC 6749, Appendix B = algorithm.

I'll just go with HTML5 as that's the canonical spec for this mime typ= e now. No need to make it complicated, and any updates of 6749/6750 will li= kely do the same I would imagine.


References to sections of other specs form broken links in the rfcmarkup ve= rsion, because of the name of the other spec appearing between "sectio= n N of" and the bracketed reference. For example, in section 2.3, &quo= t;section 5.2 of OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]"

I've seen this happen before, and I think it's a tool artifact. <= /div>

There's a dangling "These parameters" in section 2.1. This l= acks at least a verb and a colon ("These parameters are:").

Thanks, good catch! I think I was in the middle of rewriting that part= when I got distracted.

 -- Justin


A last note on the content itself: +1, I don't think I have a= ny further comment to make.

On Thu Dec 04 2014 at 01:05:07 Richer, Justin P.= <jricher@mitre.o= rg> wrote:
Small update to the Introspection draft incorporating comments from the pas= t couple days. I haven't put together the IANA considerations section that = will tie the introspection claims to the JWT registry yet, but that's the i= ntent. Please check the diffs, read the new version, and continue to send comments to the list.

Thanks,
 -- Justin

On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>        Title          &nb= sp;: OAuth 2.0 Token Introspection
>        Author          : = Justin Richer
>       Filename        : draft-= ietf-oauth-introspection-02.txt
>       Pages          &nbs= p;: 11
>       Date           = ; : 2014-12-03
>
> Abstract:
>   This specification defines a method for a protected resour= ce to query
>   an OAuth 2.0 authorization server to determine the active = state of an
>   OAuth 2.0 token and to determine meta-information about th= is token.
>   OAuth 2.0 deployments can use this method to convey inform= ation about
>   the authorization context of the token from the authorizat= ion server
>   to the protected resource.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-intr= ospection/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-introspect= ion-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-in= trospection-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

--_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_-- From nobody Thu Dec 4 07:15:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308941A0183 for ; Thu, 4 Dec 2014 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ9FvWAIJutn for ; Thu, 4 Dec 2014 07:15:03 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836931AD40E for ; Thu, 4 Dec 2014 07:14:58 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id a1so14641348wgh.19 for ; Thu, 04 Dec 2014 07:14:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Z50YLSeTBJeR+/BPDTDGxGZkUNQJjWnvxaFYWPnAWz8=; b=YtEHzmAjagFrpw1KLivPDLmxNs5nCDngHfy4obBNspu7fmRsEHu3dzSZyJZu0cXFRl ndGlz8PdJ7ztwg52O/+EcME9SMnifCsqF3pntxyaH6Keus4S1vA3Vo2h1CsZyTpkyyMi f33yOfb04WANfLB7BF901A+EM+zfKGbfbkx6d+tOKxmSe8d3m/VMvdFfsNSjyvvr1O+o BegVTat45PukdIwQzFyt8yjyZFFefdj25tg0WhJIQn8Vzv5qY8SosDXVzaW6MH/1ncm7 CLUC5OfZxDJDOoHcN9jigYiimY6PMEJywlZ8vjULWPEWM10xoB4x/nrZoyuzsd9OmouJ xX/g== X-Gm-Message-State: ALoCoQlQHaGe5I2QmpPzZYMATeODpiAwVB5kHXxoAQEPiGUqhVZN+g5cPfxIBiY4Nnhfe2Y0Wt97 X-Received: by 10.195.11.38 with SMTP id ef6mr16681306wjd.68.1417706097086; Thu, 04 Dec 2014 07:14:57 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id ry19sm40881433wjb.3.2014.12.04.07.14.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:14:55 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_0F4C488D-6DD5-4840-83D1-0A3EDB823CFA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <54806A8A.207@gmx.net> Date: Thu, 4 Dec 2014 12:14:52 -0300 Message-Id: References: <547EF145.5030501@gmx.net> <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> <54802E48.4050509@gmx.net> <54806A8A.207@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W4QAic0RN0e20r-a9OXiy1gk1wM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 15:15:05 -0000 --Apple-Mail=_0F4C488D-6DD5-4840-83D1-0A3EDB823CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 How about 126bits/21 octets a must and 256bits/42 octets a SHOULD on = platforms that can support it? We are talking about prng output, on a phone or computer there is not = going to be a performance difference. You have a point for very small devices.=20 People are going to be using system functions more likely than writing = there own prng (thank god). We can mention RFC 4086 but it may send people in the wrong direction. John B. > On Dec 4, 2014, at 11:07 AM, Hannes Tschofenig = wrote: >=20 > Thanks for pointing me to Section 7.1. >=20 > To avoid this SHOULD and RECOMMENDED language I would suggest that you > say that "The code_verifier value MUST have randomly generated with at > least 128-bits of entropy. Guidelines for producing high quality = random > numbers can be found in RFC 4086." >=20 > 256-bit is nice as well but far exceeds what is currently recommended > and might actually be difficult on certain types of devices (I am > thinking more about the IoT space here). >=20 > On 12/04/2014 11:56 AM, John Bradley wrote: >> Hannes, >>=20 >> 7.1 is talking about the generation of the code verifier you are = thinking of the code challenge, that is the output of the hash.=20 >>=20 >> The verifier is the value that is hashed 32 octets is 256bits, so = you are recommending half the entropy already recommended.=20 >>=20 >> Also see the text in 4.1=20 >> NOTE: code verifier SHOULD have enough entropy to make it impractical >> to guess the value. It is RECOMMENDED that the output of a = suitable >> random number generator be used to create a 32-octet sequence. The >> Octet sequence is then BASE64URL encoded to produce a 42-octet URL >> safe string to use as the code verifier. >>=20 >> If "It is RECOMMENDED that the output of a suitable random number = generator be used to create a 32-octet sequence." is not clear then we = need to work on that. >>=20 >> John B. >>=20 >>> On Dec 4, 2014, at 6:50 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi Bill, >>>=20 >>> I actually wasn't quite sure what this sentence meant. >>>=20 >>> What I want is that the input to the hash is a 128-bit (or larger) >>> random number. The output will be determined by the hash function = and, >>> in case of SHA-256 (as suggested in the document) that output will = be >>> 32-octets. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On 12/03/2014 07:10 PM, Bill Mills wrote: >>>> Quoting from 7.1=20 >>>>=20 >>>> "It is RECOMMENDED that the output of a suitable random number=20 >>>> generatorbe used to create a 32-octet sequence." >>>>=20 >>>> So the spec is already recommending 256 bits of randomness, is that >>>> language not clear enough? >>>>=20 >>>>=20 >>>> On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig >>>> wrote: >>>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> I am trying to figure out how to progress the SPOP document and >>>> therefore I read through the discussion about the code challenge, = see >>>>=20 >>>> I wanted to share my view about this topic. >>>>=20 >>>> As a summary, the mechanism works as follows: >>>>=20 >>>> C: Compute code_verifier:=3Drand() >>>> C: Compute code_challenge:=3Dfunc(code_verifier) >>>>=20 >>>> (For this discussion, the function func() is SHA-256.) >>>>=20 >>>> C: Send(Authz Request + code_challenge,S) >>>>=20 >>>> S: store code_challenge >>>> S: Send(Authz Grant,C) >>>>=20 >>>> C: Send(Access Token Request || code_verifier, S) >>>>=20 >>>> S: Compute code_challenge':=3Dfunc(code_verifier) >>>> S: IF (code_challenge'=3D=3Dcode_challenge) THEN SUCCESS ELSE FAIL. >>>>=20 >>>> The document currently does not say how much entropy the random = number >>>> has to have. >>>>=20 >>>> The text only talks about the output size and SHA-256 indeed = produces a >>>> 256 bit output. >>>>=20 >>>> Here is the relevant text: >>>>=20 >>>> " >>>> NOTE: code verifier SHOULD have enough entropy to make it = impractical >>>> to guess the value. It is RECOMMENDED that the output of a = suitable >>>> random number generator be used to create a 32-octet sequence. >>>> " >>>>=20 >>>> I suggest to recommend at least 128 bits, which is inline with the >>>> recommendations for symmetric ciphers in >>>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 >>>>=20 >>>> I would also suggest to reference RFC 4086 concerning the creation = of >>>> random numbers. >>>>=20 >>>> Furthermore, since you allow other hash functions to be used as = well it >>>> would be good to give guidance about what the properties of those = hash >>>> functions should be. You definitely want a cryptographic hash = function >>>> that provides pre-image resistance, second pre-image resistance, = and >>>> collision resistance. >>>>=20 >>>> Given the size of the input and output it is impractical to compute = a >>>> table that maps code_verifies to code_challenges. >>>>=20 >>>> This mechanism provides better properties than the "plain" = mechanism >>>> since it deals with an attacker that can see responses as well as >>>> requests (but cannot modify them). It does not provide any = protection >>>> against a true man-in-the-middle attacker. >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_0F4C488D-6DD5-4840-83D1-0A3EDB823CFA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDQxNTE0NTNaMCMGCSqGSIb3DQEJBDEWBBRHWKCmVaSjcEQ5390pxi44 4WlPpjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCAnK1HZbt5tD8SSqch0aiJ07Y8OkGe/78IQ29N5V4oDroS9NdiwiDr KHOFVEMAD9+ziHWTwDq6Cw8IXNCTTTLmBjCTPh0iEKhYVxLxH4LiAdW8Ay6j+wj14Sz9lWN/tMUf U92DmOcOtvupWao59R9qj5hKM+sklPd3gvzuwPdKm3AbWcYU0qm0G0/ICtMuQEfG42ZBf37fkL1w bRPbDlN40QgCwrpCWfT4sMQdUlU3rE2aOYOGYLCKCpqVFTfh7quD3SgZBwUe9giHlNfUrvN7Zg5f A6S3RIyz7PPwxrH8P1bjzXQCUZX2hRw+yCqnucqo4TE/Z9hD1o29VP6xw3OhAAAAAAAA --Apple-Mail=_0F4C488D-6DD5-4840-83D1-0A3EDB823CFA-- From nobody Fri Dec 5 11:17:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E251ACE9C for ; Fri, 5 Dec 2014 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pONd5T_kJYf for ; Fri, 5 Dec 2014 11:17:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5F81A1E0B for ; Fri, 5 Dec 2014 11:17:10 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJngW-1Xy4Iq3cAO-001D3v for ; Fri, 05 Dec 2014 20:17:09 +0100 Message-ID: <548204B3.5050903@gmx.net> Date: Fri, 05 Dec 2014 20:17:07 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <5481E0A7.2090604@cs.tcd.ie> In-Reply-To: <5481E0A7.2090604@cs.tcd.ie> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <5481E0A7.2090604@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AsDCnQ7UdaQdefhcDJtuMthGGM9M01EgN" X-Provags-ID: V03:K0:yU0bRFqwczX9vQ6io3WuBN1zuFmBxXpqci2QrK8naIJQmvmFn7R MJ9/D0ahPm/D5XAsEUGU1CJxHL8Y0fJkah3UvDKHVNYXwBRxfq8quGtjxNY7Af5ZyTBRBYd /A+waeWTqNfmf7qKDcWKgWw2/9wm0H4YZ9fD8sFGIBA1C4ExdMRrvXNczqSto8DZ6gZiTwg eKTA1dPqrINZvH0Mzxi9A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bTiVzMpAhMTzECMbY-WU6gjnPL8 Subject: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 19:17:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AsDCnQ7UdaQdefhcDJtuMthGGM9M01EgN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable -------- Forwarded Message -------- Subject: [websec] unbearable - new mailing list to discuss better than bearer tokens... Date: Fri, 05 Dec 2014 16:43:19 +0000 From: Stephen Farrell Reply-To: Stephen Farrell To: saag@ietf.org , websec , uta@ietf.org , ietf-http-wg@w3.org Group , http-auth@ietf.org Hiya, Following up on the presentation at IETF-91 on this topic, [1] we've created a new list [2] for moving that along. The list description is: "This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks." If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers, S. PS: Please don't reply-all to this, join the new list, wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec --AsDCnQ7UdaQdefhcDJtuMthGGM9M01EgN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUggSzAAoJEGhJURNOOiAteqkH/RNhoki0tLkJq99k7e7rnlI6 ChY6wQqzSqlDjON4Zri6vvBmEOJu95vKVc1YK4a9T1uVpy+W0AaRlkSd14a2UfGT SXZYDZCAFRtHUE8n6QB9kR0J8GnAkh8hoqJ/C0tp/zHk+Mt/zQe3VppW95Bhnlia bMnUq/qd6LqJdEi7PSjRW8L985Y6OyZ8vP49LdGD20vuoJmXBqZIqq1Y+qE1KLqI 0KTBl0CPxI+t2NKMRjGzN5JIdQBMMPjPhlQ5kSQsqTxo65Tvdb46cLzRU9i0P2Kw KbG4NpXeEcoWJ8HmZk+X/DXX1GhimOkT9Yp6YT6lt8UgJTJkc1C5NVn17MR0Nbg= =tSDA -----END PGP SIGNATURE----- --AsDCnQ7UdaQdefhcDJtuMthGGM9M01EgN-- From nobody Fri Dec 5 14:33:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DEF1A6F84 for ; Fri, 5 Dec 2014 14:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofyPeZcfj1LQ for ; Fri, 5 Dec 2014 14:33:39 -0800 (PST) Received: from BLU004-OMC1S19.hotmail.com (blu004-omc1s19.hotmail.com [65.55.116.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A1A1A1EF6 for ; Fri, 5 Dec 2014 14:33:39 -0800 (PST) Received: from BLU406-EAS156 ([65.55.116.8]) by BLU004-OMC1S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 5 Dec 2014 14:33:38 -0800 X-TMN: [FbaEKLIR8KTMIJXkZnCItbDAWF5Q4eV1] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_e10740d1-5516-498c-862b-d4ed4d78bc0d_" MIME-Version: 1.0 X-Client-ID: 1004 X-Mailer: BlackBerry Email (10.2.1.3442) Date: Sat, 6 Dec 2014 05:33:35 +0700 From: Panca Agus Ananda To: , X-OriginalArrivalTime: 05 Dec 2014 22:33:38.0089 (UTC) FILETIME=[83532190:01D010DB] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/N9fU9k9TKwOJkUJvtnlVWSFnVYk Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 38 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 22:33:41 -0000 --_e10740d1-5516-498c-862b-d4ed4d78bc0d_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Panca70 box.com Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Sabtu=2C 6 Desember 2014 03.00 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 74=2C Issue 38 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... (Hannes Tschofenig) ---------------------------------------------------------------------- Message: 1 Date: Fri=2C 05 Dec 2014 20:17:07 +0100 From: Hannes Tschofenig To: "oauth@ietf.org" Subject: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... Message-ID: <548204B3.5050903@gmx.net> Content-Type: text/plain=3B charset=3D"windows-1252" -------- Forwarded Message -------- Subject: [websec] unbearable - new mailing list to discuss better than bearer tokens... Date: Fri=2C 05 Dec 2014 16:43:19 +0000 From: Stephen Farrell Reply-To: Stephen Farrell To: saag@ietf.org =2C websec =2C uta@ietf.org =2C ietf-http-wg@w3.org Group =2C http-auth@ietf.org Hiya=2C Following up on the presentation at IETF-91 on this topic=2C [1] we've created a new list [2] for moving that along. The list description is: "This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies=2C OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks." If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers=2C S. PS: Please don't reply-all to this=2C join the new list=2C wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: OpenPGP digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 74=2C Issue 38 ************************************* --_e10740d1-5516-498c-862b-d4ed4d78bc0d_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Panca70 box.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Sabtu=2C 6 Desember 2014 03.00
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 74=2C Issue 38

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Fwd: [websec] unbearable - new mailing list to discuss = better
 =3B =3B =3B =3B =3B than bearer tokens... (Hannes Tsch= ofenig)


----------------------------------------------------------------------

Message: 1
Date: Fri=2C 05 Dec 2014 20:17:07 +=3B0100
From: Hannes Tschofenig <=3Bhannes.tschofenig@gmx.net>=3B
To: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to
 =3B =3B =3B =3B =3B =3B =3B discuss better tha= n bearer tokens...
Message-ID: <=3B548204B3.5050903@gmx.net>=3B
Content-Type: text/plain=3B charset=3D"=3Bwindows-1252"=3B




-------- Forwarded Message --------
Subject: [websec] unbearable - new mailing list to discuss better than
bearer tokens...
Date: Fri=2C 05 Dec 2014 16:43:19 +=3B0000
From: Stephen Farrell <=3Bstephen.farrell@cs.tcd.ie>=3B
Reply-To: Stephen Farrell <=3BStephen.Farrell@cs.tcd.ie>=3B
To: saag@ietf.org <=3Bsaag@ietf.org>=3B=2C websec <=3Bwebsec@ietf.org= >=3B=2C
uta@ietf.org <=3Buta@ietf.org>=3B=2C ietf-http-wg@w3.org Group
<=3Bietf-http-wg@w3.org>=3B=2C http-auth@ietf.org <=3Bhttp-auth@ietf.= org>=3B


Hiya=2C

Following up on the presentation at IETF-91 on this topic=2C [1]
we've created a new list [2] for moving that along. The list
description is:

"=3BThis list is for discussion of proposals for doing better than bear= er
tokens (e.g. HTTP cookies=2C OAuth tokens etc.) for web applications.
The specific goal is chartering a WG focused on preventing security
token export and replay attacks."=3B

If you're interested please join in.

Thanks to Vinod and Andrei for agreeing to admin the list.

We'll kick off discussion in a few days when folks have had
a chance to subscribe.

Cheers=2C
S.

PS: Please don't reply-all to this=2C join the new list=2C wait
a few days and then say what you need to say:-)

[1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf
[2] https://ww= w.ietf.org/mailman/listinfo/unbearable

_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.o= rg/mailman/listinfo/websec



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 513 bytes
Desc: OpenPGP digital signature
URL: <=3Bhttp://www.ietf.org/mail-archive/web/oa= uth/attachments/20141205/c398b24f/attachment.asc>=3B

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest=2C Vol 74=2C Issue 38
*************************************
--_e10740d1-5516-498c-862b-d4ed4d78bc0d_-- From nobody Fri Dec 5 17:48:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326E1A87CE for ; Fri, 5 Dec 2014 17:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6hjtBVIy6uR for ; Fri, 5 Dec 2014 17:48:45 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ED31A87C3 for ; Fri, 5 Dec 2014 17:48:45 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB61mf9b018734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 01:48:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB61mefg015143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 01:48:41 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB61meW2019045; Sat, 6 Dec 2014 01:48:40 GMT Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Dec 2014 17:48:40 -0800 References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <548204B3.5050903@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Fri, 5 Dec 2014 17:48:38 -0800 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Jpcfu-J0_wUwBnNSn7VXIV5_UjE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 01:48:47 -0000 Doesn't that duplicate our current work? Phil > On Dec 5, 2014, at 11:17, Hannes Tschofenig wr= ote: >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: [websec] unbearable - new mailing list to discuss better than > bearer tokens... > Date: Fri, 05 Dec 2014 16:43:19 +0000 > From: Stephen Farrell > Reply-To: Stephen Farrell > To: saag@ietf.org , websec , > uta@ietf.org , ietf-http-wg@w3.org Group > , http-auth@ietf.org >=20 >=20 > Hiya, >=20 > Following up on the presentation at IETF-91 on this topic, [1] > we've created a new list [2] for moving that along. The list > description is: >=20 > "This list is for discussion of proposals for doing better than bearer > tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. > The specific goal is chartering a WG focused on preventing security > token export and replay attacks." >=20 > If you're interested please join in. >=20 > Thanks to Vinod and Andrei for agreeing to admin the list. >=20 > We'll kick off discussion in a few days when folks have had > a chance to subscribe. >=20 > Cheers, > S. >=20 > PS: Please don't reply-all to this, join the new list, wait > a few days and then say what you need to say:-) >=20 > [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf > [2] https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Dec 6 00:52:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821971A8FD3 for ; Sat, 6 Dec 2014 00:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHcnzDztFi1l for ; Sat, 6 Dec 2014 00:52:40 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CDC1A8F4E for ; Sat, 6 Dec 2014 00:52:39 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so747628wiw.9 for ; Sat, 06 Dec 2014 00:52:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Y29mFy6T0PtM8+Dntj39kDNaZaQReFg0YXaMzxtRPpw=; b=KWCKJ7C0sHHRoplt2B8n8EOUY2yIIVl5yWorzAi1Rm3EkjZxU+gMZ57i9q5Pp1/0QK p5/IbirlO3Y6LmQTdW2YRjmOHHldm/+8Ob0/B7aLf8UwqTW9rFRkSOT5hn+aTkcQOy2j THwlrSGL97cTmmGp5Tp39eIcZ/62hPUhRs8vr04xIP0l9Er0QwTq3CnYuTaWcN6pZ7eL T2Gc7p0I+imOl2YwjqMcb445QjMdu1xKMhTvMVKYOoy4B8IlmpU/ElXhSqU6mHiMI8O/ H/b6VCjyMxsgRXjSnHufDHZ+N8QmVLiDQfNh/3D+hl4bZCv2UxsM0dKOgg0jNLSDvoQb JeOA== X-Gm-Message-State: ALoCoQl8pEDOZYCCUJIFaixuWhrfU35/Eknjeo5xMmk6J7zOtMvmdnsPu0lugnjOUDGm9Jrhrhfj X-Received: by 10.194.48.109 with SMTP id k13mr31114310wjn.7.1417855958703; Sat, 06 Dec 2014 00:52:38 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id f7sm1114997wiz.13.2014.12.06.00.52.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Dec 2014 00:52:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B8B21117-303A-4F7E-9B2D-C096B1FE536D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Sat, 6 Dec 2014 05:52:36 -0300 Message-Id: <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> To: Phil Hunt X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5WL9OEXIlG3w-cjb3V0L2mPYHiI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 08:52:42 -0000 --Apple-Mail=_B8B21117-303A-4F7E-9B2D-C096B1FE536D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, this is the the work formerly known as origin bound certificates & = Channel ID. We need this to bind id_tokens and or access tokens to TLS = sessions. So it is an alternative TLS binding mechanism. We still need to = describe how to use it with OAuth and JWT. It is a building block we can use for PoP. John B. > On Dec 5, 2014, at 10:48 PM, Phil Hunt wrote: >=20 > Doesn't that duplicate our current work? >=20 > Phil >=20 >> On Dec 5, 2014, at 11:17, Hannes Tschofenig = wrote: >>=20 >>=20 >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: [websec] unbearable - new mailing list to discuss better = than >> bearer tokens... >> Date: Fri, 05 Dec 2014 16:43:19 +0000 >> From: Stephen Farrell >> Reply-To: Stephen Farrell >> To: saag@ietf.org , websec , >> uta@ietf.org , ietf-http-wg@w3.org Group >> , http-auth@ietf.org >>=20 >>=20 >> Hiya, >>=20 >> Following up on the presentation at IETF-91 on this topic, [1] >> we've created a new list [2] for moving that along. The list >> description is: >>=20 >> "This list is for discussion of proposals for doing better than = bearer >> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. >> The specific goal is chartering a WG focused on preventing security >> token export and replay attacks." >>=20 >> If you're interested please join in. >>=20 >> Thanks to Vinod and Andrei for agreeing to admin the list. >>=20 >> We'll kick off discussion in a few days when folks have had >> a chance to subscribe. >>=20 >> Cheers, >> S. >>=20 >> PS: Please don't reply-all to this, join the new list, wait >> a few days and then say what you need to say:-) >>=20 >> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >> [2] https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >>=20 >>=20 >>=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 --Apple-Mail=_B8B21117-303A-4F7E-9B2D-C096B1FE536D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDYwODUyMzZaMCMGCSqGSIb3DQEJBDEWBBQlKnDmD06Fs6AiamY4O5Gi ROvcZjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCvoQ1O17Qg3cKDdWfRMTXi5ny4/ryqVD+C0S8j1LncmTY2aaay5yrE ws1uJLcczRisjYcwUoH9aTZbjw9yIc/Vq6rKxw4iH0IWLX8VypoKv3tdRSRH7vJjF/kaUViiIpHl Ii3Gx0Ea4H+Y77ae5JhyGx27JHKQr/giAXbactytAIRDszg9Fjc8ThKm96l6rbFCrnylpGYhW5zd BQh3c0UA7hOaz4r5/TDUo/6yyxeJNYYt6DXqhNFQXb12hBzZZr5FOXwnsXTxoF8oD2Ktx/llSxOd 1J850bwXWIQVnSNKw4PwoRVKUxCH6wNY7OFX/0HPx/+sjzHkdzWYMxwEbs3WAAAAAAAA --Apple-Mail=_B8B21117-303A-4F7E-9B2D-C096B1FE536D-- From nobody Sat Dec 6 01:28:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341071A1A25 for ; Sat, 6 Dec 2014 01:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1HcZPMrNLt9 for ; Sat, 6 Dec 2014 01:28:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504721A0197 for ; Sat, 6 Dec 2014 01:28:07 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MH07e-1Y9tER3aeA-00Drfb; Sat, 06 Dec 2014 10:28:02 +0100 Message-ID: <5482CC20.4000202@gmx.net> Date: Sat, 06 Dec 2014 10:28:00 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Bradley , Phil Hunt References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> In-Reply-To: <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K7CCqOp0ncbj4dG76QDL4fB7OdBswGNtl" X-Provags-ID: V03:K0:p3mJEqbawX4d73RkjX+yPutHtrrm+3DR42POh2F16uNTCj/aLMG rLhvWDZCCnD/hVzOG7fygpDppfhWTIazuirboa6UQxFEequ28JK4Q16CLyDCZWB4bFLS0s2 sd+bEDVi5t+mSiz87ewrRT2lyL8S1ROkm2n6Mvl7Q1VvjeFQVvC916oeO4A2SuRhFIAgr8N ymTg0R1Yt7sNsXUHuXjfg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yMjgMGDFGZEdU3bu1j-IF5RSwic Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 09:28:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K7CCqOp0ncbj4dG76QDL4fB7OdBswGNtl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Phil. As currently described it replicates a lot of the work we have done in PoP. Ciao Hannes On 12/06/2014 09:52 AM, John Bradley wrote: > No, this is the the work formerly known as origin bound certificates &= Channel ID. We need this to bind id_tokens and or access tokens to TLS= sessions. >=20 > So it is an alternative TLS binding mechanism. We still need to descr= ibe how to use it with OAuth and JWT. >=20 > It is a building block we can use for PoP. >=20 > John B. >> On Dec 5, 2014, at 10:48 PM, Phil Hunt wrote: >> >> Doesn't that duplicate our current work? >> >> Phil >> >>> On Dec 5, 2014, at 11:17, Hannes Tschofenig wrote: >>> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: [websec] unbearable - new mailing list to discuss better tha= n >>> bearer tokens... >>> Date: Fri, 05 Dec 2014 16:43:19 +0000 >>> From: Stephen Farrell >>> Reply-To: Stephen Farrell >>> To: saag@ietf.org , websec , >>> uta@ietf.org , ietf-http-wg@w3.org Group >>> , http-auth@ietf.org >>> >>> >>> Hiya, >>> >>> Following up on the presentation at IETF-91 on this topic, [1] >>> we've created a new list [2] for moving that along. The list >>> description is: >>> >>> "This list is for discussion of proposals for doing better than beare= r >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. >>> The specific goal is chartering a WG focused on preventing security >>> token export and replay attacks." >>> >>> If you're interested please join in. >>> >>> Thanks to Vinod and Andrei for agreeing to admin the list. >>> >>> We'll kick off discussion in a few days when folks have had >>> a chance to subscribe. >>> >>> Cheers, >>> S. >>> >>> PS: Please don't reply-all to this, join the new list, wait >>> a few days and then say what you need to say:-) >>> >>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >>> >>> >>> _______________________________________________ >>> 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 --K7CCqOp0ncbj4dG76QDL4fB7OdBswGNtl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUgswgAAoJEGhJURNOOiAto9EIAIEi9d1IMlPiNiOs35Ld02GO tD/lIJ+pOqSaCu4ZeSYFP6cGK13ecDpc1ag+sEJvSrNTvCSlHXI96GWdB3HznKxR g7Xn/3IyztO5Crv4K7N7Y6eyvHlhAaeO9tdQ2R65HJF22ODdnsye1ECLV7o2lEoH RQ4h3gIcAKQmvOnErfs9VapebXSSRo55nNiEFEIkQgRs8ky4+u9vbImZnOYvbknM bDnzEf2PPRtzJWoZJIWE0Q8bPXO8sMEd4X8Nmp/pL9R2nJiLB4MoI6bHY9Zl7JyI PT6ts80gNjUlnT02+Qvctxkc6+uUC1SNcw8SAAHHx5TulwDHB/5yJAobAY92EQQ= =62Fm -----END PGP SIGNATURE----- --K7CCqOp0ncbj4dG76QDL4fB7OdBswGNtl-- From nobody Sat Dec 6 02:09:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D992C1A9024 for ; Sat, 6 Dec 2014 02:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVdGXXEMPO6e for ; Sat, 6 Dec 2014 02:09:09 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8941A9008 for ; Sat, 6 Dec 2014 02:09:08 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so2753797wgh.9 for ; Sat, 06 Dec 2014 02:09:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yke033efrb/aKgPcsNi36UHrzGuRN12M7SOp0oVLyYM=; b=TeVJiYO8M2UuJmeItipig0FdEIX/KM9sLiiOO3kZ2inXi1CvETuEDIymkWyyMZmtMW 4lfE5u7cu1dhVb2ZlenmZUwQCnREwS7y/U6olHk5YSXo7bWVVsMzADIwnd6T9am+RG4K Trkn+vgejWIxhLAdGa97R5ounoSAtbjq8y3xZcHeBzIxOA4qwQMd5p2ziMdffCdsq2NB YPLNXqJrbycdy+/x6JVcdO3UF+TiafR9WiX5gwebyg+KFnhxsEqnto6rEkB5ZS+Pdui1 XYwf9eRqmXt6DKkwOGw8rpAmev6iNOZPxXHHfqB8EjtdBjzHtCOJOwNrdmyVO6AkxHwA JXtg== X-Gm-Message-State: ALoCoQlgYLvRONv5P6nBxbzf3DCguhryvhmySBT5/7eBRkPA4zUii6eY8MIFkVktiRBsb7VsdvS/ X-Received: by 10.194.93.5 with SMTP id cq5mr30205874wjb.84.1417860547621; Sat, 06 Dec 2014 02:09:07 -0800 (PST) Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id kv6sm48127850wjb.9.2014.12.06.02.09.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Dec 2014 02:09:06 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_66344E10-0C22-4115-B732-E3A41BFA873E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <5482CC20.4000202@gmx.net> Date: Sat, 6 Dec 2014 07:09:04 -0300 Message-Id: <4FDB30EC-62D3-4C01-9EA0-1876BA1AC861@ve7jtb.com> References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> <5482CC20.4000202@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wJhwEhVSJx1TTfe5aXPqCx6CThk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 10:09:12 -0000 --Apple-Mail=_66344E10-0C22-4115-B732-E3A41BFA873E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 They have examples of how it could be used in OAuth and Connect. They = didn't look at what we were doing with PoP so the examples don't line = up. That is why it is important to keep on top of this so that it is the = OAuth WG that is defining how this binding mechanism is used in OAuth = and JWT. The specs themselves are, or should be independent of token type. We have been waiting for TLS to produce this for around 4 years now. = It is not really new work, mostly a change of venue to make progress. All of this was discussed at the last IETF meeting. I thought a = significant number of people from the OAuth WG were in the room. John B. > On Dec 6, 2014, at 6:28 AM, Hannes Tschofenig = wrote: >=20 > I agree with Phil. As currently described it replicates a lot of the > work we have done in PoP. >=20 > Ciao > Hannes >=20 > On 12/06/2014 09:52 AM, John Bradley wrote: >> No, this is the the work formerly known as origin bound certificates = & Channel ID. We need this to bind id_tokens and or access tokens to = TLS sessions. >>=20 >> So it is an alternative TLS binding mechanism. We still need to = describe how to use it with OAuth and JWT. >>=20 >> It is a building block we can use for PoP. >>=20 >> John B. >>> On Dec 5, 2014, at 10:48 PM, Phil Hunt wrote: >>>=20 >>> Doesn't that duplicate our current work? >>>=20 >>> Phil >>>=20 >>>> On Dec 5, 2014, at 11:17, Hannes Tschofenig = wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -------- Forwarded Message -------- >>>> Subject: [websec] unbearable - new mailing list to discuss better = than >>>> bearer tokens... >>>> Date: Fri, 05 Dec 2014 16:43:19 +0000 >>>> From: Stephen Farrell >>>> Reply-To: Stephen Farrell >>>> To: saag@ietf.org , websec , >>>> uta@ietf.org , ietf-http-wg@w3.org Group >>>> , http-auth@ietf.org >>>>=20 >>>>=20 >>>> Hiya, >>>>=20 >>>> Following up on the presentation at IETF-91 on this topic, [1] >>>> we've created a new list [2] for moving that along. The list >>>> description is: >>>>=20 >>>> "This list is for discussion of proposals for doing better than = bearer >>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. >>>> The specific goal is chartering a WG focused on preventing security >>>> token export and replay attacks." >>>>=20 >>>> If you're interested please join in. >>>>=20 >>>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>>=20 >>>> We'll kick off discussion in a few days when folks have had >>>> a chance to subscribe. >>>>=20 >>>> Cheers, >>>> S. >>>>=20 >>>> PS: Please don't reply-all to this, join the new list, wait >>>> a few days and then say what you need to say:-) >>>>=20 >>>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>>=20 >>>> _______________________________________________ >>>> websec mailing list >>>> websec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/websec >>>>=20 >>>>=20 >>>>=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 >>=20 >=20 --Apple-Mail=_66344E10-0C22-4115-B732-E3A41BFA873E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDYxMDA5MDVaMCMGCSqGSIb3DQEJBDEWBBRGsHEwyOFB0Da4DuNz8jdC WgTV+zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBcEQJERKK3mkbZQr1LFNIzkUvhnuFgqELkQj9W8AF9CGElyUX+o6PZ ilh1MHjKkG+60tj3k+1+mVIce51xvyx6aTy0IboWmMBBy9RTzD4di5WatlT250liIPuNPZEzNqAk ATfh/EOMK3ITRTGU4xkR7L123WVO7x550sa7Eaa4/4uGPJeD2ydGfXlOWM+z/LG8dx+bDC7llLzp EJuZu1P3GhEARMFh5k9kEcI41BSEnyVI0Y3jx8maWfgCokPAeSX/n8gOHZYejUJ6CaF+kzelhUTO MkBTKRbPWKl0g5xVepQmX93UGQWLKSN96k1NcyKYK/UPjBO8db6nOorTS4ifAAAAAAAA --Apple-Mail=_66344E10-0C22-4115-B732-E3A41BFA873E-- From nobody Sat Dec 6 03:43:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209E41A9031 for ; Sat, 6 Dec 2014 03:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOePNXY7lZz6 for ; Sat, 6 Dec 2014 03:43:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC0A1A0127 for ; Sat, 6 Dec 2014 03:43:00 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4Wwq-1Xn7yI14mq-00yfjk; Sat, 06 Dec 2014 12:42:58 +0100 Message-ID: <5482EBC1.1030603@gmx.net> Date: Sat, 06 Dec 2014 12:42:57 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Bradley References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> <5482CC20.4000202@gmx.net> <4FDB30EC-62D3-4C01-9EA0-1876BA1AC861@ve7jtb.com> In-Reply-To: <4FDB30EC-62D3-4C01-9EA0-1876BA1AC861@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="24Ddw1GQcuPwNBeIWQqkua8qJlm8qGLKt" X-Provags-ID: V03:K0:5HJQMYFw9UZj2Ggz4GmiIE/sSZRL5bvnvSHV4UnxrbzTVInnUMu J3Aa0fj/Ohk8G+wLfVxqjrBKDBvIJayc3mGjxu59I0HPuLWmV9kG0PNpkrL/bWGQuwk27QA zk5rXqxDsgS3LB23zI581bWQEHNgHKD5wnBn+84AQ8IzuhkE0cCH19L5Nczzs/OYEJemPwe QCM1NvtQ0E9HsG2l47Bxw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-FzD2jQ5ajJbTBf_VmiquZmAOig Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 11:43:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --24Ddw1GQcuPwNBeIWQqkua8qJlm8qGLKt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think it should be the responsibility of document authors to read the the state of the art to avoid re-inventing the wheel (particularly since their co-workers have been heavily involved in the work). It is not true that we have been waiting for 4 years for this now since they have changed their solution approach many times and the use of the raw public key in combination with the PoP solution would have given a complete solution. Ciao Hannes On 12/06/2014 11:09 AM, John Bradley wrote: > They have examples of how it could be used in OAuth and Connect. They = didn't look at what we were doing with PoP so the examples don't line up.= >=20 > That is why it is important to keep on top of this so that it is the OA= uth WG that is defining how this binding mechanism is used in OAuth and J= WT. >=20 > The specs themselves are, or should be independent of token type. >=20 > We have been waiting for TLS to produce this for around 4 years now. = It is not really new work, mostly a change of venue to make progress. >=20 > All of this was discussed at the last IETF meeting. I thought a signif= icant number of people from the OAuth WG were in the room. >=20 > John B. >> On Dec 6, 2014, at 6:28 AM, Hannes Tschofenig wrote: >> >> I agree with Phil. As currently described it replicates a lot of the >> work we have done in PoP. >> >> Ciao >> Hannes >> >> On 12/06/2014 09:52 AM, John Bradley wrote: >>> No, this is the the work formerly known as origin bound certificates= & Channel ID. We need this to bind id_tokens and or access tokens to T= LS sessions. >>> >>> So it is an alternative TLS binding mechanism. We still need to des= cribe how to use it with OAuth and JWT. >>> >>> It is a building block we can use for PoP. >>> >>> John B. >>>> On Dec 5, 2014, at 10:48 PM, Phil Hunt wrote:= >>>> >>>> Doesn't that duplicate our current work? >>>> >>>> Phil >>>> >>>>> On Dec 5, 2014, at 11:17, Hannes Tschofenig wrote: >>>>> >>>>> >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: [websec] unbearable - new mailing list to discuss better t= han >>>>> bearer tokens... >>>>> Date: Fri, 05 Dec 2014 16:43:19 +0000 >>>>> From: Stephen Farrell >>>>> Reply-To: Stephen Farrell >>>>> To: saag@ietf.org , websec , >>>>> uta@ietf.org , ietf-http-wg@w3.org Group >>>>> , http-auth@ietf.org >>>>> >>>>> >>>>> Hiya, >>>>> >>>>> Following up on the presentation at IETF-91 on this topic, [1] >>>>> we've created a new list [2] for moving that along. The list >>>>> description is: >>>>> >>>>> "This list is for discussion of proposals for doing better than bea= rer >>>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.= >>>>> The specific goal is chartering a WG focused on preventing security= >>>>> token export and replay attacks." >>>>> >>>>> If you're interested please join in. >>>>> >>>>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>>> >>>>> We'll kick off discussion in a few days when folks have had >>>>> a chance to subscribe. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> PS: Please don't reply-all to this, join the new list, wait >>>>> a few days and then say what you need to say:-) >>>>> >>>>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>>>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>>> >>>>> _______________________________________________ >>>>> websec mailing list >>>>> websec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/websec >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 --24Ddw1GQcuPwNBeIWQqkua8qJlm8qGLKt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUguvBAAoJEGhJURNOOiAtC/EH/R9rBjKGpWkqkARIzWbwNiwp mvKjqKsE4h5U7x+m15aCJxcXIufujjfjvFZRPz/XCi0i+jYSs5YJFDsNEiGxk2dS 6hIo4G1E3xxe6O9T2qtKk7s9mSmjG/Mq8YhD26MNTQbpkm62uQomuKwdlKoFRfXi i9BqofUuLfgjnBLGdzUfg8+ZstGf2a2MLz496bP3vPKAItUJOGBsCHVTglxYlJs6 /sBvtOKdO2coNsGbSsKm9f59hDZ54sP5ozIxLFfsCcdOI65eUUCvk5qG0TSvbdj2 XYeM8UqqFpvpDCwvD/aY4R/Z7M9erorOm+oTdXg+ibGLQ2RWk8LQqRjutRnrqds= =X2yB -----END PGP SIGNATURE----- --24Ddw1GQcuPwNBeIWQqkua8qJlm8qGLKt-- From nobody Sat Dec 6 04:43:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8F1A9038 for ; Sat, 6 Dec 2014 04:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF_0WKAD_1IM for ; Sat, 6 Dec 2014 04:43:15 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D021A8A0E for ; Sat, 6 Dec 2014 04:43:15 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so648021igb.7 for ; Sat, 06 Dec 2014 04:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p80DTHdArAcpj9+6pFjF3+zdqL/ilPi4Y8dvdjA59Ww=; b=UmrE1q81kOvc5rW6vJzVxISs/9N+Pz02xy8jxaVjpvMSJkUBm9Uiy4Z1LbLQ4mWMCc 7SMGgsS7P53MI+5MjRib/pzAwRCYFV0un9BxK4NZVor7pqObCeqFXqvJ+vJuXSJzJgbX 0bcd5zkAyZuC93NWKqnncTxDEV1gtiHTavSqxHstgJIJpnXVuHVGqtNyP5RsGuRbebRo ptyQDRD5mIn4XjuF0ZDtuZ7IBCMtrEG7VulIL4LM8yfyStNtLb5OKprUJPrBnMl5hND9 k31pJHmHomhq+ni3Tc6Ii8Y7Dt7rqQFubck1WmBCF1jbutY636zfRjUJSCznOkRTzfgn KhUw== MIME-Version: 1.0 X-Received: by 10.50.114.97 with SMTP id jf1mr6858590igb.29.1417869794195; Sat, 06 Dec 2014 04:43:14 -0800 (PST) Received: by 10.107.131.217 with HTTP; Sat, 6 Dec 2014 04:43:14 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Dec 2014 14:43:14 +0200 Message-ID: From: Brian Thaga To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a94d66bc09505098b892c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v93nm4rZGz6HecvZWIdDkWfA_mw Subject: Re: [OAUTH-WG] OAuth Digest, Vol 74, Issue 31 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 12:43:19 -0000 --047d7b3a94d66bc09505098b892c Content-Type: text/plain; charset=UTF-8 On Wed, Dec 3, 2014 at 3:37 AM, wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Review of draft-ietf-oauth-introspection-01 (Justin Richer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 02 Dec 2014 20:36:59 -0500 > From: Justin Richer > To: Phil Hunt > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Ah, I think I got my threads crossed. Then yes, I agree with you, and I'm > going to be making authorization a MUST instead of a SHOULD. Would love to > hear feedback from other implementers on this point.? > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Phil Hunt > Date:12/02/2014 8:25 PM (GMT-05:00) > To: Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > > I was asking in the context of the thread where the comment was made that > you only need to authenticate if more information is provided. > > This didn?t make sense to me. Because you would never make the call to > re-confirm (pointless). Even a caller re-confirming is actually checking > for more information - to see if the assertion has been revoked. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Dec 2, 2014, at 5:04 PM, Justin Richer wrote: > > Nothing says you need to pack the same information inside the JWT that you > return from introspection. In our specific case, we don't put scopes or > client IDs inside the JWT, just basic signature/identifier type stuff, so > you need to call introspection to get back this other information. But the > information inside the JWT includes an "iss" claim which the client can use > to figure out *which* introspection endpoint to call. > > This is just one of many different ways you could handle multiple AS at a > single resource, and so it's definitely orthogonal to the basic > introspection concept. > > -- Justin > > On 12/2/2014 6:38 PM, Phil Hunt wrote: > I am confused. Why would you call the introspection endpoint if you were > not expecting new information to be disclosed? > > Phil > > On Dec 2, 2014, at 14:26, Richer, Justin P. wrote: > > I agree that there's some use in this (and in fact I've deployed a version > that uses a signed JWT to indicate its authorization server), but it should > remain outside the scope of this spec. It's a service discovery problem, > it's orthogonal. > > -- Justin > > > On Dec 2, 2014, at 5:13 PM, John Bradley wrote: > > Yes, but unless there is something new the introspection endpoint in UMA > is tied to the resource. > > In some cases having the token indicate the introspection endpoint may be > useful. > > John B. > > Sent from my iPhone > > On Dec 2, 2014, at 10:02 PM, Eve Maler wrote: > > FWIW, UMA goes ahead and standardizes a good deal about the trust > establishment between the RS and the AS, and (of course) profiles and wraps > the token introspection spec as part of the resulting ?authorization API? > that the AS presents to the RS. A big part of the motivation for this is to > support an n:n relationship between AS and RS entities. > > EVe > > On 2 Dec 2014, at 12:14 PM, John Bradley wrote: > > Many of the proprietary introspection protocols in use return scope, role > or other meta data for the RS to make its access policy decision on. > One of the reasons for using opaque tokens rather than JWT is to prevent > leakage of that info. > > Making authentication to the introspection endpoint a MUST if additional > attributes are present is OK, I might even be inclined to say that > authentication of some sort is always required, but that might be going a > bit far for some use cases. > > We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. > It would be nice if we could standardize it. Precluding other attributes > would not be helpful for adoption. > > > One issue that we haven?t addressed in this spec is what happens if there > are multiple AS for the RS and how it would decide what introspection > endpoint to use. > Perhaps that needs to be a extension, leaving this for the simple case. > > However having more than on e AS per RS is not as unusual as it once was > in larger environments. > > John B. > > > On Dec 2, 2014, at 4:56 PM, Richer, Justin P. wrote: > > Agreed, which is why we've got space for the "sub" and "user_id" fields > but not anything else about the user, and we've got a privacy > considerations section for dealing with that. If you can help make the > wording on that section stronger, I'd appreciate it. > > -- Justin > > On Dec 2, 2014, at 2:25 PM, Bill Mills wrote: > > If introspection returns any other user data beyond what is strictly > required to validate the token based solely on possession of the public > part it would be a mistake. > > > On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." < > jricher@mitre.org> wrote: > > > That's all fine -- it's all going over TLS anyway (RS->AS) just like the > original token fetch by the client (C->AS). Doesn't mean you need TLS > *into* the RS (C->RS) with a good PoP token. > > Can you explain how this is related to "act on behalf of"? I don't see any > connection. > > -- Justin > > On Dec 2, 2014, at 2:09 PM, Bill Mills wrote: > > Fetching the public key for a token might be fine, but what if the > introspection endpoint returns the symmetric key? Data about the user? > Where does this blur the line between this and "act on behalf of"? > > > On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." < > jricher@mitre.org> wrote: > > > The call to introspection has a TLS requirement, but the call to the RS > wouldn't necessarily have that requirement. The signature and the token > identifier are two different things. The identifier doesn't do an attacker > any good on its own without the verifiable signature that's associated with > it and the request. What I'm saying is that you introspect the identifier > and get back something that lets you, the RS, check the signature. > > -- Justin > > On Dec 2, 2014, at 1:40 PM, Bill Mills wrote: > > "However, I think it's very clear how PoP tokens would work. ..." > > I don't know if that's true. POP tokens (as yet to be fully defined) would > then also have a TLS or transport security requirement unless there is > token introspection client auth in play I think. Otherwise I can as an > attacker take that toklen and get info about it that might be useful, and I > don't think that's what we want. > > -bill > > > > > > > > > _______________________________________________ > 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 > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > _______________________________________________ > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/97e34bdb/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 74, Issue 31 > ************************************* > --047d7b3a94d66bc09505098b892c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 3, 2014 at 3:37 AM, <oauth-request@ietf.org> wrote:
Send OAuth mailing li= st submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth<= br> or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Review of draft-ietf-oauth-introspection-01 (Justin Ric= her)


----------------------------------------------------------------------

Message: 1
Date: Tue, 02 Dec 2014 20:36:59 -0500
From: Justin Richer <jricher@mit.edu<= /a>>
To: Phil Hunt <phil.hunt@oracle.= com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <vsk5f8yo3l57x91s65bsay6a.1417570619461@email.android.com>
Content-Type: text/plain; charset=3D"utf-8"

Ah, I think I got my threads crossed. Then yes, I agree with you, and I'= ;m going to be making authorization a MUST instead of a SHOULD. Would love = to hear feedback from other implementers on this point.?


-- Justin

/ Sent from my phone /


-------- Original message --------
From: Phil Hunt <phil.hunt@oracl= e.com>
Date:12/02/2014=C2=A0 8:25 PM=C2=A0 (GMT-05:00)
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

I was asking in the context of the thread where the comment was made that y= ou only need to authenticate if more information is provided.

This didn?t make sense to me. Because you would never make the call to re-c= onfirm (pointless). Even a caller re-confirming is actually checking for mo= re information - to see if the assertion has been revoked.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com

On Dec 2, 2014, at 5:04 PM, Justin Richer <jricher@mit.edu> wrote:

Nothing says you need to pack the same information inside the JWT that you = return from introspection. In our specific case, we don't put scopes or= client IDs inside the JWT, just basic signature/identifier type stuff, so = you need to call introspection to get back this other information. But the = information inside the JWT includes an "iss" claim which the clie= nt can use to figure out *which* introspection endpoint to call.

This is just one of many different ways you could handle multiple AS at a s= ingle resource, and so it's definitely orthogonal to the basic introspe= ction concept.

=C2=A0-- Justin

On 12/2/2014 6:38 PM, Phil Hunt wrote:
I am confused. Why would you call the introspection endpoint if you were no= t expecting new information to be disclosed?

Phil

On Dec 2, 2014, at 14:26, Richer, Justin P. <jricher@mitre.org> wrote:

I agree that there's some use in this (and in fact I've deployed a = version that uses a signed JWT to indicate its authorization server), but i= t should remain outside the scope of this spec. It's a service discover= y problem, it's orthogonal.

=C2=A0-- Justin


On Dec 2, 2014, at 5:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, but unless there is something new the introspection endpoint in UMA is= tied to the resource.

In some cases having the token indicate the introspection endpoint may be u= seful.

John B.

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <eve@xmlgrrl.com> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the trust establish= ment between the RS and the AS, and (of course) profiles and wraps the toke= n introspection spec as part of the resulting ?authorization API? that the = AS presents to the RS. A big part of the motivation for this is to support = an n:n relationship between AS and RS entities.

EVe

On 2 Dec 2014, at 12:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Many of the proprietary introspection protocols in use return scope, role o= r other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is to prevent le= akage of that info.

Making authentication to the introspection endpoint a MUST if additional at= tributes are present is OK, I might even be inclined to say that authentica= tion of some sort is always required, but that might be going a bit far for= some use cases.

We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. I= t would be nice if we could standardize it. Precluding other attributes wou= ld not be helpful for adoption.


One issue that we haven?t addressed in this spec is what happens if there a= re multiple AS for the RS and how it would decide what introspection endpoi= nt to use.
Perhaps that needs to be a extension, leaving this for the simple case.

However having more than on e AS per RS is not as unusual as it once was in= larger environments.

John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jricher@mitre.org> wrote:

Agreed, which is why we've got space for the "sub" and "= user_id" fields but not anything else about the user, and we've go= t a privacy considerations section for dealing with that. If you can help m= ake the wording on that section stronger, I'd appreciate it.

=C2=A0-- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

If introspection returns any other user data beyond what is strictly requir= ed to validate the token based solely on possession of the public part it w= ould be a mistake.


On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


That's all fine -- it's all going over TLS anyway (RS->AS) just = like the original token fetch by the client (C->AS). Doesn't mean yo= u need TLS *into* the RS (C->RS) with a good PoP token.

Can you explain how this is related to "act on behalf of"? I don&= #39;t see any connection.

=C2=A0-- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Fetching the public key for a token might be fine, but what if the introspe= ction endpoint returns the symmetric key? Data about the user? Where does t= his blur the line between this and "act on behalf of"?


On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org> wrote:


The call to introspection has a TLS requirement, but the call to the RS wou= ldn't necessarily have that requirement. The signature and the token id= entifier are two different things. The identifier doesn't do an attacke= r any good on its own without the verifiable signature that's associate= d with it and the request. What I'm saying is that you introspect the i= dentifier and get back something that lets you, the RS, check the signature= .

=C2=A0-- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

"However, I think it's very clear how PoP tokens would work. ...&q= uot;

I don't know if that's true. POP tokens (as yet to be fully defined= ) would then also have a TLS or transport security requirement unless there= is token introspection client auth in play I think. Otherwise I can as an = attacker take that toklen and get info about it that might be useful, and I= don't think that's what we want.

-bill








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

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


Eve Maler http://= www.xmlgrrl.com/blog
+1 425 345 6= 756=C2=A0h= ttp://www.twitter.com/xmlgrrl


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


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/ma= il-archive/web/oauth/attachments/20141202/97e34bdb/attachment.html><= br>
------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest, Vol 74, Issue 31
*************************************

--047d7b3a94d66bc09505098b892c-- From nobody Sat Dec 6 05:55:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC5D1A9040 for ; Sat, 6 Dec 2014 05:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GdosCizjNUD for ; Sat, 6 Dec 2014 05:55:41 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F07B11A9042 for ; Sat, 6 Dec 2014 05:55:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 071ABBF1B; Sat, 6 Dec 2014 13:55:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDZa50WqSNSF; Sat, 6 Dec 2014 13:55:38 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.46.31.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 166C7BF18; Sat, 6 Dec 2014 13:55:38 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <5482EBC1.1030603@gmx.net> References: <5481E0A7.2090604@cs.tcd.ie> <548204B3.5050903@gmx.net> <6E5265E8-B017-4757-ACAC-6754A30CCC81@ve7jtb.com> <5482CC20.4000202@gmx.net> <4FDB30EC-62D3-4C01-9EA0-1876BA1AC861@ve7jtb.com> <5482EBC1.1030603@gmx.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Stephen Farrell Date: Sat, 06 Dec 2014 13:55:22 +0000 To: Hannes Tschofenig , John Bradley Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-fzpngcGZpy3Lljo9gk2tZx06wo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 13:55:44 -0000 Hiya, Sorry - I should have posted the announce here too. Not doing so was just an oversight. Discussion of overlaps between the newly proposed and existing work is a fine topic for the new list I'd say. But better there than here. Cheers, S On 6 December 2014 11:42:57 GMT+00:00, Hannes Tschofenig wrote: >I think it should be the responsibility of document authors to read the >the state of the art to avoid re-inventing the wheel (particularly >since >their co-workers have been heavily involved in the work). > >It is not true that we have been waiting for 4 years for this now since >they have changed their solution approach many times and the use of the >raw public key in combination with the PoP solution would have given a >complete solution. > >Ciao >Hannes > > >On 12/06/2014 11:09 AM, John Bradley wrote: >> They have examples of how it could be used in OAuth and Connect. >They didn't look at what we were doing with PoP so the examples don't >line up. >> >> That is why it is important to keep on top of this so that it is the >OAuth WG that is defining how this binding mechanism is used in OAuth >and JWT. >> >> The specs themselves are, or should be independent of token type. >> >> We have been waiting for TLS to produce this for around 4 years now. > It is not really new work, mostly a change of venue to make progress. >> >> All of this was discussed at the last IETF meeting. I thought a >significant number of people from the OAuth WG were in the room. >> >> John B. >>> On Dec 6, 2014, at 6:28 AM, Hannes Tschofenig > wrote: >>> >>> I agree with Phil. As currently described it replicates a lot of the >>> work we have done in PoP. >>> >>> Ciao >>> Hannes >>> >>> On 12/06/2014 09:52 AM, John Bradley wrote: >>>> No, this is the the work formerly known as origin bound >certificates & Channel ID. We need this to bind id_tokens and or >access tokens to TLS sessions. >>>> >>>> So it is an alternative TLS binding mechanism. We still need to >describe how to use it with OAuth and JWT. >>>> >>>> It is a building block we can use for PoP. >>>> >>>> John B. >>>>> On Dec 5, 2014, at 10:48 PM, Phil Hunt >wrote: >>>>> >>>>> Doesn't that duplicate our current work? >>>>> >>>>> Phil >>>>> >>>>>> On Dec 5, 2014, at 11:17, Hannes Tschofenig > wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: [websec] unbearable - new mailing list to discuss better >than >>>>>> bearer tokens... >>>>>> Date: Fri, 05 Dec 2014 16:43:19 +0000 >>>>>> From: Stephen Farrell >>>>>> Reply-To: Stephen Farrell >>>>>> To: saag@ietf.org , websec , >>>>>> uta@ietf.org , ietf-http-wg@w3.org Group >>>>>> , http-auth@ietf.org >>>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> Following up on the presentation at IETF-91 on this topic, [1] >>>>>> we've created a new list [2] for moving that along. The list >>>>>> description is: >>>>>> >>>>>> "This list is for discussion of proposals for doing better than >bearer >>>>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web >applications. >>>>>> The specific goal is chartering a WG focused on preventing >security >>>>>> token export and replay attacks." >>>>>> >>>>>> If you're interested please join in. >>>>>> >>>>>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>>>> >>>>>> We'll kick off discussion in a few days when folks have had >>>>>> a chance to subscribe. >>>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>>> PS: Please don't reply-all to this, join the new list, wait >>>>>> a few days and then say what you need to say:-) >>>>>> >>>>>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>>>>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>>>> >>>>>> _______________________________________________ >>>>>> websec mailing list >>>>>> websec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/websec >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Sat Dec 6 08:08:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55DA1A8830; Sat, 6 Dec 2014 08:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLWuTas1nYn2; Sat, 6 Dec 2014 08:08:18 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755071A1BF1; Sat, 6 Dec 2014 08:08:15 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB6G87rW009841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 16:08:08 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB6G85dW007201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 16:08:05 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6G84X4016037; Sat, 6 Dec 2014 16:08:04 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Dec 2014 08:08:04 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: <5481E0A7.2090604@cs.tcd.ie> Date: Sat, 6 Dec 2014 08:08:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> References: <5481E0A7.2090604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YB6KvR3w_y5HAvk5verAqQxhT2o Cc: unbearable@ietf.org, oauth Subject: Re: [OAUTH-WG] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 16:08:22 -0000 On the surface (as currently presented) this work appears to duplicate = the POP work going on in OAuth. The key difference is that this work is = focused on using ALPN to bind tokens to the TLS channel. =46rom a use = case perspective it is very close to OAuth POP, and a specific use case = of the current OAuth POP (proof of possession) architecture. I note that the OAuth WG had originally dropped TLS binding in part = because TLS was not always end-to-end in cases where load-balancers = where used. The identified use-cases required end-to-end proof of = possession (e.g. to prevent token re-use and relaying). Never-the-less, events and approaches change and this is worth = discussing (again). =20 I think the architectural/protocol issues around the use of load = balancers have to be discussed as the current ALPN proposal may be = unbearable for many.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 5, 2014, at 8:43 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Following up on the presentation at IETF-91 on this topic, [1] > we've created a new list [2] for moving that along. The list > description is: >=20 > "This list is for discussion of proposals for doing better than bearer > tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. > The specific goal is chartering a WG focused on preventing security > token export and replay attacks." >=20 > If you're interested please join in. >=20 > Thanks to Vinod and Andrei for agreeing to admin the list. >=20 > We'll kick off discussion in a few days when folks have had > a chance to subscribe. >=20 > Cheers, > S. >=20 > PS: Please don't reply-all to this, join the new list, wait > a few days and then say what you need to say:-) >=20 > [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf > [2] https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Sat Dec 6 08:37:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436461A1B44; Sat, 6 Dec 2014 08:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z7G-g-__hDJ; Sat, 6 Dec 2014 08:37:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DABA91A0277; Sat, 6 Dec 2014 08:37:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A652BF14; Sat, 6 Dec 2014 16:37:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDgfYUGTmNRA; Sat, 6 Dec 2014 16:37:33 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.31.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C193DBEFD; Sat, 6 Dec 2014 16:37:33 +0000 (GMT) Message-ID: <548330CC.20906@cs.tcd.ie> Date: Sat, 06 Dec 2014 16:37:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Hunt References: <5481E0A7.2090604@cs.tcd.ie> <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> In-Reply-To: <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jE0YGi_2UaIOklsRQV1BnkktV8w Cc: unbearable@ietf.org, oauth Subject: Re: [OAUTH-WG] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 16:37:39 -0000 Hi Phil, Good points that need discussing but I'd suggest we give the new list a few days to allow folks to subscribe and then have that discussion. Thanks, S. On 06/12/14 16:08, Phil Hunt wrote: > On the surface (as currently presented) this work appears to duplicate the POP work going on in OAuth. The key difference is that this work is focused on using ALPN to bind tokens to the TLS channel. From a use case perspective it is very close to OAuth POP, and a specific use case of the current OAuth POP (proof of possession) architecture. > > I note that the OAuth WG had originally dropped TLS binding in part because TLS was not always end-to-end in cases where load-balancers where used. The identified use-cases required end-to-end proof of possession (e.g. to prevent token re-use and relaying). > > Never-the-less, events and approaches change and this is worth discussing (again). > > I think the architectural/protocol issues around the use of load balancers have to be discussed as the current ALPN proposal may be unbearable for many. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Dec 5, 2014, at 8:43 AM, Stephen Farrell wrote: >> >> >> Hiya, >> >> Following up on the presentation at IETF-91 on this topic, [1] >> we've created a new list [2] for moving that along. The list >> description is: >> >> "This list is for discussion of proposals for doing better than bearer >> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. >> The specific goal is chartering a WG focused on preventing security >> token export and replay attacks." >> >> If you're interested please join in. >> >> Thanks to Vinod and Andrei for agreeing to admin the list. >> >> We'll kick off discussion in a few days when folks have had >> a chance to subscribe. >> >> Cheers, >> S. >> >> PS: Please don't reply-all to this, join the new list, wait >> a few days and then say what you need to say:-) >> >> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >> [2] https://www.ietf.org/mailman/listinfo/unbearable >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Sat Dec 6 11:49:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E21A1B15; Sat, 6 Dec 2014 11:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swcoM4JQ5Uj4; Sat, 6 Dec 2014 11:49:14 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63EB1A1B06; Sat, 6 Dec 2014 11:49:14 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB6Jn8UE002342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 19:49:09 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6Jn6iq006058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 19:49:07 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6Jn6E4028719; Sat, 6 Dec 2014 19:49:06 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Dec 2014 11:49:06 -0800 References: <5481E0A7.2090604@cs.tcd.ie> <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> <548330CC.20906@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <548330CC.20906@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Sat, 6 Dec 2014 11:49:02 -0800 To: Stephen Farrell X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xwYVYhUMQHAD80crRt-q87adalQ Cc: "unbearable@ietf.org" , oauth Subject: Re: [OAUTH-WG] [Unbearable] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 19:49:16 -0000 :-) Phil > On Dec 6, 2014, at 08:37, Stephen Farrell wrot= e: >=20 >=20 >=20 > Hi Phil, >=20 > Good points that need discussing but I'd suggest we give the new > list a few days to allow folks to subscribe and then have that > discussion. >=20 > Thanks, > S. >=20 >> On 06/12/14 16:08, Phil Hunt wrote: >> On the surface (as currently presented) this work appears to duplicate th= e POP work going on in OAuth. The key difference is that this work is focus= ed on using ALPN to bind tokens to the TLS channel. =46rom a use case perspe= ctive it is very close to OAuth POP, and a specific use case of the current O= Auth POP (proof of possession) architecture. >>=20 >> I note that the OAuth WG had originally dropped TLS binding in part becau= se TLS was not always end-to-end in cases where load-balancers where used. T= he identified use-cases required end-to-end proof of possession (e.g. to pre= vent token re-use and relaying). >>=20 >> Never-the-less, events and approaches change and this is worth discussing= (again). =20 >>=20 >> I think the architectural/protocol issues around the use of load balancer= s have to be discussed as the current ALPN proposal may be unbearable for ma= ny.=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Dec 5, 2014, at 8:43 AM, Stephen Farrell w= rote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> Following up on the presentation at IETF-91 on this topic, [1] >>> we've created a new list [2] for moving that along. The list >>> description is: >>>=20 >>> "This list is for discussion of proposals for doing better than bearer >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. >>> The specific goal is chartering a WG focused on preventing security >>> token export and replay attacks." >>>=20 >>> If you're interested please join in. >>>=20 >>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>=20 >>> We'll kick off discussion in a few days when folks have had >>> a chance to subscribe. >>>=20 >>> Cheers, >>> S. >>>=20 >>> PS: Please don't reply-all to this, join the new list, wait >>> a few days and then say what you need to say:-) >>>=20 >>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>=20 >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Sat Dec 6 19:32:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5E1A1BD6; Sat, 6 Dec 2014 19:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eja2UV27jwGe; Sat, 6 Dec 2014 19:32:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6EA1A8030; Sat, 6 Dec 2014 19:32:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> Date: Sat, 06 Dec 2014 19:32:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dVSTftO-Tk4_yxNbze1f16KyblI Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 03:32:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-03.txt Pages : 12 Date : 2014-12-06 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 6 19:34:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39BC1A8035 for ; Sat, 6 Dec 2014 19:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_VQ_ka0RsPU for ; Sat, 6 Dec 2014 19:34:24 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8B01A1BD6 for ; Sat, 6 Dec 2014 19:34:24 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-eb-5483cabf21e0 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F5.A1.03354.FBAC3845; Sat, 6 Dec 2014 22:34:23 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sB73YMKc030193 for ; Sat, 6 Dec 2014 22:34:22 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB73YGMd007212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Dec 2014 22:34:21 -0500 From: Justin Richer Content-Type: multipart/signed; boundary="Apple-Mail=_983047A4-F17F-49A0-9D5B-A2BD24170C5F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sat, 6 Dec 2014 22:34:15 -0500 References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> To: oauth In-Reply-To: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6nrrv/VHOIQfdXAYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/IniYLVYhWHD89kb2C8JdTFyMkhIWAicWnte0YIW0ziwr31 bF2MXBxCAouZJF5O+s8CkhASOMoI5PBAJN4ySZyafg+sg01AVWL6mhYmkASzwCRGiYlbX4N1 8ApYSbz+sosRwjaQWLJrEzOILSzgKdGy7iWYzSKgIrH88V6gdRxAUx0l1szRBwmLCEhJvF7e DFbCKeAk8WPLV2aI6+QlPnw4zj6BkX8WsnWzkKwAsZkFtCWWLXwNZRtIPO18xQphy0tsfzsH Km4psXjmDRYI21biVt8CJgjbTuLRtEWsCxg5VjHKpuRW6eYmZuYUpybrFicn5uWlFuma6OVm luilppRuYgQFPack/w7GbweVDjEKcDAq8fD+6GoKEWJNLCuuzD3EKMnBpCTKu+tEc4gQX1J+ SmVGYnFGfFFpTmrxIUYVoF2PNqy+wCjFkpefl6okwrtSGKiONyWxsiq1KB+mTJqDRUmcd9MP vhAhgfTEktTs1NSC1CKYrAwHh5IE74mTQI2CRanpqRVpmTklCGkmDs5DjBIcPEDD34HU8BYX JOYWZ6ZD5E8xKkqJ884ASQiAJDJK8+B6YcnqFaM40FvCvLzA1CXEA0x0cN2vgAYzAQ2+W9wI MrgkESEl1cAYddTO0HtH6sepW26Z7F70dWf4n7RpvtllS8/PmLBqTtCUOb2b55l7hS6LSdqR uo2/4mJ7FmNgdJsqZ65NmG/mjbDmCS9UXUo951zdf/6F7U0huQPTHPadCL++niFg3pRnUQ9P LFx0k8XQ1/TM3stpfn8c87ZbGD9zbWv9xBQRVjq7UO+UZsMUJZbijERDLeai4kQA79ofoDED AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/98DAmsMxGDVqPxBGGdyG3Ma3C54 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 03:34:26 -0000 --Apple-Mail=_983047A4-F17F-49A0-9D5B-A2BD24170C5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Small update to introspection, now the returned values reference the JWT = claims specifically (as requested). Also updated the HTTP and HTML = references. No normative changes. =97 Justin On Dec 6, 2014, at 10:32 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-03.txt > Pages : 12 > Date : 2014-12-06 >=20 > Abstract: > This specification defines a method for a protected resource to = query > an OAuth 2.0 authorization server to determine the active state of = an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information = about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_983047A4-F17F-49A0-9D5B-A2BD24170C5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUg8q3AAoJEDPAngkbd+w9RAYIAKqflyw61nPj6I7wXdkwiJzi 4LIKn7D1Ds39OhVQxvXUjgyilSs7ZAfD5UUifL+zxs7rPdKXTQF7CUhl3ikR7kuG D1dl+zKYSkyw8zWCfxlfMcL2xQ/MSarDGVneLQ3p2anEpphop/qGhennmBJIvQzn IogZgn4OTEeMia7kwroT2I6JZ3kMtSWWptIrFrW3bcrasHac4ZQ4a4OZYoI6rzVa E7qPeVcrjypX6WujulAGSHytIsQhOiLea1gMZsFy7CvPvVlJyNhtck3wg8fxJgFy osTiCTa0CRnpn3ZtqAczB49vUPK28r2Vgf25MC4UoDAu2X5UQ5BCpYe11bWYD0Y= =D0h5 -----END PGP SIGNATURE----- --Apple-Mail=_983047A4-F17F-49A0-9D5B-A2BD24170C5F-- From nobody Sat Dec 6 19:38:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357311A8549 for ; Sat, 6 Dec 2014 19:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRDHh10FLnd6 for ; Sat, 6 Dec 2014 19:38:20 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A61F31A8546 for ; Sat, 6 Dec 2014 19:38:20 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-5f-5483cbab8cf5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 39.84.03486.CABC3845; Sat, 6 Dec 2014 22:38:20 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB73cJMt014446 for ; Sat, 6 Dec 2014 22:38:19 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB73cHNm008211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Dec 2014 22:38:19 -0500 From: Justin Richer Content-Type: multipart/signed; boundary="Apple-Mail=_A5832B8F-B51A-4C79-BA76-0BCD227123F4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sat, 6 Dec 2014 22:38:16 -0500 References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> To: oauth In-Reply-To: <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixCmqrLvmdHOIQe8fVouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48CrtUwFJ6Uqzv/4xdbAuFysi5GTQ0LAROL1irtMELaYxIV7 69lAbCGBxUwSv8/LdTFyAdlHGSUmffzBAuG8ZZK4dGIlWAebgKrE9DUtTCAJZoFJjBKrft5k BknwClhJfJ67iQXCNpBYsmsTWFxYwFOiZd1LMJtFQEXi64xfjBDrCiR2ts1iB7FFBKQkXi9v BqvhFLCWWPmtmQXiPHmJDx+Os09g5J+FbN8sJDtAbGYBbYllC19D2QYSTztfsULY8hLb386B iltKLJ55gwXCtpW41beACcK2k3g0bRHrAkaOVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZ JXqpKaWbGEGBz+6itIPx50GlQ4wCHIxKPLwLOppChFgTy4orcw8xSnIwKYny7jrRHCLEl5Sf UpmRWJwRX1Sak1p8iFEFaNejDasvMEqx5OXnpSqJ8K4UBqrjTUmsrEotyocpk+ZgURLn3fSD L0RIID2xJDU7NbUgtQgmK8PBoSTBa3MKqFGwKDU9tSItM6cEIc3EwXmIUYKDB2h4OkgNb3FB Ym5xZjpE/hSjopQ4rwNIQgAkkVGaB9cLS1ivGMWB3hLm5QWp4gEmO7juV0CDmYAG3y1uBBlc koiQkmpgtLcXWzF9i7XRjL/1nD/9Ekw1EwRmJHQYFQozFl/5UhGrsJV1s9l2dR+NqCCRz+Lr 7bKL0t+/7Pp37caFywumadwS4mKYkN4tsu2t8rbju98EP9rBXPj+wg5/cx82ofyC/P//rtnM fbzP7IoQ/0PnN7lPdks1qt56Vrb1y6JKn/LWnI6WFQbKSizFGYmGWsxFxYkAKIeTXzMDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Sz15AbfWIo0JcKi9ysGaqbGr7DI Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 03:38:22 -0000 --Apple-Mail=_A5832B8F-B51A-4C79-BA76-0BCD227123F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =85 and I just noticed hanging text at the top of section 2.2 due to the = JWT claims edit. My working copy has removed the extraneous text = =93Several of these=94. Also, as always, latest XML is up on GitHub: https://github.com/jricher/oauth-spec =97 Justin On Dec 6, 2014, at 10:34 PM, Justin Richer wrote: > Small update to introspection, now the returned values reference the = JWT claims specifically (as requested). Also updated the HTTP and HTML = references. >=20 > No normative changes. >=20 > =97 Justin >=20 > On Dec 6, 2014, at 10:32 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>=20 >> Title : OAuth 2.0 Token Introspection >> Author : Justin Richer >> Filename : draft-ietf-oauth-introspection-03.txt >> Pages : 12 >> Date : 2014-12-06 >>=20 >> Abstract: >> This specification defines a method for a protected resource to = query >> an OAuth 2.0 authorization server to determine the active state of = an >> OAuth 2.0 token and to determine meta-information about this token. >> OAuth 2.0 deployments can use this method to convey information = about >> the authorization context of the token from the authorization server >> to the protected resource. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-03 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 --Apple-Mail=_A5832B8F-B51A-4C79-BA76-0BCD227123F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUg8uoAAoJEDPAngkbd+w9j9kIAJfXUvq3Cqq2+zPVi6+corm7 KVorNLXKt+XHXZQ81mBFGUJJiOlgLY+t2l+CF9BkZAKqNJ5NaHvqErvfBQUTNA+A +/qHtjfuRx45vsF+XyUD7jWHgJ5dPD/lJ4c4WIBXjKQBgiG/IWcJtILs7flkNF5d lwK/cJ7K5iY+1Oa1gXLNKI8MW2Biv9JM6e9DpOBAKnhf0d2lWyioWEXwOgXsjOZP TUCBlI6fCC2Q72g53GNc8CqcK9980vhww5/8XjzCJpb9SCU0vpsqr/eiykA1tuEw swcSE1G+zo3LV0bU3lgg2tkqJHeFKcnMhlb2I+QHj9Ivp0Ym5kkCDMCKEPfq6uA= =8uU8 -----END PGP SIGNATURE----- --Apple-Mail=_A5832B8F-B51A-4C79-BA76-0BCD227123F4-- From nobody Sat Dec 6 20:39:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C41A86F1; Sat, 6 Dec 2014 20:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqUfFx-0U30n; Sat, 6 Dec 2014 20:38:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9563C1A86E9; Sat, 6 Dec 2014 20:38:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141207043855.11221.58305.idtracker@ietfa.amsl.com> Date: Sat, 06 Dec 2014 20:38:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7GQeiTrFD_oLixATDKd5G8Nqd_A Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 04:38:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-06.txt Pages : 17 Date : 2014-12-06 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 6 20:41:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B78A1A86EA for ; Sat, 6 Dec 2014 20:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1wyP_RkCZGL for ; Sat, 6 Dec 2014 20:41:19 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A0A641A86E9 for ; Sat, 6 Dec 2014 20:41:19 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-2c-5483da6f298d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 95.85.03486.F6AD3845; Sat, 6 Dec 2014 23:41:19 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sB74fIXQ002284 for ; Sat, 6 Dec 2014 23:41:19 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB74fGZL023904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Dec 2014 23:41:18 -0500 From: Justin Richer Content-Type: multipart/signed; boundary="Apple-Mail=_2435D05F-D593-41C0-8B65-56B4F0264DAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <9E502345-7E5B-4A10-AAFF-DDB6EA2ABE97@mit.edu> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sat, 6 Dec 2014 23:41:15 -0500 References: <20141207043855.11221.58305.idtracker@ietfa.amsl.com> To: oauth In-Reply-To: <20141207043855.11221.58305.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nrpt/qznE4PwEXouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/fZTpaCy+IVP7/dY25g3CrcxcjJISFgIvG7ZQ0LhC0mceHe erYuRi4OIYHFTBI3Lm9lhXCOMkpsPneUEcJ5yyTRO7EJrIVNQFVi+poWJpAEs8AkRomlp9ex giR4BawkfrWsYIewDSSW7NrEDGILC/hJzPl3DayZRUBF4uHDo0wgtpCAo8S1L5PA6kUEpCRe L28Gq+cUcJL4+OgqI8R98hIfPhxnn8DIPwvZvllIdoDYzALaEssWvoayDSSedr5ihbDlJba/ nQMVt5RYPPMGC4RtK3GrbwEThG0n8WjaItYFjByrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31 cjNL9FJTSjcxgkPfRWkH48+DSocYBTgYlXh4F3Q0hQixJpYVV+YeYpTkYFIS5d11ojlEiC8p P6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuFdKQxUx5uSWFmVWpQPUybNwaIkzrvp B1+IkEB6YklqdmpqQWoRTFaGg0NJgvf6DaBGwaLU9NSKtMycEoQ0EwfnIUYJDh6g4cY3QYYX FyTmFmemQ+RPMSpKifPygCQEQBIZpXlwvbCU9YpRHOgtYV5dkCoeYLqD634FNJgJaPDd4kaQ wSWJCCmpBkYuq1d1B2NvLS60bXk3jbW/+qdphjbryuf3b5crCBrJq1qsbHpjYHDlVyVLzJwb 7z9JP/RfbRqQ76V45tqafduU1Z5uKGjtdIkojHrIx7viZFrrvjfz7q56sULu/MxZjoyG57cx iba3+U/y+WXWsiHhz4srzrPW6E+vupxgs3bS7xNpJnxCCRpKLMUZiYZazEXFiQARL4zBNAMA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FW8VbhiDTXXAmiNFxwqyDTXl6J8 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 04:41:21 -0000 --Apple-Mail=_2435D05F-D593-41C0-8B65-56B4F0264DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a small batch of updates to the Dynamic Registration Management = experimental draft to address comments from the shepherd writeup. Source is in GitHub:=20 https://github.com/jricher/oauth-spec =97 Justin On Dec 6, 2014, at 11:38 PM, = wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration = Management Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-management-06.txt > Pages : 17 > Date : 2014-12-06 >=20 > Abstract: > This specification defines methods for management of dynamic OAuth > 2.0 client registrations for use cases in which the properties of a > registered client may need to be changed during the lifetime of the > client. Not all authorization servers supporting dynamic client > registration will support these management methods. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-06 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-management-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2435D05F-D593-41C0-8B65-56B4F0264DAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUg9prAAoJEDPAngkbd+w9gv8H/1tcZqQmuFp1ilFZaGHjZrDv pHgUSih+2fY6sddzKIKzVD1AFgqkXvkdUP7zBXUgFijLBd764aPiw3v4bp8jUwaB nEKCK9t1o/V7MdQCXiWfANFVlkaC8paEKj+PkFsM/yC3QG58gSyKyx5mLoCcqthH tMcP6lIl9/xePEoqFZrMqnRLPEHUYJu7/5o7FVSirWdoTmoSY1NeKLOAeY0U10/L 3Bvqix5vPc6XNY7ed3xxkOz276gFsBQrPWTq8enOwsq7ppy7MX4JA1B8pyouou7s pylDQm27y+VBoAfDQU1cUq9zFTE46GFc4RwlnY104omohIGN6ChhlOWQWQMz8IA= =t1g2 -----END PGP SIGNATURE----- --Apple-Mail=_2435D05F-D593-41C0-8B65-56B4F0264DAA-- From nobody Sun Dec 7 13:57:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586F1A00AD; Sun, 7 Dec 2014 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSMr85jC9vWr; Sun, 7 Dec 2014 13:57:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1451A00B6; Sun, 7 Dec 2014 13:57:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141207215712.11783.38494.idtracker@ietfa.amsl.com> Date: Sun, 07 Dec 2014 13:57:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OGFhLu_mNrEtP26E171CEZKfTlg Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 21:57:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Symmetric Proof of Possession for the OAuth Authorization Code Grant Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-05.txt Pages : 13 Date : 2014-12-07 Abstract: The OAuth 2.0 public client utilizing Authorization Code Grant (RFC 6749 - 4.1) is susceptible to the code interception attack. This specification describes a mechanism that acts as a control against this threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 01:35:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169391A8880 for ; Mon, 8 Dec 2014 01:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsSLHHn1_K-Y for ; Mon, 8 Dec 2014 01:35:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EB91A8738 for ; Mon, 8 Dec 2014 01:35:29 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LxPNC-1XwI7B0PIw-016xjw for ; Mon, 08 Dec 2014 10:35:27 +0100 Message-ID: <548570DE.2050100@gmx.net> Date: Mon, 08 Dec 2014 10:35:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <54856F84.4040403@gmx.net> In-Reply-To: <54856F84.4040403@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <54856F84.4040403@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NtmC1Ms7UkBnVHEMXSR7NvhlLlFb1L7wh" X-Provags-ID: V03:K0:/7aBeUZyLGLR4jpY3Wyr8WS4iLPbPwipPK4lQTBUdly0ZMV8+Sk sIZo1I7eBh6VukV6OuLuCoUYUYASYpVxQMPmY41VCSW5Z4QBh8tE5BWT/+KSAG2lX9m3LWX HaIb26SCgUKUO7NFE6UgiUs6p2KOWNmjPJTJnHZ0B92jxATiMfO027nx3XTW5wsoITk3iKW 3aDh11VuBc1Ou1QpD5P4g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ce3a8tkMe2UJXXvuxI9-0m2YqKE Subject: [OAUTH-WG] Fwd: [Ace] Webinar on "Kantara User-Managed Access (UMA)" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 09:35:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NtmC1Ms7UkBnVHEMXSR7NvhlLlFb1L7wh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you are interested in Internet of Things and authorization issues you might also want to join this webinar. Ciao Hannes -------- Forwarded Message -------- Subject: [Ace] Webinar on "Kantara User-Managed Access (UMA)" Date: Mon, 08 Dec 2014 10:29:40 +0100 From: Hannes Tschofenig To: Ace@ietf.org CC: Eve Maler Hi all, earlier this year we organized a couple of webinars to hear about ACE- relevant technologies, including OAuth, Kerberos, and the PKI/certificate model. In a recent chat with Eve Maler, who co-chairs the Kantara User-Managed Access (UMA) working group, she volunteered to explain their ongoing work to us. Eve is employed by Forgerock, a company developing identity management solutions, and has been working in the identity management space for a very long time. UMA is a profile and application of OAuth that defines how resource owners can control resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. Recent investigations have shown promise for applying UMA to Internet of Things authorization use cases. The webinar will take place on January 13th 2015 at 8am PST. We are looking forward to hear from Eve. Ciao Hannes & Kepeng --------- Here is the Webex meeting info. Webex Link: https://ietf.webex.com/ietf/j.php?MTID=3Dmf6d0740b7959df0377a74117c49a0ff= 3 Meeting #: 641 684 081 Meeting password: test Join by phone: +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 684 081 (As mentioned during earlier calls, the IETF Webex bridge does not offer other dial-in numbers. If you want to dial-in from remote please use Skype or some other VoIP tool to keep the costs at a reasonable level.) Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dmaca56e1e06cf3b2bc8322bd9a6d5afb= a We are planning to enable recording but we do not promise that it will work since there have been problems with the IETF Webex configuration in the past. --NtmC1Ms7UkBnVHEMXSR7NvhlLlFb1L7wh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUhXDeAAoJEGhJURNOOiAttHoIAIrzyt5yM+FUsh4d9zuCEPf3 RzT5CNa/5tGCoNE9GvOoXwk7culIIeGt9Ey+G1snOuDeVDQaZFH3edhq6IUVKire x+nzuxdXYIh+aEFWwoasZtTPsn7ksKvTU8yMNbGVHDGinB+34tM6KPQUgg30EYwl a51SJX/WjSNAhnPXRpuyj/3JO4aBrnBJyIQKkcOwaAVBVtQMWOA7R/pcuDpusi24 XYK+qg2V2iUNCj0zf+9etNihyR79ITHPoQBftd/hZ0eksmAtwPFAabpuF3fIJ0Ah y6S7TmSJ1YLDXYT5uYXLpkHshu9jJ4NAIvJ6RDD4wm7Id08+C9gxtScUhKWbt2A= =2C9l -----END PGP SIGNATURE----- --NtmC1Ms7UkBnVHEMXSR7NvhlLlFb1L7wh-- From nobody Mon Dec 8 15:21:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1A1A0143 for ; Mon, 8 Dec 2014 15:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnUNMT66IrQd for ; Mon, 8 Dec 2014 15:20:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E063A1A0073 for ; Mon, 8 Dec 2014 15:20:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A995DBEE5 for ; Mon, 8 Dec 2014 23:20:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a_pQnl-JihK for ; Mon, 8 Dec 2014 23:20:45 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DEDC0BED5 for ; Mon, 8 Dec 2014 23:20:44 +0000 (GMT) Message-ID: <5486324C.8060309@cs.tcd.ie> Date: Mon, 08 Dec 2014 23:20:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <54863200.4030600@cs.tcd.ie> In-Reply-To: <54863200.4030600@cs.tcd.ie> X-Forwarded-Message-Id: <54863200.4030600@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Q7eZi_R17k_1xH6UAjd04VNs29s Subject: [OAUTH-WG] Fwd: [Unbearable] one proposal for a charter - please dicsuss X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:20:59 -0000 Hiya, I've kicked off that discussion on the unbearable list. *Please* let's have the discussion there. On one mailing list, not two. Thanks, S. -------- Forwarded Message -------- Subject: [Unbearable] one proposal for a charter - please dicsuss Date: Mon, 08 Dec 2014 23:19:28 +0000 From: Stephen Farrell To: unbearable@ietf.org Hi all, There's about 70+ people on the list now so let's kick off. Andrei sent Kathleen and I the charter proposal below a while ago. For myself I don't think its quite right yet but I'd rather hear what you all think. So please discuss... Cheers, S. Token Binding (TB) Charter for Working Group Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. The idea of Token Binding is to prevent such attacks by cryptographically binding security tokens to the TLS layer. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination with HTTPS. It is a goal of this working group to prevent security token export and replay attacks, but other issues associated with the use of security tokens are out of scope. It is a goal of this working group to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS, however specifying such uses is not a primary goal. Some of the main design goals for the Token Binding protocol, in no particular order: 1. Prevent export and replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party and federation scenarios. 4. Preserve user privacy. 5. Make the Token Binding protocol useable in combination with a variety of application protocols. 6. Allow the negotiation of the Token Binding protocol without additional round-trips. 7. Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding. The working group will use the following documents as a starting point for its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs. Milestones: March 2015: WG document for the Token Binding Protocol v1.0. March 2015: WG document for HTTPS Token Binding. November 2015: Token Binding Protocol v1.0 to IESG. November 2015: HTTPS Token Binding to IESG. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Dec 9 07:59:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE111A0364 for ; Tue, 9 Dec 2014 07:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7rmAtIjEHVG for ; Tue, 9 Dec 2014 07:59:50 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C050C1A0369 for ; Tue, 9 Dec 2014 07:59:49 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2220358wid.0 for ; Tue, 09 Dec 2014 07:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G4KUT1yL5Iwb6zfcCVaKR8KOxeivfVsQFyoMzKJdRlc=; b=oIBkM5udE1aD3PlnUerWM6hxhcMp3/2cTDy/v+hl9UpaHK5IG29QutK8R9BJ6rCO1L 6AOH9fudXGiW5esyn/x/1Nz2Qb4rOORSfmnjz2jx/DuhRtCYOtc1ZQaraG5boRokJmXf AvmQBlmAZlIF+PKDibXSsy6spiTPWH7vP7YAbYD4mpj1dn7L3fI12ghBjjK9zrB6JNvp WTq9/M2WfRACUiBI8rJrrrvGHZ7GUq7XuAkbvffybkaRqIM73cEgg0p0qhORa+PqiC5N IDJAfbDOFiY5DpbiRRpLFmJA5geVLV44nocxz5eFM7yRqUI32TQSbV0I5d5qTrAXK94i s9VA== X-Received: by 10.194.24.103 with SMTP id t7mr6146148wjf.15.1418140788382; Tue, 09 Dec 2014 07:59:48 -0800 (PST) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id ei5sm12016193wid.2.2014.12.09.07.59.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 07:59:47 -0800 (PST) Message-ID: <54871C72.60006@gmail.com> Date: Tue, 09 Dec 2014 15:59:46 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu> In-Reply-To: <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h_1w7gQuUg2jB-nBDXbhhaq-NUU Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 15:59:53 -0000 Hi Justin IMHO the section 2.1 [1] requires more work. First, "resource_id". Having such a parameter does not add anything to the interoperability side of the spec. It is a "server specific string..." which may be anything and as such a 3rd party AS is unlikely to do any work around this parameter unless both RS and AS are from the same provider. IMHO it either has to be dropped, the text "The endpoint MAY allow other parameters to provide further context to the query" covers whatever else that server may want to add or attach some more specific meaning to it. Besides that, the MUST authentication requirement covers properly a possible RS identification requirement. I'd rather have a "resource_id" representing an RS base address or better, a current request URI, which in combination with an optional client_ip can help AS to make a more specific introspection action. I also suggested to promote a parameter like "client_ip". Just referring to a possibility of RS reporting a client IP adress does not help improving the interoperability either with respect to RS and AS offered by different providers working with a client IP property Thanks, Sergey [1] http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1 On 07/12/14 03:38, Justin Richer wrote: > … and I just noticed hanging text at the top of section 2.2 due to the JWT claims edit. My working copy has removed the extraneous text “Several of these”. > > Also, as always, latest XML is up on GitHub: > > https://github.com/jricher/oauth-spec > > — Justin > On Dec 6, 2014, at 10:34 PM, Justin Richer wrote: > >> Small update to introspection, now the returned values reference the JWT claims specifically (as requested). Also updated the HTTP and HTML references. >> >> No normative changes. >> >> — Justin >> >> On Dec 6, 2014, at 10:32 PM, internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF. >>> >>> Title : OAuth 2.0 Token Introspection >>> Author : Justin Richer >>> Filename : draft-ietf-oauth-introspection-03.txt >>> Pages : 12 >>> Date : 2014-12-06 >>> >>> Abstract: >>> This specification defines a method for a protected resource to query >>> an OAuth 2.0 authorization server to determine the active state of an >>> OAuth 2.0 token and to determine meta-information about this token. >>> OAuth 2.0 deployments can use this method to convey information about >>> the authorization context of the token from the authorization server >>> to the protected resource. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 nobody Tue Dec 9 18:39:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D801A88A6; Tue, 9 Dec 2014 18:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D-YjFBWCUKy; Tue, 9 Dec 2014 18:39:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 915611A88BE; Tue, 9 Dec 2014 18:39:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210023949.7662.68527.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 18:39:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GfPv6OglgjmhcnC1BCJ6kif6EC8 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-32.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 02:39:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-32.txt Pages : 35 Date : 2014-12-09 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-32 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 19:45:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9249A1A1A6C for ; Tue, 9 Dec 2014 19:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikhveNmcSFtR for ; Tue, 9 Dec 2014 19:45:47 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79F11A010C for ; Tue, 9 Dec 2014 19:45:47 -0800 (PST) Received: from BN3PR0301CA0012.namprd03.prod.outlook.com (25.160.180.150) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 03:45:46 +0000 Received: from BY2FFO11FD017.protection.gbl (2a01:111:f400:7c0c::143) by BN3PR0301CA0012.outlook.office365.com (2a01:111:e400:4000::22) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Wed, 10 Dec 2014 03:45:46 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Wed, 10 Dec 2014 03:45:45 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.188]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0210.003; Wed, 10 Dec 2014 03:45:13 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -38 and JWT -32 drafts addressing the last of the IESG review comments Thread-Index: AdAUI55I3vU3GXoERk6BHCB97RwmvAACA9ZQ Date: Wed, 10 Dec 2014 03:45:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BC19876@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BC19537@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BC19537@TK5EX14MBXC286.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BC19876TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(199003)(189002)(71186001)(16236675004)(87936001)(55846006)(16297215004)(54356999)(2501002)(76176999)(50986999)(2656002)(85806002)(26826002)(84676001)(33656002)(19625215002)(512954002)(86362001)(69596002)(66066001)(19580405001)(92566001)(84326002)(6806004)(46102003)(21056001)(20776003)(86612001)(64706001)(15975445007)(102836002)(99396003)(4396001)(19300405004)(120916001)(450100001)(19617315012)(81156004)(77156002)(62966003)(104016003)(1720100001)(19580395003)(107886001)(2351001)(107046002)(110136001)(31966008)(68736005)(106466001)(97736003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(602002); SRVR:BN3PR0301MB1204; X-Forefront-PRVS: 0421BF7135 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1204; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3fiUax2NtzEM9rq4zn3ZqQhDLBI Subject: [OAUTH-WG] FW: JOSE -38 and JWT -32 drafts addressing the last of the IESG review comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 03:45:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BC19876TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Tuesday, December 09, 2014 6:47 PM To: jose@ietf.org Cc: Stephen Farrell; Pete Resnick Subject: JOSE -38 and JWT -32 drafts addressing the last of the IESG review= comments Slightly updated JSON Object Signing and Encryption (JOSE) and JSON Web Tok= en (JWT) drafts have been published that address the last of the IESG revie= w comments, which were follow-up comments by Stephen Farrell and Pete Resni= ck. All DISCUSS comments had already been addressed by the previous drafts= . The one normative change is that impl= ementations must now discard RSA private keys with an "oth" parameter when = the implementation does not support private keys with more than two primes.= The remaining changes were editorial improvements suggested by Pete. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-38 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-38 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-38 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-38 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-38= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-3= 8.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-38.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-3= 8.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-32.ht= ml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1310 and = as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BC19876TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Tuesday, December 09, 2014 6:47 PM
To: jose@ietf.org
Cc: Stephen Farrell; Pete Resnick
Subject: JOSE -38 and JWT -32 drafts addressing the last of the IESG= review comments

 

Slightly updated JSON Object Signing and Encryption = (JOSE) and JSON Web Token (JWT) drafts have been published that address the= last of the IESG review comments, which were follow-up comments by Stephen= Farrell and Pete Resnick.  All DISCUSS comments had already been addressed by the previous drafts.  The one normative change is that implementat= ions must now discard RSA private keys with an “oth” parameter when the impleme= ntation does not support private keys with more than two primes.  The remaining changes were editorial improvements suggested by Pete.<= /o:p>

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-38

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-38

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-38

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-38

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-32

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-38.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-38.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-38.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-38.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-32.html

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1310 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439BC19876TK5EX14MBXC286r_-- From nobody Mon Dec 15 09:33:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F91A871B for ; Mon, 15 Dec 2014 09:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHdQtZ82rzOw for ; Mon, 15 Dec 2014 09:33:40 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D803B1A86F5 for ; Mon, 15 Dec 2014 09:33:39 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-9a-548f1b72ea51 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 14.54.03354.27B1F845; Mon, 15 Dec 2014 12:33:38 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sBFHXcNl005007 for ; Mon, 15 Dec 2014 12:33:38 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFHXaKJ001151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Dec 2014 12:33:37 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBFHXamA006854; Mon, 15 Dec 2014 12:33:36 -0500 (EST) Date: Mon, 15 Dec 2014 12:33:36 -0500 (EST) From: Benjamin Kaduk To: oauth@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixCmqrFsk3R9isPaigcXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXJZN1PBN96KH7/CGxj3c3cxcnBICJhIHHgY38XICWSKSVy4 t54NxBYSWMwksbEjuouRC8g+xiix/9VJdojEdSaJM11iEIkGRokPy+eygCRYBLQlOhs+MIPY bAIqEjPfbASbJCIgJPF8Zx8TiC0sYCexpf0FWJxXwFFi/aq3jCC2qICOxOr9U1gg4oISJ2c+ AbOZBbQklk/fxjKBkW8WktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJT SjcxggKJ3UV1B+OEQ0qHGAU4GJV4eCMY+0KEWBPLiitzDzFKcjApifLaS/WHCPEl5adUZiQW Z8QXleakFh9ilOBgVhLhnfUOqJw3JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxW hoNDSYL3gSTQUMGi1PTUirTMnBKENBMHJ8hwHqDhd0BqeIsLEnOLM9Mh8qcYFaXEed+CJARA EhmleXC9sEh/xSgO9Iow71WQKh5gkoDrfgU0mAlo8GXGHpDBJYkIKakGxlW8d3tqv3M4buNx 9+pdsNPH6uecHO4ndw5F///kf2uJYBbf6u5zQpNl1lZ+T92pwBXg41V15/3r/Y8+/veeeXGz Vrmv3qag2IuZG/s8/695udqjeQrjinxm45wTmf3vrT5Mf/Ik+72tO9fWFY+s3iQvU3VmtOSN f7C+JM37r1X26x+aT439WZRYijMSDbWYi4oTASid5S/PAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_lDOiP1vzeEoc0TGKT2dDMkAKtA Subject: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:33:42 -0000 Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben ---------- Forwarded message ---------- Date: Mon, 15 Dec 2014 12:14:30 -0500 From: Benjamin Kaduk To: kitten@ietf.org Cc: kitten-chairs@tools.ietf.org Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 This message begins the fourth Working Group Last Call (WGLC) of "A set of SASL Mechanisms for OAuth" . Due to the overlap of the last call period with holidays, the duration of the WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Because the changes between -15 and -18 involve behavior changes, including changes regarding discovery and dynamic registration, the Chairs decided to issue an additional last call. Please review the document and send comments to the Working Group mailing list < kitten at itef.org > or the co-chairs < kitten-chairs at tools.ietf.org > before the end of the WGLC. Any and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From futuretizen@gmail.com Mon Dec 15 19:05:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE21AC3E9 for ; Mon, 15 Dec 2014 19:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn8UwUSUdyZC for ; Mon, 15 Dec 2014 19:05:22 -0800 (PST) Received: from mail-yh0-x242.google.com (mail-yh0-x242.google.com [IPv6:2607:f8b0:4002:c01::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10571AC3E4 for ; Mon, 15 Dec 2014 19:05:22 -0800 (PST) Received: by mail-yh0-f66.google.com with SMTP id f10so1609155yha.5 for ; Mon, 15 Dec 2014 19:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mEA7h1s04PTkgcpbvhiGX/nouUP4qHX20wK4n2m6veU=; b=N+QSAZMq1RfAIiyIaLmBtVPBkb5wlqq9VH4tFeoEmBYoq30V3VHp1IYXOTPbo0JpNe /vEgVX+SfsqSNoqhpeX4tCK4+5EbQcxtYbUm3ysOcwibWFjz3n7lFHqGWZGqB9KVztoz 33MgOGD1g1fhffASfGdxX0dEwuqoJqUVCNeGZ88CwXzS7CVkLW5euz46dr02aySg6QqZ vPNC9PSiVEZ8XuV1zZiFDtc7QpbjSzq2HjlZY4K4Q6AIGu+lAjnBhAQWKJznqZtyWwTm onJruzW0YpZgHVuCW47jpcmeykFlcoWkDxz8A0Aq67bQNL9Ap0w8OcIFc7C/qksHWwrE /U3g== MIME-Version: 1.0 X-Received: by 10.236.20.19 with SMTP id o19mr14435564yho.119.1418699121989; Mon, 15 Dec 2014 19:05:21 -0800 (PST) Received: by 10.170.216.70 with HTTP; Mon, 15 Dec 2014 19:05:21 -0800 (PST) Date: Tue, 16 Dec 2014 08:35:21 +0530 Message-ID: From: future tizen To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c1bb82359b9f050a4ca19e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/t9VgTy_mPhjtXfaWT0hvUqh-OUI Subject: [OAUTH-WG] library for oauth2.0 in C or C++ X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 03:44:54 -0000 --001a11c1bb82359b9f050a4ca19e Content-Type: text/plain; charset=UTF-8 Dear oauth group members, i am new to this grorup, i found liboauth written in C which supports oauth 1.0 standard. i would like to know if there is any library available in C for oauth 2.0 or any plans of implementing it. Thanks in advance --001a11c1bb82359b9f050a4ca19e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear oauth group members,

=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i am new to this grorup, i found= liboauth written in C which supports oauth 1.0 standard.
i would = like to know if there is any library available in C for oauth 2.0 or any pl= ans of implementing it.


Thanks in advance
<= /div> --001a11c1bb82359b9f050a4ca19e-- From nobody Tue Dec 16 13:35:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA66A1A873E for ; Tue, 16 Dec 2014 13:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik5M1wRhZ8rZ for ; Tue, 16 Dec 2014 13:35:26 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C5AC91A016F for ; Tue, 16 Dec 2014 13:35:26 -0800 (PST) Received: (qmail 19067 invoked by uid 0); 16 Dec 2014 21:35:23 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 16 Dec 2014 21:35:23 -0000 Received: from host125.hostmonster.com ([74.220.207.125]) by CMOut01 with id UMbE1p01Q2is6CS01MbHVY; Tue, 16 Dec 2014 14:35:24 -0700 X-Authority-Analysis: v=2.1 cv=OJu0g0qB c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=Bm2sVaLAWHkA:10 a=A92cGCtB03wA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=N9CTd5XAF1Y3RYgcn2MA:9 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=hG5njnvn4-qV23hpV2gA:9 a=9PjJBgeWNpFtXloX:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=UPcnnepz304xTJw/wSmGf2HyfKHWX6dAzpr8lRPQynk=; b=Rdq3WF3tu2elMXnnjPlhltE0pjMMp/OAUr9FqwklEK37Db2zsy4MxOvfD59UYpOWwjuSKzhtd6IwEHmwdio5OS4hWFCsL7c9/Bb/7dXN5fDL0x/7IqCOpHdZ/zKq4CPu; Received: from [50.248.250.163] (port=51239 helo=HPLaptop) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Y0zly-0003aa-8N for oauth@ietf.org; Tue, 16 Dec 2014 14:35:14 -0700 From: "Donald Coffin" To: Date: Tue, 16 Dec 2014 16:35:11 -0500 Organization: REMI Networks Message-ID: <002001d01978$2dbc9d10$8935d730$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01D0194E.44E73150" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAZd9rw5kb790tjSYWL2PaXemelPA== Content-Language: en-us X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 50.248.250.163 authed with donald.coffin@reminetworks.com} Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KkmGgnC3o9Erzg9bWshPJEVeRIk Subject: [OAUTH-WG] Status of RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:35:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01D0194E.44E73150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the official status of RFC 7009 Oauth 2.0 Token Revocation? Is it still a proposed standard or has it been accepted as an internet standard. The document implies it became a standard in August 2013, but several sites, including the ISOC, list it as a proposed standard. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com ------=_NextPart_000_0021_01D0194E.44E73150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the official status of RFC 7009 Oauth 2.0 = Token Revocation?

 

Is it still = a proposed standard or has it been accepted as an internet = standard.  The document implies it became a standard in August = 2013, but several sites, including the ISOC, list it as a proposed = standard.

 

Best = regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Crossing Suite = E

Dunwoody, = GA 30338

 

Phone:    &nbs= p; (949) 636-8571

Email:    &nbs= p;  donald.coffin@reminetworks.com

 

------=_NextPart_000_0021_01D0194E.44E73150-- From nobody Tue Dec 16 14:08:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259631A87CE for ; Tue, 16 Dec 2014 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy9kItNrGq5P for ; Tue, 16 Dec 2014 14:08:09 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 974F91A8858 for ; Tue, 16 Dec 2014 14:08:04 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E73A72E035; Tue, 16 Dec 2014 17:08:04 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id F3D82B2E004; Tue, 16 Dec 2014 17:08:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 16 Dec 2014 17:08:03 -0500 From: "Richer, Justin P." To: Donald Coffin Thread-Topic: [OAUTH-WG] Status of RFC 7009 Thread-Index: AdAZd9rw5kb790tjSYWL2PaXemelPAALs78A Date: Tue, 16 Dec 2014 22:08:02 +0000 Message-ID: <6D868812-F2DC-488C-B740-C2B8DC80783F@mitre.org> References: <002001d01978$2dbc9d10$8935d730$@reminetworks.com> In-Reply-To: <002001d01978$2dbc9d10$8935d730$@reminetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_6D868812F2DC488CB740C2B8DC80783Fmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bk0uS4K8BS8pVfvLoKnQiPJHI0E Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Status of RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:08:11 -0000 --_000_6D868812F2DC488CB740C2B8DC80783Fmitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you'll notice, RFC6749 is also Proposed Standard, as are most of the RFC= s published out of IETF working groups. This is actually the final state fo= r many protocols, and it's not until many years of wide deployment that thi= ngs move up the classification stack. So in short, yes, it's a standard. -- Justin On Dec 16, 2014, at 4:35 PM, Donald Coffin > wrote: What is the official status of RFC 7009 Oauth 2.0 Token Revocation? Is it still a proposed standard or has it been accepted as an internet stan= dard. The document implies it became a standard in August 2013, but severa= l sites, including the ISOC, list it as a proposed standard. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_6D868812F2DC488CB740C2B8DC80783Fmitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <4486BBC12623DE4F9582021C52F4048E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable If you'll notice, RFC6749 is also Proposed Standard, as are most of the RFC= s published out of IETF working groups. This is actually the final state fo= r many protocols, and it's not until many years of wide deployment that thi= ngs move up the classification stack.

So in short, yes, it's a standard. 

 -- Justin

On Dec 16, 2014, at 4:35 PM, Donald Coffin <donald.coffin@reminetworks.com> wrote:

What is the official status of RFC 7009 Oauth 2.0 To= ken Revocation?

 

Is it still a proposed standard or has it been accep= ted as an internet standard.  The document implies it became a standar= d in August 2013, but several sites, including the ISOC, list it as a propo= sed standard.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO<= span style=3D"">

 

REMI Networks

2335 Dunwoody Cross= ing Suite E

Dunwoody, GA 30338<= /span>

 

Phone:  &= nbsp;   (949) 636-8571<= /p>

Email:  &= nbsp;    donald.coffin@reminetworks.com=

 

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

--_000_6D868812F2DC488CB740C2B8DC80783Fmitreorg_-- From nobody Tue Dec 16 22:45:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F214E1A0687 for ; Tue, 16 Dec 2014 22:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA7MHxcn0O2Q for ; Tue, 16 Dec 2014 22:45:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53DB1A03A7 for ; Tue, 16 Dec 2014 22:45:33 -0800 (PST) Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lj25i-1XVvPX37Ec-00dIgC; Wed, 17 Dec 2014 07:45:25 +0100 Message-ID: <54912685.5090300@gmx.net> Date: Wed, 17 Dec 2014 07:45:25 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Richer, Justin P." , Donald Coffin References: <002001d01978$2dbc9d10$8935d730$@reminetworks.com> <6D868812-F2DC-488C-B740-C2B8DC80783F@mitre.org> In-Reply-To: <6D868812-F2DC-488C-B740-C2B8DC80783F@mitre.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="naorQthM9WOxethQPBHFTM38FtRvB71SN" X-Provags-ID: V03:K0:idfwKjC/FtC2ooo1gADf6t3Frmm3zsJZ1QMXkUm3ctFbB/HMlux ydILhHa52ZNCXf1QCPL+zebKpQU9aTZQT8wtd92s73zhOFlaKMc8MRCaIQPX6OaSYAqGJOT ckfhvp0a4k0yUQqqIK3WjrQK4dBjn+21nPbPp+LAFvXe1lNH0hchWwdLFdBazEBQledWIoC cikMhjTrpWX3giWm3f90Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Bw8hurVy8AZ3fNTmi4myuoLDSWk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Status of RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 06:45:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --naorQthM9WOxethQPBHFTM38FtRvB71SN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Donald, let me also provide you with a reference to the standardization process: https://www.ietf.org/about/standards-process.html (which references https://www.ietf.org/about/process-docs.html#RFC7127) As Justin said, standards come in different levels of maturity. Ciao Hannes On 12/16/2014 11:08 PM, Richer, Justin P. wrote: > If you'll notice, RFC6749 is also Proposed Standard, as are most of the= > RFCs published out of IETF working groups. This is actually the final > state for many protocols, and it's not until many years of wide > deployment that things move up the classification stack. >=20 > So in short, yes, it's a standard.=20 >=20 > -- Justin >=20 > On Dec 16, 2014, at 4:35 PM, Donald Coffin > = > > wrote: >=20 >> What is the official status of RFC 7009 Oauth 2.0 Token Revocation? >> >> =20 >> >> Is it still a proposed standard or has it been accepted as an internet= >> standard. The document implies it became a standard in August 2013, >> but several sites, including the ISOC, list it as a proposed standard.= >> >> =20 >> >> Best regards, >> >> Don >> >> Donald F. Coffin >> >> Founder/CTO >> >> =20 >> >> REMI Networks >> >> 2335 Dunwoody Crossing Suite E >> >> Dunwoody, GA 30338 >> >> =20 >> >> Phone: (949) 636-8571 >> >> Email: donald.coffin@reminetworks.com >> >> >> =20 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --naorQthM9WOxethQPBHFTM38FtRvB71SN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUkSaFAAoJEGhJURNOOiAtXg8H/01pWdcYINIIcJimM3OZ5fz0 8BzNv80K5MGRKRK+H6LcCHdhFQln/V6o9kH7CzQ4SHDkeoghiz9Ln6vUQEzuagS8 3F+8DFM8Bk6ONT/e9WBnC+tWsp+jMXZtdsFrZYKiWz0P2BcL5BWyYhryPTZ3Ejeq 1BKJnFwCyltoYnwT3AVAsEGg0zLIbOvASFJQwzUFJxp2uSI03SZMDoFn9UZ5JE9c TWIn6t0t5s/zQI65cJKpYNDajBKdGKqspgq8fgengxUegnZeUgegHVIzZDC1y8xL vBZJNs5VaHKpOCqruNfA5cbkvn8VWaAh2mDIC71yuXnwzdPoF8qb4vnzxjIQPJs= =W2jT -----END PGP SIGNATURE----- --naorQthM9WOxethQPBHFTM38FtRvB71SN-- From nobody Fri Dec 19 15:13:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F3B1A90AE for ; Fri, 19 Dec 2014 15:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk_Bo2Z2Mqb7 for ; Fri, 19 Dec 2014 15:13:06 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCEC1A90AC for ; Fri, 19 Dec 2014 15:13:06 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so2527369wgh.37 for ; Fri, 19 Dec 2014 15:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Pwj1c3SMSMD8G1fuQLgvSCVhRCDR6sWvYMF7bRjXw7g=; b=m5yncr47agWNosv9MbwHzIEgvmzC3BXQC1mjLSSV3NoC6YZ670k4qmJo6ydlhrtWwz yGT4EBrZ5tf8Fw63c0D71wJJSzNfPEQx8S6dxADjW8Dahl9Wq4oG4XMpcI6brd1qDMy4 VB4C43UCV4fX88vYYhpyupajB/bNTJqvp4u8NBei9VLsgDkEiHEGE6Mj7H9dYK9xQoLC MgJIFMNscqeB+MsG6A6c0kG6pZ5rmZUDdm7n+73Ii0vwcXqmox1GULgDtgr/+9bKwOgO 98qQJDC8m6G+JyGYQay1Jo4yKk/PczKXxmZAQt2cQz4dRKxfWR+mydhYaZPcFVeWvw4s 7x9A== X-Received: by 10.180.228.37 with SMTP id sf5mr10110783wic.35.1419030785240; Fri, 19 Dec 2014 15:13:05 -0800 (PST) Received: from [192.168.2.7] ([109.255.230.137]) by mx.google.com with ESMTPSA id n4sm1792985wia.7.2014.12.19.15.13.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Dec 2014 15:13:04 -0800 (PST) Message-ID: <5494B0FE.4010900@gmail.com> Date: Fri, 19 Dec 2014 23:13:02 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu> <54871C72.60006@gmail.com> In-Reply-To: <54871C72.60006@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Q1XWjYdza1RWe5-7oOd8o5lZNoc Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 23:13:09 -0000 Hi Justin returning a client public/confidential status may be useful in case RS chooses to allow for a more restricted access to public clients in cases where both public & private clients are accepted Thanks, Sergey On 09/12/14 15:59, Sergey Beryozkin wrote: > Hi Justin > > IMHO the section 2.1 [1] requires more work. > > First, "resource_id". Having such a parameter does not add anything to > the interoperability side of the spec. It is a "server specific > string..." which may be anything and as such a 3rd party AS is unlikely > to do any work around this parameter unless both RS and AS are from the > same provider. > IMHO it either has to be dropped, the text "The endpoint MAY allow other > parameters to provide further context to the query" covers whatever else > that server may want to add or attach some more specific meaning to it. > Besides that, the MUST authentication requirement covers properly a > possible RS identification requirement. > I'd rather have a "resource_id" representing an RS base address or > better, a current request URI, which in combination with an optional > client_ip can help AS to make a more specific introspection action. > > I also suggested to promote a parameter like "client_ip". Just referring > to a possibility of RS reporting a client IP adress does not help > improving the interoperability either with respect to RS and AS offered > by different providers working with a client IP property > > Thanks, Sergey > > > > [1] > http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1 > > > > On 07/12/14 03:38, Justin Richer wrote: >> … and I just noticed hanging text at the top of section 2.2 due to the >> JWT claims edit. My working copy has removed the extraneous text >> “Several of these”. >> >> Also, as always, latest XML is up on GitHub: >> >> https://github.com/jricher/oauth-spec >> >> — Justin >> On Dec 6, 2014, at 10:34 PM, Justin Richer wrote: >> >>> Small update to introspection, now the returned values reference the >>> JWT claims specifically (as requested). Also updated the HTTP and >>> HTML references. >>> >>> No normative changes. >>> >>> — Justin >>> >>> On Dec 6, 2014, at 10:32 PM, internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Web Authorization Protocol Working >>>> Group of the IETF. >>>> >>>> Title : OAuth 2.0 Token Introspection >>>> Author : Justin Richer >>>> Filename : draft-ietf-oauth-introspection-03.txt >>>> Pages : 12 >>>> Date : 2014-12-06 >>>> >>>> Abstract: >>>> This specification defines a method for a protected resource to query >>>> an OAuth 2.0 authorization server to determine the active state of an >>>> OAuth 2.0 token and to determine meta-information about this token. >>>> OAuth 2.0 deployments can use this method to convey information about >>>> the authorization context of the token from the authorization server >>>> to the protected resource. >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 nobody Fri Dec 19 16:50:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1681A802F for ; Fri, 19 Dec 2014 16:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL_twdU_cq3z for ; Fri, 19 Dec 2014 16:50:30 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2081A8032 for ; Fri, 19 Dec 2014 16:50:30 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-a8-5494c7d408b2 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.CE.03762.4D7C4945; Fri, 19 Dec 2014 19:50:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sBK0oS7Q032035; Fri, 19 Dec 2014 19:50:28 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBK0oQQU001190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Dec 2014 19:50:27 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Justin Richer In-Reply-To: <5494B0FE.4010900@gmail.com> Date: Fri, 19 Dec 2014 19:50:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu> <54871C72.60006@gmail.com> <5494B0FE.4010900@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrnvl+JQQg7mPLC1Ovn3FZvFvqb0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAldHS/46toEGnYvefm0wNjA+Vuxg5OSQETCSe 7/jFBGGLSVy4t56ti5GLQ0hgMZPExIZDUM5GRomeKZ+YIZyHTBLLT7awg7QwC+hJ7Lj+i7WL kYODF8i+2qkFEhYW8JRoWfeSGcRmE1CVmL6mhQmkhFNAU+LkHnmQMAtQeO6SJ2wQU4QkPlxq YoGwtSWWLXwN1sorYCXx9/hcqLXXGSU+XHvKCpIQASq6+PoWO8TVshL/Lp5hn8AoOAvJRbMQ LpqFZOwCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsYQcHLKcmzg/HNQaVD jAIcjEo8vAUdU0KEWBPLiitzDzFKcjApifL+2AsU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLb sR0ox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwXv4GFCjYFFqempF WmZOCUKaiYMTZDgP0PCLIDW8xQWJucWZ6RD5U4yKUuK8vSAJAZBERmkeXC8subxiFAd6RZh3 G0gVDzAxwXW/AhrMBDSY891kkMEliQgpqQbGYFep5W0bG+Tzghz9dzfvMN8sE3fYZX7Y5by0 LY121w/HW9X5vp3ZkxmwcE7Xr7lfTnqLH7+ub9o0PUau7NvJ18yVG0J2XV2YJMrzIu8WMFHG 3wpYtL3s8LXc6dcUmz8nvUp/ddPtTOOqb9ac5nICoh53ZYr55urfazhtZBzK9OdB0rsfVTuU WIozEg21mIuKEwH/RWqgCQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tqCgCYRzVWUfJlZYLFeAD7o2pvo Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 00:50:34 -0000 There=92s a whole host of client information that =93might=94 be helpful = to an RS, but I don=92t think it would be helpful for us to try to = determine all of that information since, as far as I know, there is no = implementation today that is passing that kind of information over. = Especially consider that whether the client is public or not has no = bearing over how the token is presented to the RS. If in the future someone wants to standardize that kind of information = as an extension to introspection, the data model used in Dynamic = Registration could be referenced for this purpose. But something like = that very much belongs in an extension after there are at least a couple = implementations of it. =97 Justin > On Dec 19, 2014, at 6:13 PM, Sergey Beryozkin = wrote: >=20 > Hi Justin >=20 > returning a client public/confidential status may be useful in case RS = chooses to allow for a more restricted access to public clients in cases = where both public & private clients are accepted >=20 > Thanks, Sergey > On 09/12/14 15:59, Sergey Beryozkin wrote: >> Hi Justin >>=20 >> IMHO the section 2.1 [1] requires more work. >>=20 >> First, "resource_id". Having such a parameter does not add anything = to >> the interoperability side of the spec. It is a "server specific >> string..." which may be anything and as such a 3rd party AS is = unlikely >> to do any work around this parameter unless both RS and AS are from = the >> same provider. >> IMHO it either has to be dropped, the text "The endpoint MAY allow = other >> parameters to provide further context to the query" covers whatever = else >> that server may want to add or attach some more specific meaning to = it. >> Besides that, the MUST authentication requirement covers properly a >> possible RS identification requirement. >> I'd rather have a "resource_id" representing an RS base address or >> better, a current request URI, which in combination with an optional >> client_ip can help AS to make a more specific introspection action. >>=20 >> I also suggested to promote a parameter like "client_ip". Just = referring >> to a possibility of RS reporting a client IP adress does not help >> improving the interoperability either with respect to RS and AS = offered >> by different providers working with a client IP property >>=20 >> Thanks, Sergey >>=20 >>=20 >>=20 >> [1] >> = http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1 >>=20 >>=20 >>=20 >> On 07/12/14 03:38, Justin Richer wrote: >>> =85 and I just noticed hanging text at the top of section 2.2 due to = the >>> JWT claims edit. My working copy has removed the extraneous text >>> =93Several of these=94. >>>=20 >>> Also, as always, latest XML is up on GitHub: >>>=20 >>> https://github.com/jricher/oauth-spec >>>=20 >>> =97 Justin >>> On Dec 6, 2014, at 10:34 PM, Justin Richer wrote: >>>=20 >>>> Small update to introspection, now the returned values reference = the >>>> JWT claims specifically (as requested). Also updated the HTTP and >>>> HTML references. >>>>=20 >>>> No normative changes. >>>>=20 >>>> =97 Justin >>>>=20 >>>> On Dec 6, 2014, at 10:32 PM, internet-drafts@ietf.org wrote: >>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol = Working >>>>> Group of the IETF. >>>>>=20 >>>>> Title : OAuth 2.0 Token Introspection >>>>> Author : Justin Richer >>>>> Filename : draft-ietf-oauth-introspection-03.txt >>>>> Pages : 12 >>>>> Date : 2014-12-06 >>>>>=20 >>>>> Abstract: >>>>> This specification defines a method for a protected resource to = query >>>>> an OAuth 2.0 authorization server to determine the active state = of an >>>>> OAuth 2.0 token and to determine meta-information about this = token. >>>>> OAuth 2.0 deployments can use this method to convey information = about >>>>> the authorization context of the token from the authorization = server >>>>> to the protected resource. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-03= >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=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 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 22 04:09:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65111A8A7C for ; Mon, 22 Dec 2014 04:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CrAnHxl6Pgw for ; Mon, 22 Dec 2014 04:08:36 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5780B1A0378 for ; Mon, 22 Dec 2014 04:08:35 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so7839681wiw.1 for ; Mon, 22 Dec 2014 04:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=e3Uq1YsP4rDcxJwskn4qZZGzXigxoJibw+npkEI3sSw=; b=vL6aX8j3+I0NFPTl7ZU1Q0XExRNt2AIavyLMe3ggPzefuSVqa177RrtkfXXYUNQ/4p HUCytlBjmeAAbZNilLoAts0jZYCGnHfqbxx+6cCbECkJo+v9SppiklV+ao9TxJ6xUZLO ktT951f3COyhhFrSN4gUsA+hrz675cxBOpi1qXLeXwtGYGr7h6A4VC1+H1KT8Ns8gtdJ 4gA5l3gvq6UUOU0wBaS5vAxylMsM6Ad2oDeRjjCrtYt+7BV8eDs7NpU/sS5tTz9A5gYu PTUyaechZpBg0cu1ddgxc0QqsDlngncSxoyT6oK2IqDgI7vAQ6oxUvuc7GJEEgoK1dNI rggQ== X-Received: by 10.180.76.132 with SMTP id k4mr30917160wiw.41.1419250113742; Mon, 22 Dec 2014 04:08:33 -0800 (PST) Received: from [192.168.2.7] ([109.255.230.137]) by mx.google.com with ESMTPSA id wv8sm23457266wjc.44.2014.12.22.04.08.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Dec 2014 04:08:33 -0800 (PST) Message-ID: <549809BF.3080707@gmail.com> Date: Mon, 22 Dec 2014 12:08:31 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20140721135816.30459.4950.idtracker@ietfa.amsl.com> In-Reply-To: <20140721135816.30459.4950.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HTEF4CF9HKJ1lPUBLUEFVlVGZws Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 12:09:02 -0000 Hi Justin I see a fair bit of interest toward this work now being shown from my colleagues; it would help if the next draft could clarify which HTTP headers can be signed given it is difficult to get hold of some of HTTP headers typically created by a low level HTTP transport component. Thanks, Sergey On 21/07/14 14:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : A Method for Signing an HTTP Requests for OAuth > Authors : Justin Richer > John Bradley > Hannes Tschofenig > Filename : draft-ietf-oauth-signed-http-request-00.txt > Pages : 11 > Date : 2014-07-21 > > Abstract: > This document a method for offering data origin authentication and > integrity protection of HTTP requests. To convey the relevant data > items in the request a JSON-based encapsulation is used and the JSON > Web Signature (JWS) technique is re-used. JWS offers integrity > protection using symmetric as well as asymmetric cryptography. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Dec 22 04:33:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A041A8A9B for ; Mon, 22 Dec 2014 04:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjeP0WvlSkVI for ; Mon, 22 Dec 2014 04:33:28 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F418F1A8A95 for ; Mon, 22 Dec 2014 04:33:27 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-28-54980f96c44e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id F3.B5.03326.69F08945; Mon, 22 Dec 2014 07:33:26 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sBMCXPSX021796; Mon, 22 Dec 2014 07:33:26 -0500 Received: from [IPv6:2607:fb90:2909:2fa:0:1e:2ed9:d201] ([172.56.23.73]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBMCXNf0028983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Dec 2014 07:33:25 -0500 Date: Mon, 22 Dec 2014 07:33:22 -0500 Message-ID: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> Importance: normal From: Justin Richer To: Sergey Beryozkin , oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_5133150833291170" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nojuNf0aIwZblqhYn375is/i31N6B yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyvj1RK3gl3PFw1fL2BsYG5y6GDk5JARMJI7t v8wCYYtJXLi3nq2LkYtDSGAxk8S1w49YIJyNjBLTr91khHB2MUlMezgDrIVFQFXiz9EWZhBb WKBMYtvhHiYQm1fATeLLoTdADRwcnAJCEl27JEDCbEDl09e0gJWICFhL3Hg8nRGiXFDi5Mwn YCOZBUIl2ma2ME9g5J2FJDULSQrCVpf4M+8SlK0oMaX7IfssoG3MAmoSy1qVkIUXMLKtYpRN ya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECApRTkneHYzvDiodYhTgYFTi4eVImx4i xJpYVlyZe4hRkoNJSZT3LPeMECG+pPyUyozE4oz4otKc1OJDjBIczEoivIc/A5XzpiRWVqUW 5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnw8vIBDRUsSk1PrUjLzClBSDNxcIIM 5wEangxSw1tckJhbnJkOkT/FqCglzusAkhAASWSU5sH1wlLIK0ZxoFeEeVeBVPEA0w9c9yug wUxAg6VugVxdXJKIkJJqYFzync/eMcnAvDpu2/Lk5JfGDlnKMpE2sTrnigJd9O4x+FTUryuJ l6nivPA+RlOi7WueeX9rubzE3O+yKwtXVn1/cPnp/beHF1Y96NypOO3PDxaX0pW//9YZzn5V lXiUo/L7pb5761aGXWHem/8+TbiW/bdBj/2y7wsNXhScKpA4Hnp5R39ashJLcUaioRZzUXEi ABwxBjL8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gWoErIaW2SzaxuYJKzF5_Y-lTXg Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 12:33:30 -0000 ----_com.android.email_5133150833291170 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhdCdzIGVhc3k6IGFueSBoZWFkZXJzLiBUaGF0J3Mgd2h5IHRoZSBzaWduZXIgc3BlY2lmaWVz IHdoaWNoIG9uZXMuIFdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzaW5jZSBndWlkYW5jZSB0b3VnaCwg YW5kIGV4YW1wbGVzLsKgCgoKLS0gSnVzdGluCgovIFNlbnQgZnJvbSBteSBwaG9uZSAvCgoKLS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBTZXJnZXkgQmVyeW96a2luIDxz YmVyeW96a2luQGdtYWlsLmNvbT4gCkRhdGU6MTIvMjIvMjAxNCAgNzowOCBBTSAgKEdNVC0wNTow MCkgClRvOiBvYXV0aEBpZXRmLm9yZyAKQ2M6ICAKU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSS1E IEFjdGlvbjoNIAlkcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3QtMDAudHh0IAoK SGkgSnVzdGluCgpJIHNlZSBhIGZhaXIgYml0IG9mIGludGVyZXN0IHRvd2FyZCB0aGlzIHdvcmsg bm93IGJlaW5nIHNob3duIGZyb20gbXkgCmNvbGxlYWd1ZXM7IGl0IHdvdWxkIGhlbHAgaWYgdGhl IG5leHQgZHJhZnQgY291bGQgY2xhcmlmeSB3aGljaCBIVFRQIApoZWFkZXJzIGNhbiBiZSBzaWdu ZWQgZ2l2ZW4gaXQgaXMgZGlmZmljdWx0IHRvIGdldCBob2xkIG9mIHNvbWUgb2YgSFRUUCAKaGVh ZGVycyB0eXBpY2FsbHkgY3JlYXRlZCBieSBhIGxvdyBsZXZlbCBIVFRQIHRyYW5zcG9ydCBjb21w b25lbnQuCgpUaGFua3MsIFNlcmdleQoKT24gMjEvMDcvMTQgMTQ6NTgsIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZToKPgo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KPiAgIFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtp bmcgR3JvdXAgb2YgdGhlIElFVEYuCj4KPiAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBIE1l dGhvZCBmb3IgU2lnbmluZyBhbiBIVFRQIFJlcXVlc3RzIGZvciBPQXV0aAo+ICAgICAgICAgIEF1 dGhvcnMgICAgICAgICA6IEp1c3RpbiBSaWNoZXIKPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKb2huIEJyYWRsZXkKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMgVHNjaG9m ZW5pZwo+IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVx dWVzdC0wMC50eHQKPiBQYWdlcyAgICAgICAgICAgOiAxMQo+IERhdGUgICAgICAgICAgICA6IDIw MTQtMDctMjEKPgo+IEFic3RyYWN0Ogo+ICAgICBUaGlzIGRvY3VtZW50IGEgbWV0aG9kIGZvciBv ZmZlcmluZyBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBhbmQKPiAgICAgaW50ZWdyaXR5IHBy b3RlY3Rpb24gb2YgSFRUUCByZXF1ZXN0cy4gIFRvIGNvbnZleSB0aGUgcmVsZXZhbnQgZGF0YQo+ ICAgICBpdGVtcyBpbiB0aGUgcmVxdWVzdCBhIEpTT04tYmFzZWQgZW5jYXBzdWxhdGlvbiBpcyB1 c2VkIGFuZCB0aGUgSlNPTgo+ICAgICBXZWIgU2lnbmF0dXJlIChKV1MpIHRlY2huaXF1ZSBpcyBy ZS11c2VkLiAgSldTIG9mZmVycyBpbnRlZ3JpdHkKPiAgICAgcHJvdGVjdGlvbiB1c2luZyBzeW1t ZXRyaWMgYXMgd2VsbCBhcyBhc3ltbWV0cmljIGNyeXB0b2dyYXBoeS4KPgo+Cj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0 Lwo+Cj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6Cj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1 ZXN0LTAwCj4KPgo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLgo+Cj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ogo+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9BdXRoIG1haWxpbmcgbGlzdAo+IE9BdXRoQGll dGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0aCBtYWls aW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo= ----_com.android.email_5133150833291170 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5UaGF0J3MgZWFzeTogYW55 IGhlYWRlcnMuIFRoYXQncyB3aHkgdGhlIHNpZ25lciBzcGVjaWZpZXMgd2hpY2ggb25lcy4gV291 bGQgYmUgZ29vZCB0byBoYXZlIHNpbmNlIGd1aWRhbmNlIHRvdWdoLCBhbmQgZXhhbXBsZXMuJm5i c3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjlweCI+PGRpdiBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+LS0gSnVzdGluPC9kaXY+PGRp diBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogOXB4OyAiPi8gU2VudCBmcm9tIG15IHBob25lIC88L2Rpdj48L2Rpdj48ZGl2PjwvZGl2Pjxk aXY+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZy b206IFNlcmdleSBCZXJ5b3praW4gJmx0O3NiZXJ5b3praW5AZ21haWwuY29tJmd0OyA8YnI+RGF0 ZToxMi8yMi8yMDE0ICA3OjA4IEFNICAoR01ULTA1OjAwKSA8YnI+VG86IG9hdXRoQGlldGYub3Jn IDxicj5DYzogIDxicj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOg0gCWRyYWZ0 LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVzdC0wMC50eHQgPGJyPjxicj5IaSBKdXN0aW48 YnI+PGJyPkkgc2VlIGEgZmFpciBiaXQgb2YgaW50ZXJlc3QgdG93YXJkIHRoaXMgd29yayBub3cg YmVpbmcgc2hvd24gZnJvbSBteSA8YnI+Y29sbGVhZ3VlczsgaXQgd291bGQgaGVscCBpZiB0aGUg bmV4dCBkcmFmdCBjb3VsZCBjbGFyaWZ5IHdoaWNoIEhUVFAgPGJyPmhlYWRlcnMgY2FuIGJlIHNp Z25lZCBnaXZlbiBpdCBpcyBkaWZmaWN1bHQgdG8gZ2V0IGhvbGQgb2Ygc29tZSBvZiBIVFRQIDxi cj5oZWFkZXJzIHR5cGljYWxseSBjcmVhdGVkIGJ5IGEgbG93IGxldmVsIEhUVFAgdHJhbnNwb3J0 IGNvbXBvbmVudC48YnI+PGJyPlRoYW5rcywgU2VyZ2V5PGJyPjxicj5PbiAyMS8wNy8xNCAxNDo1 OCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXAgb2Yg dGhlIElFVEYuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEEgTWV0aG9kIGZvciBTaWduaW5nIGFu IEhUVFAgUmVxdWVzdHMgZm9yIE9BdXRoPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEp1c3RpbiBSaWNoZXI8YnI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKb2huIEJyYWRsZXk8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBI YW5uZXMgVHNjaG9mZW5pZzxicj4mZ3Q7IAlGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRyYWZ0LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVz dC0wMC50eHQ8YnI+Jmd0OyAJUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAxMTxicj4mZ3Q7IAlEYXRlJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDog MjAxNC0wNy0yMTxicj4mZ3Q7PGJyPiZndDsgQWJzdHJhY3Q6PGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBhIG1ldGhvZCBmb3Igb2ZmZXJpbmcgZGF0YSBvcmln aW4gYXV0aGVudGljYXRpb24gYW5kPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50 ZWdyaXR5IHByb3RlY3Rpb24gb2YgSFRUUCByZXF1ZXN0cy4mbmJzcDsgVG8gY29udmV5IHRoZSBy ZWxldmFudCBkYXRhPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXRlbXMgaW4gdGhl IHJlcXVlc3QgYSBKU09OLWJhc2VkIGVuY2Fwc3VsYXRpb24gaXMgdXNlZCBhbmQgdGhlIEpTT048 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZWIgU2lnbmF0dXJlIChKV1MpIHRlY2hu aXF1ZSBpcyByZS11c2VkLiZuYnNwOyBKV1Mgb2ZmZXJzIGludGVncml0eTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3RlY3Rpb24gdXNpbmcgc3ltbWV0cmljIGFzIHdlbGwgYXMg YXN5bW1ldHJpYyBjcnlwdG9ncmFwaHkuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4mZ3Q7IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAt cmVxdWVzdC88YnI+Jmd0Ozxicj4mZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Ojxicj4mZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVzdC0wMDxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uPGJyPiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+Jmd0Ozxicj4mZ3Q7IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+ Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4mZ3Q7PGJyPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0Ozxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGlu ZyBsaXN0PGJyPk9BdXRoQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_5133150833291170-- From nobody Mon Dec 22 04:36:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6243F1A8AB1 for ; Mon, 22 Dec 2014 04:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hznkJ56D6hhX for ; Mon, 22 Dec 2014 04:36:08 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6CD1A8A9D for ; Mon, 22 Dec 2014 04:36:08 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so7875582wib.16 for ; Mon, 22 Dec 2014 04:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sy2+tGGBb1gYpGWNU5kUmAQP2XhQJpJFCgTg/bRqN2Q=; b=wNooOytaL7MyrEgjGt2NaTGBjoHereMKXn4oVJNJgrlOnhpk79XN44DRHj+z3NrR8P QAGVRzyTcRsFlvwOBHt4Pzy69y3L5S+5kbMO6CN+UB/sT9UuccOxmLpto98Q4/Ua95lR 4jShTsDh5+y3nXyQ4uEtVCjlV4V4Xm9rfleV3n2m98LGKCgcfVCIf5UIvs+JI/YBwi+z W9KHKP/Mwf1nr6PodXMmkyaHkg5O7YPoEts2n9vHya7cJJVIgIPNCem+jl9mo3K/cDoI QpShKxIqCifuyKimSTg4X3mglnQILa63OFTfO+zXlRb7IDaag8X01xqhgZPrwLM1hhEW sG/g== X-Received: by 10.194.179.166 with SMTP id dh6mr41676858wjc.87.1419251766917; Mon, 22 Dec 2014 04:36:06 -0800 (PST) Received: from [192.168.2.7] ([109.255.230.137]) by mx.google.com with ESMTPSA id wv8sm23538684wjc.44.2014.12.22.04.36.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Dec 2014 04:36:06 -0800 (PST) Message-ID: <54981035.2060807@gmail.com> Date: Mon, 22 Dec 2014 12:36:05 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Justin Richer , oauth@ietf.org References: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> In-Reply-To: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LYJMI5R5XgNEyNTpV7AK1oO5I5k Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 12:36:10 -0000 Hi, yes, it is obvious for anyone who has read the text carefully :-), sorry for the noise Sergey On 22/12/14 12:33, Justin Richer wrote: > That's easy: any headers. That's why the signer specifies which ones. > Would be good to have since guidance tough, and examples. > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Sergey Beryozkin > Date:12/22/2014 7:08 AM (GMT-05:00) > To: oauth@ietf.org > Cc: > Subject: Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-signed-http-request-00.txt > > Hi Justin > > I see a fair bit of interest toward this work now being shown from my > colleagues; it would help if the next draft could clarify which HTTP > headers can be signed given it is difficult to get hold of some of HTTP > headers typically created by a low level HTTP transport component. > > Thanks, Sergey > > On 21/07/14 14:58, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > > > Title : A Method for Signing an HTTP Requests for > OAuth > > Authors : Justin Richer > > John Bradley > > Hannes Tschofenig > > Filename : draft-ietf-oauth-signed-http-request-00.txt > > Pages : 11 > > Date : 2014-07-21 > > > > Abstract: > > This document a method for offering data origin authentication and > > integrity protection of HTTP requests. To convey the relevant data > > items in the request a JSON-based encapsulation is used and the JSON > > Web Signature (JWS) technique is re-used. JWS offers integrity > > protection using symmetric as well as asymmetric cryptography. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 nobody Mon Dec 22 08:21:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6A1A09CF for ; Mon, 22 Dec 2014 08:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_4sQhErsEFp for ; Mon, 22 Dec 2014 08:21:48 -0800 (PST) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449BF1A1A27 for ; Mon, 22 Dec 2014 08:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419265307; bh=D/uAGMT6et2cKdl7Zmild0zq7G4BT/79DYs/9jkfE00=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=CU5EAb+B00dhAmMADrA1Ke4mRLgFE34G6Opo31+/j0HNwhvTog00hGxLoihARvMsBSmjll0+5KBhjksjPn6uxNRs7VdwyIHDB76GzPT1lQxrAhkmoHgqXOFHY59J/EcYcdI0rUzaIzT5ZbII0WA/KmfKqBh9xJ+V5x5PUVXmhhDgEQ2xK0E3p4ToaEZ4pEUOUZhY+qRg7I2qJ4No8Q6ubyZahK6ppjjHbS4yT4YcfZMskmF/xqgb22WdMd4hAWnAckgvFES2JaTHTHi1XsvpljZl0ls9fK1MqyzcQP/w5OePxoNuxEKpikIeCThSG80TZst+EogYjMaiqKr40N7Jwg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=ubcHJUb2qWgpFTKDZxjldjmYLh97FlatkfR4sHNZ0cy9QSAHGkk+gTJioEtD8XHfo3ADObFnNkNMIklhASIl1zfhowQ2WCwztR2EjcuiD8kvK3Q23j9KiPmKY1y+Gep/92iFl3B4e7KI6ChTgwGFGSVbVNdoL1mgncRbfeVOGgv48b6/8JycUJEryaBs85u0XWM02j6yin1+mUKNsj5J0aoZbHGlzbPUV63OtlaaXuSBS9H4qcuyFUc4Nh6xFuKtWo15CuUVLggNKP+Fm2xHEP4SUTqhAoLPRpTx+/VLkUPtumVYsqd+jRIQlCdpA8PgH8+L8x12nlnG1Nnq1QnZJg==; Received: from [98.139.215.140] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 16:21:47 -0000 Received: from [98.139.212.219] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 16:21:47 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 16:21:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 441248.15044.bm@omp1028.mail.bf1.yahoo.com X-YMail-OSG: 92Dto3EVM1nq9QADfV4qD2s8g.4kaRFZZjCsAnsWSjxndICfRBCDtlxeK6eGCXD HQAObpnEgvGJ9iCYNtPPH.GetDLzm_g1tTzLpTg_oynmdSgNSJWUmjxrxq4eLYwW8is9lpdFvrOz _dy0dUd49ntc8OhA8EAmdU_4Uc9UataYSuFpfpzN2bdwRrjn.lHYlyYzXuRitDYMOoDKiZSFYdGN zEp2ZqLCA_yEsqdTlrY_ZaHnjEHAu37LnTP4Br5KmPshuJOG42Q.rBIIiqrVaeNeB7Znh0nf5Vhj 3mFo_KjRDZKGGdbE4ax_7SJS4gyneHzlYUwMC1d4VjPhnWni1MJixKzANiDRihvsv80iZ1fNLaYg 5vDqrsq.V9FQWwPwWmGPeGu1eDSqpATsf4dr5bqnvZxpaIrSQ3OP5GFE1d8Fg2Nr5_obOmrqHUjD seCYAT9W_8SENtT3nksdFkiNPv6fAAoKOJ9mqEmJtU8OlLufRKWxo0PHlZjvdFrly0uqK.Bs745U SQBiupckf Received: by 76.13.26.142; Mon, 22 Dec 2014 16:21:46 +0000 Date: Mon, 22 Dec 2014 16:21:46 +0000 (UTC) From: Bill Mills To: Justin Richer , Sergey Beryozkin , "oauth@ietf.org" Message-ID: <1793186558.221941.1419265306540.JavaMail.yahoo@jws10621.mail.bf1.yahoo.com> In-Reply-To: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> References: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_221940_499890343.1419265306536" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Fbbrw1ea_sygxugikd1tTGZldZE Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 16:21:50 -0000 ------=_Part_221940_499890343.1419265306536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Did this get adopted as a WG item already and I missed it?=20 On Monday, December 22, 2014 4:33 AM, Justin Richer = wrote: =20 That's easy: any headers. That's why the signer specifies which ones. Woul= d be good to have since guidance tough, and examples.=C2=A0 -- Justin / Sent from my phone / -------- Original message -------- From: Sergey Beryozkin =20 Date:12/22/2014 7:08 AM (GMT-05:00)=20 To: oauth@ietf.org=20 Cc:=20 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00= .txt=20 Hi Justin I see a fair bit of interest toward this work now being shown from my=20 colleagues; it would help if the next draft could clarify which HTTP=20 headers can be signed given it is difficult to get hold of some of HTTP=20 headers typically created by a low level HTTP transport component. Thanks, Sergey On 21/07/14 14:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=C2=A0=C2=A0 This draft is a work item of the Web Authorization Protocol W= orking Group of the IETF. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : A Method for Signing an = HTTP Requests for OAuth >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Justin Richer >=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 John Bradley >=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Hannes Tschofenig > Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-oauth-sig= ned-http-request-00.txt > Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 11 > Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 2014-07-21 > > Abstract: >=C2=A0=C2=A0=C2=A0=C2=A0 This document a method for offering data origin a= uthentication and >=C2=A0=C2=A0=C2=A0=C2=A0 integrity protection of HTTP requests.=C2=A0 To c= onvey the relevant data >=C2=A0=C2=A0=C2=A0=C2=A0 items in the request a JSON-based encapsulation i= s used and the JSON >=C2=A0=C2=A0=C2=A0=C2=A0 Web Signature (JWS) technique is re-used.=C2=A0 J= WS offers integrity >=C2=A0=C2=A0=C2=A0=C2=A0 protection using symmetric as well as asymmetric = cryptography. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 ------=_Part_221940_499890343.1419265306536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Did this get adopted as a WG it= em already and I missed it?

<= br>
On Monday, Dece= mber 22, 2014 4:33 AM, Justin Richer <jricher@mit.edu> wrote:


That's easy: any headers. That's why the signer specifies whi= ch ones. Would be good to have since guidance tough, and examples. 


-- Justin

=
/ Sent from my phone /
=


-------- Original message --------
From: Sergey Beryo= zkin <sberyozkin@gmail.com>
Date:12/22/2014 7:08 AM (GMT-05:00)=
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] I-D Action: =09draft-ietf-oauth-signed-http-request-00.txt

Hi Justin

I = see a fair bit of interest toward this work now being shown from my
col= leagues; it would help if the next draft could clarify which HTTP
heade= rs can be signed given it is difficult to get hold of some of HTTP
head= ers typically created by a low level HTTP transport component.

Thank= s, Sergey

On 21/07/14 14:58, internet-drafts@ietf.org wrote:
>=
> A New Internet-Draft is available from the on-line Internet-Drafts= directories.
>   This draft is a work item of the Web Auth= orization Protocol Working Group of the IETF.
>
>  &n= bsp;       Title     = ;      : A Method for Signing an HTTP Requests for= OAuth
>          Author= s         : Justin Richer
>&n= bsp;            = ;            &n= bsp;  John Bradley
>       &n= bsp;            = ;        Hannes Tschofenig
> =09Fi= lename        : draft-ietf-oauth-signed-= http-request-00.txt
> =09Pages      &nb= sp;    : 11
> =09Date     &nb= sp;      : 2014-07-21
>
> Abstract:>     This document a method for offering data orig= in authentication and
>     integrity protection = of HTTP requests.  To convey the relevant data
>  &nbs= p;  items in the request a JSON-based encapsulation is used and the JS= ON
>     Web Signature (JWS) technique is re-used= .  JWS offers integrity
>     protection usi= ng symmetric as well as asymmetric cryptography.
>
>
> Th= e IETF datatracker status page for this draft is:
> https://datatrack= er.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>
> There= 's also a htmlized version available at:
> http://tools.ietf.org/html= /draft-ietf-oauth-signed-http-request-00
>
>
> Please not= e that it may take a couple of minutes from the time of submission
> = until the htmlized version and diff are available at tools.ietf.org.
>= ;
> Internet-Drafts are also available by anonymous FTP at:
> f= tp://ftp.ietf.org/internet-drafts/
>
> ________________________= _______________________
> 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


<= /div>
------=_Part_221940_499890343.1419265306536-- From nobody Mon Dec 22 08:26:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07551A1A20 for ; Mon, 22 Dec 2014 08:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io6ajY5Qu0aI for ; Mon, 22 Dec 2014 08:26:40 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 11AC01A1A1E for ; Mon, 22 Dec 2014 08:26:40 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9551472E006; Mon, 22 Dec 2014 11:26:38 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 86BE072E0C7; Mon, 22 Dec 2014 11:26:38 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.143]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Mon, 22 Dec 2014 11:26:38 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt Thread-Index: AQHQHgQPS9qnffF7lUW6PKu9E1CyvQ== Date: Mon, 22 Dec 2014 16:26:37 +0000 Message-ID: <3C34AA41-D045-40B6-9B5D-4199C485763E@mitre.org> References: <0j3djshkn5mba4hl4yvgn6r6.1419251602904@email.android.com> <1793186558.221941.1419265306540.JavaMail.yahoo@jws10621.mail.bf1.yahoo.com> In-Reply-To: <1793186558.221941.1419265306540.JavaMail.yahoo@jws10621.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_3C34AA41D04540B69B5D4199C485763Emitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dsVEVeMaCCL2fM5uQOZiRSwA8T4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 16:26:42 -0000 --_000_3C34AA41D04540B69B5D4199C485763Emitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes it did, as part of the PoP suite. It's the current stab at an HTTP pres= entation mechanism for PoP tokens. -- Justin On Dec 22, 2014, at 11:21 AM, Bill Mills > wrote: Did this get adopted as a WG item already and I missed it? On Monday, December 22, 2014 4:33 AM, Justin Richer > wrote: That's easy: any headers. That's why the signer specifies which ones. Would= be good to have since guidance tough, and examples. -- Justin / Sent from my phone / -------- Original message -------- From: Sergey Beryozkin > Date:12/22/2014 7:08 AM (GMT-05:00) To: oauth@ietf.org Cc: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00= .txt Hi Justin I see a fair bit of interest toward this work now being shown from my colleagues; it would help if the next draft could clarify which HTTP headers can be signed given it is difficult to get hold of some of HTTP headers typically created by a low level HTTP transport component. Thanks, Sergey On 21/07/14 14:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF. > > Title : A Method for Signing an HTTP Requests for OAut= h > Authors : Justin Richer > John Bradley > Hannes Tschofenig > Filename : draft-ietf-oauth-signed-http-request-00.txt > Pages : 11 > Date : 2014-07-21 > > Abstract: > This document a method for offering data origin authentication and > integrity protection of HTTP requests. To convey the relevant data > items in the request a JSON-based encapsulation is used and the JSON > Web Signature (JWS) technique is re-used. JWS offers integrity > protection using symmetric as well as asymmetric cryptography. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_3C34AA41D04540B69B5D4199C485763Emitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Yes it did, as part of the PoP suite. It's the current stab at an HTTP pres= entation mechanism for PoP tokens.

 -- Justin

On Dec 22, 2014, at 11:21 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

Did this get adopted as a WG item already and= I missed it?


On Monday, December 22, 20= 14 4:33 AM, Justin Richer <jricher@mi= t.edu> wrote:


That's easy: any headers. That's why the signer specifies which ones. = Would be good to have since guidance tough, and examples. 


-- Justin

/ Sent from my phone /


-------- Original message --------
From: Sergey Beryozkin <sberyozk= in@gmail.com>
Date:12/22/2014 7:08 AM (GMT-05:00)
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00= .txt

Hi Justin

I see a fair bit of interest toward this work now being shown from my
colleagues; it would help if the next draft could clarify which HTTP
headers can be signed given it is difficult to get hold of some of HTTP headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, internet-dra= fts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>   This draft is a work item of the Web Authorization Protoco= l Working Group of the IETF.
>
>          Title  = ;         : A Method for Signing an= HTTP Requests for OAuth
>          Authors &nb= sp;       : Justin Richer
>            = ;            &n= bsp;   John Bradley
>            = ;            &n= bsp;   Hannes Tschofenig
> Filename        : draft-ietf-oauth-= signed-http-request-00.txt
> Pages           : 11=
> Date           = : 2014-07-21
>
> Abstract:
>     This document a method for offering data origi= n authentication and
>     integrity protection of HTTP requests.  T= o convey the relevant data
>     items in the request a JSON-based encapsulatio= n is used and the JSON
>     Web Signature (JWS) technique is re-used. = ; JWS offers integrity
>     protection using symmetric as well as asymmetr= ic cryptography.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/<= br> >
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00=
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/int= ernet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>

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

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


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

--_000_3C34AA41D04540B69B5D4199C485763Emitreorg_-- From nobody Mon Dec 22 09:21:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0F1A1B67 for ; Mon, 22 Dec 2014 09:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DAbUlS5Ywkv for ; Mon, 22 Dec 2014 09:21:35 -0800 (PST) Received: from nm38-vm5.bullet.mail.bf1.yahoo.com (nm38-vm5.bullet.mail.bf1.yahoo.com [72.30.239.21]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595471A1B63 for ; Mon, 22 Dec 2014 09:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419268894; bh=PkjwcduW2PXU9h8WMnmqxRrChNfajgOJqjYSiHdO7sM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=X+rv3cn9cO1JiKeJJihgABxMs3sYOI/QTFF0dAnX3wjuqNIe4d05HF4smY6CokPoO6YPE2FAlszleZR4mOFEyHsuctTx+4tzu2EBlodK7amgzA/eS4w7kTlm7So3Id9NVXMeuvn3oV93O4+jIZuhVF1oWpCEvGRyo0XpLzq7E3t0vDjYLkiT754vsbHpmIexvnyvV1R/ErrCBP4zAy+FCEGrQo0Z8ptxleWS3nScyAMVPg+W2nxD/MCT54d2GlFANql1v2zibcnJhv0wRTciQ01XZTtzKTTLxL1HWq+jYEYp/nuDQ9OeRj0EgY53NWULMz2Xpv3Y3yEVlFI0BBRLsQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=tQFMtYcHqTwC6uN6Tec1R16CL9jaObWMNj5jWo1eIOgc6hQJno25WpQr78df9R7W8h0z0BTTgbRD8WmUS8c7ouO5WvwjoRDBiMbIlxO6ASVlboDqEvTDfCSxp75PxU6PswM+HoHA915hbnIRn3/WmUkHH0sQ1kFatKdCRnqjB4027CPKfWfH4te+vk/VzVKzSbNz6p29b0X6W4gf//qTzGlrgGZA17yr2zg4QPfdTFCEZHPpbvta1WYtW3UR4b2Sbq/xZFtPqATKivtkCBnKFTk+b6GyPaaEMafVZhnqc75tap4g8CDfcmI8az7AJcCswWscIIqFDD88lM9JpIZKtw==; Received: from [98.139.215.141] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 17:21:34 -0000 Received: from [98.139.215.229] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 17:21:34 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 22 Dec 2014 17:21:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 594868.36157.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: K_DUKL4VM1m3mE2lkWUNtGCwPYsC7tRTRXWvgMsovkpR0Lb7bzeQ9owzrRrnzXn HGHoZLOUut5u7OtHJaEpSbYUub32fXQ2OSlS7ELTozVy3.j.TVguitoRfVh_OqGrFdvfeKL2bsGE r5oblUY3Tru5SPpMFnbRIIV6n_IXrx4bg1LG30HDO50XZTmkybkyczfGHQ3Ps.ceR.3f0jrqTBA5 oGgxGuCLKKZ3yoqraCC7VHFvT2OMsyhDRhxlhjiEKtmetvrXATG1sNvAWprH_hjyY565fuu91NU1 IpK.Mf1ivWZ7F3DEwPCNGaD2FAGnlGhyOTecZ6g54bUeqdIkVaRZBhGXOQEu9mlxMuUD0jeZZzY2 FGOU4uoA2kmWeKP0OZfIyyB0p0nfrx3z_M4f83xCvYnH82hYzqRaXFwGShwK28fampG14plVbQ7i W.udh7YmWq.sjnclULZz5zIfq7mWijBV6dKoxaK_M6qWYpejhb_VraR.Zz8EJeqQv.DJRr2n7soq Vshy64ZjC Received: by 66.196.81.119; Mon, 22 Dec 2014 17:21:34 +0000 Date: Mon, 22 Dec 2014 17:21:33 +0000 (UTC) From: Bill Mills To: "Richer, Justin P." Message-ID: <1716675910.255967.1419268893770.JavaMail.yahoo@jws106148.mail.bf1.yahoo.com> In-Reply-To: <3C34AA41-D045-40B6-9B5D-4199C485763E@mitre.org> References: <3C34AA41-D045-40B6-9B5D-4199C485763E@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_255966_803108743.1419268893759" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sq3BdBBYaGOh2OfHZhKkQMgE0uo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 17:21:47 -0000 ------=_Part_255966_803108743.1419268893759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah yes, I am remembering vague snatches of that Sunday meeting we had in Lo= ndon. In 3.1 it states you have to use a hash function of equal size to the JWT w= rapper's. =C2=A0Why don't we just specify that the same function must be us= ed? Why include a timestamp explicitly here when we could use the Date header? There's no nonce included in anything here, was that an explicit decision? How is line continuation handled for header values? =C2=A0This should proba= bly be explicit about that. Repeated headers... =C2=A0"Repeated header names are processed separately w= ith no special handling." this wants to be clearer. =C2=A0Does this mean yo= u repeated a header name in the list? =C2=A0(which explicitly should not be= allowed). =C2=A0I think this needs to explicitly say "If a header name is = specified then all headers with the same name must be processed for that he= ader.". =C2=A0The next question is ordering, will any frameworks or proxies= re-order headers of the same name? =C2=A0If so then we probably have to pr= oduce a sorted list of headers. =C2=A0 Do we need to handle repeated parameter values explicitly? =C2=A0 -bill=20 On Monday, December 22, 2014 8:26 AM, "Richer, Justin P." wrote: =20 Yes it did, as part of the PoP suite. It's the current stab at an HTTP pre= sentation mechanism for PoP tokens. =C2=A0-- Justin On Dec 22, 2014, at 11:21 AM, Bill Mills wrote: Did this get adopted as a WG item already and I missed it? On Monday, December 22, 2014 4:33 AM, Justin Richer wrote= : That's easy: any headers. That's why the signer specifies which ones. Would= be good to have since guidance tough, and examples.=C2=A0 -- Justin / Sent from my phone / -------- Original message -------- From: Sergey Beryozkin Date:12/22/2014 7:08 AM (GMT-05:00)=20 To: oauth@ietf.org=20 Cc:=20 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00= .txt=20 Hi Justin I see a fair bit of interest toward this work now being shown from my=20 colleagues; it would help if the next draft could clarify which HTTP=20 headers can be signed given it is difficult to get hold of some of HTTP=20 headers typically created by a low level HTTP transport component. Thanks, Sergey On 21/07/14 14:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=C2=A0=C2=A0 This draft is a work item of the Web Authorization Protocol W= orking Group of the IETF. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : A Method for Signing an = HTTP Requests for OAuth >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Justin Richer >=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 John Bradley >=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Hannes Tschofenig > Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-oauth-sig= ned-http-request-00.txt > Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 11 > Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 2014-07-21 > > Abstract: >=C2=A0=C2=A0=C2=A0=C2=A0 This document a method for offering data origin a= uthentication and >=C2=A0=C2=A0=C2=A0=C2=A0 integrity protection of HTTP requests.=C2=A0 To c= onvey the relevant data >=C2=A0=C2=A0=C2=A0=C2=A0 items in the request a JSON-based encapsulation i= s used and the JSON >=C2=A0=C2=A0=C2=A0=C2=A0 Web Signature (JWS) technique is re-used.=C2=A0 J= WS offers integrity >=C2=A0=C2=A0=C2=A0=C2=A0 protection using symmetric as well as asymmetric = cryptography. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 ------=_Part_255966_803108743.1419268893759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah yes, I am remembering vague = snatches of that Sunday meeting we had in London.

In 3.1 it states you hav= e to use a hash function of equal size to the JWT wrapper's.  Why don'= t we just specify that the same function must be used?

Why include a timestamp explicitly here= when we could use the Date header?

There's no nonce included in anything here, was that an ex= plicit decision?

Ho= w is line continuation handled for header values?  This should probabl= y be explicit about that.

Repeated headers...  "Repeated header names are processed separately with no s= pecial
handling." this wants = to be clearer.  Does this mean you repeated a header name in the list?=  (which explicitly should not be allowed).  I think this needs t= o explicitly say "If a header name is specified then all headers with the s= ame name must be processed for that header.".  The next question is or= dering, will any frameworks or proxies re-order headers of the same name? &= nbsp;If so then we probably have to produce a sorted list of headers.  = ;

Do we need to handle repeated parameter values e= xplicitly?  

-bill


On= Monday, December 22, 2014 8:26 AM, "Richer, Justin P." <jricher@mitre.o= rg> wrote:


<= div id=3D"yiv9760592633">
Yes it did, as part of the PoP suite. It's the current stab at an HTTP pres= entation mechanism for PoP tokens.

 -- Justin

On Dec 22, 2014, at 11:21 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

Did this get adopte= d as a WG item already and I missed it?


On Monday, December 22, 20= 14 4:33 AM, Justin Richer <= jricher@mit.edu> wrote:


That's easy: any headers. That's why the signer specifies which ones. = Would be good to have since guidance tough, and examples. 


-- Justin

/ Sent from my phone /


-------- Original message --------
From: Sergey Beryozkin <sberyozkin@gmail.com>
Date:12/22/2014 7:08 AM (GMT-05:00)
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00= .txt

Hi Justin

I see a fair bit of interest toward this work now being shown from my
colleagues; it would help if the next draft could clarify which HTTP
headers can be signed given it is difficult to get hold of some of HTTP headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>   This draft is a work item of the Web Authorization Protoco= l Working Group of the IETF.
>
>          Title  = ;         : A Method for Signing an= HTTP Requests for OAuth
>          Authors &nb= sp;       : Justin Richer
>            = ;            &n= bsp;   John Bradley
>            = ;            &n= bsp;   Hannes Tschofenig
> Filename        : draft-ietf-oauth-= signed-http-request-00.txt
> Pages           : 11=
> Date           = : 2014-07-21
>
> Abstract:
>     This document a method for offering data origi= n authentication and
>     integrity protection of HTTP requests.  T= o convey the relevant data
>     items in the request a JSON-based encapsulatio= n is used and the JSON
>     Web Signature (JWS) technique is re-used. = ; JWS offers integrity
>     protection using symmetric as well as asymmetr= ic cryptography.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/<= br clear=3D"none"> >
> There's also a htmlized version available at:
> http://tools.iet= f.org/html/draft-ietf-oauth-signed-http-request-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/o= auth
>

_______________________________________________
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<= /a>


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



------=_Part_255966_803108743.1419268893759-- From nobody Tue Dec 23 06:45:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDD1ACEF3 for ; Tue, 23 Dec 2014 06:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP37LnbXIz9p for ; Tue, 23 Dec 2014 06:45:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5707A1A8F48 for ; Tue, 23 Dec 2014 06:45:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F08F218047D; Tue, 23 Dec 2014 06:44:37 -0800 (PST) To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141223144437.F08F218047D@rfc-editor.org> Date: Tue, 23 Dec 2014 06:44:37 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ny65T18wkw1IcXzqo850mbrtURc Cc: alex@kempgen.de, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4206) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 14:45:17 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4206 -------------------------------------- Type: Technical Reported by: Alexander Kempgen Section: 4.1 Original Text ------------- (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Corrected Text -------------- (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the redirection URI provided by the client in step (A). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Notes ----- As written in section 4.1.3, the redirection URI in the access token request must match the redirection URI provided by the client in the authorization request (4.1.1). The URI used to redirect the user agent to the client in step (C) is actually different from this URI, as it contains the additional query parameters "code" and "state". Affects the same sentence as Errata ID: 3500. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 23 09:59:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FEB1A1A8C; Tue, 23 Dec 2014 09:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH18phCeMNIU; Tue, 23 Dec 2014 09:59:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 457431A1A8F; Tue, 23 Dec 2014 09:59:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223175920.640.76803.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 09:59:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7jOiyn61o-CT4euVDGOKKLsuiRg Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:59:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-04.txt Pages : 13 Date : 2014-12-23 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 23 10:02:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8710D1A1ABE for ; Tue, 23 Dec 2014 10:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nackIUNVtsCR for ; Tue, 23 Dec 2014 10:02:33 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 81F241A1AB3 for ; Tue, 23 Dec 2014 10:02:33 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1996F52E056 for ; Tue, 23 Dec 2014 13:02:33 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id F3D3B52E1B9 for ; Tue, 23 Dec 2014 13:02:32 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.143]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 23 Dec 2014 13:02:32 -0500 From: "Richer, Justin P." To: "" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt Thread-Index: AQHQHto2m+EA/K/3q0afSMLS15gPipydy1qA Date: Tue, 23 Dec 2014 18:02:31 +0000 Message-ID: References: <20141223175920.640.76803.idtracker@ietfa.amsl.com> In-Reply-To: <20141223175920.640.76803.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i7zwtNa_fRWkBOzNFJXuCoFtgEQ Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 18:02:36 -0000 This draft makes two changes: - Removal of the "resource_id" input parameter, whose purpose has been lar= gely supplanted by requiring authorization to call the introspection endpoi= nt. I also don't know of any implementations that make use of this paramete= r. If there's later consensus on defining more context on the way in, we ca= n easily have an extension for that. - Re-shuffling of the examples out of an appendix and into the sections th= at they represent; it reads better this way. -- Justin On Dec 23, 2014, at 12:59 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-04.txt > Pages : 13 > Date : 2014-12-23 >=20 > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Dec 24 01:15:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AF01AD017 for ; Wed, 24 Dec 2014 01:15:36 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrRzFl1Uvwl5 for ; Wed, 24 Dec 2014 01:15:34 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BAA1AD012 for ; Wed, 24 Dec 2014 01:15:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so6775819lab.31 for ; Wed, 24 Dec 2014 01:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=gnuzN4KwL1cvbGcbatoxTxK0gFur8wu6bOmbjK5EGC0=; b=unGI7KNZ+cZ+eq3B5ZArZB4yGbYAB6WBQXMk6RG5lBxNZFt/Hh/mVAoh18Qk8UWTYJ vhR8XHSm/tUG8eKGus30YD4Q05dsAEa6T++ZQr3GToz/sDiiK0StNUXJ/gjyu4r0nR9b N7D0JJUOB0DyPXCwUMyEc85KFhrj1rVr0C5OUGtOJzT4MvG3dGT3yldL7aC07/AC61dI o0DAmwx9BBZHNdmV1ZA/lUIVmk2MS0GhZPHI7lzG3NI9SY1CtBPqGOgIxMNEJwmbnuwL aXz4fn7yreWibIFWMcmmUwFD8Liz6Yck2oIXAumxYLHYEhrM1UTAdEc3WW7CnMnTmSQH yMKw== X-Received: by 10.112.73.97 with SMTP id k1mr33497670lbv.78.1419412531872; Wed, 24 Dec 2014 01:15:31 -0800 (PST) MIME-Version: 1.0 References: <20141223175920.640.76803.idtracker@ietfa.amsl.com> From: Thomas Broyer Date: Wed, 24 Dec 2014 09:15:31 +0000 Message-ID: To: "Richer, Justin P." , "" Content-Type: multipart/alternative; boundary=001a11c3274cc08a8a050af2bb7d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zRbS_4JGMDn3GBIAYjcni_26HQA Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 09:15:37 -0000 --001a11c3274cc08a8a050af2bb7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, A couple editorial remarks: When introducing the first 2 examples, maybe merge the two paragraphs, starting with "The following non-normative example shows =E2=80=A6". Similarly, you talk about line wraps for display purpose but the examples don't need/use wrapping. Other than that, ready to go to the RFC state if you ask me. Le mar. 23 d=C3=A9c. 2014 19:02, Richer, Justin P. a = =C3=A9crit : > This draft makes two changes: > > - Removal of the "resource_id" input parameter, whose purpose has been > largely supplanted by requiring authorization to call the introspection > endpoint. I also don't know of any implementations that make use of this > parameter. If there's later consensus on defining more context on the way > in, we can easily have an extension for that. > > - Re-shuffling of the examples out of an appendix and into the sections > that they represent; it reads better this way. > > -- Justin > > On Dec 23, 2014, at 12:59 PM, < > internet-drafts@ietf.org> wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > > > Title : OAuth 2.0 Token Introspection > > Author : Justin Richer > > Filename : draft-ietf-oauth-introspection-04.txt > > Pages : 13 > > Date : 2014-12-23 > > > > Abstract: > > This specification defines a method for a protected resource to query > > an OAuth 2.0 authorization server to determine the active state of an > > OAuth 2.0 token and to determine meta-information about this token. > > OAuth 2.0 deployments can use this method to convey information about > > the authorization context of the token from the authorization server > > to the protected resource. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-oauth-introspection-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-04 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --001a11c3274cc08a8a050af2bb7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

A couple editorial remarks:

When introducing the first 2 examples, maybe merge the two p= aragraphs, starting with "The following non-normative example shows = =E2=80=A6".

Similarly, you talk about line wraps for display purpose but= the examples don't need/use wrapping.

Other than that, ready to go to the RFC state if you ask me.=


Le=C2=A0mar. 23 d=C3=A9c. 2014 19:02,=C2=A0R= icher, Justin P. <jricher@mitre.org= > a =C3=A9crit=C2=A0:
This draft m= akes two changes:

=C2=A0- Removal of the "resource_id" input parameter, whose purpo= se has been largely supplanted by requiring authorization to call the intro= spection endpoint. I also don't know of any implementations that make u= se of this parameter. If there's later consensus on defining more conte= xt on the way in, we can easily have an extension for that.

=C2=A0- Re-shuffling of the examples out of an appendix and into the sectio= ns that they represent; it reads better this way.

=C2=A0-- Justin

On Dec 23, 2014, at 12:59 PM, <internet-drafts@ietf.org> <internet-drafts@ietf.org&g= t; wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Token Introspection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-introspection-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 13
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-12-23
>
> Abstract:
>=C2=A0 =C2=A0This specification defines a method for a protected resour= ce to query
>=C2=A0 =C2=A0an OAuth 2.0 authorization server to determine the active = state of an
>=C2=A0 =C2=A0OAuth 2.0 token and to determine meta-information about th= is token.
>=C2=A0 =C2=A0OAuth 2.0 deployments can use this method to convey inform= ation about
>=C2=A0 =C2=A0the authorization context of the token from the authorizat= ion server
>=C2=A0 =C2=A0to the protected resource.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf= -oauth-introspection/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-= introspection-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-introspection-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a11c3274cc08a8a050af2bb7d-- From nobody Wed Dec 24 07:01:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769F71A8A7B for ; Wed, 24 Dec 2014 07:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1Uc7bGAFEBl for ; Wed, 24 Dec 2014 07:01:17 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id CC1801A8A7A for ; Wed, 24 Dec 2014 07:01:16 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E029A72E023; Wed, 24 Dec 2014 10:01:15 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id D102F72E00D; Wed, 24 Dec 2014 10:01:15 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.143]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Wed, 24 Dec 2014 10:01:15 -0500 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt Thread-Index: AQHQHto2m+EA/K/3q0afSMLS15gPipydy1qAgACrSciAALRlgA== Date: Wed, 24 Dec 2014 15:01:13 +0000 Message-ID: References: <20141223175920.640.76803.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_E1B297BE08454735B71C54D723774C45mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9jnl-meJYTmijqI-X0UqijXB1JE Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:01:19 -0000 --_000_E1B297BE08454735B71C54D723774C45mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the review, especially of the new text. The "Following is a non-normative example" text is, in all cases, actually = a preamble attached to the diagram/example section. In the plain text it re= nders as a separate paragraph, which is why it might look odd there. I've removed the line wrapping comments in my working draft -- those were l= eft over from previous examples, thanks for catching that. It's a small cha= nge that will get rolled up with whatever shepherd/AD comments come in at t= he next stage. -- Justin On Dec 24, 2014, at 4:15 AM, Thomas Broyer > wrote: Hi, A couple editorial remarks: When introducing the first 2 examples, maybe merge the two paragraphs, star= ting with "The following non-normative example shows =85". Similarly, you talk about line wraps for display purpose but the examples d= on't need/use wrapping. Other than that, ready to go to the RFC state if you ask me. Le mar. 23 d=E9c. 2014 19:02, Richer, Justin P. > a =E9crit : This draft makes two changes: - Removal of the "resource_id" input parameter, whose purpose has been lar= gely supplanted by requiring authorization to call the introspection endpoi= nt. I also don't know of any implementations that make use of this paramete= r. If there's later consensus on defining more context on the way in, we ca= n easily have an extension for that. - Re-shuffling of the examples out of an appendix and into the sections th= at they represent; it reads better this way. -- Justin On Dec 23, 2014, at 12:59 PM, > > = wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-04.txt > Pages : 13 > Date : 2014-12-23 > > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-04 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_E1B297BE08454735B71C54D723774C45mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7216439419C98A44A5EAF5FB0A8839F8@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Thanks for the review, especially of the new text. 

The "Following is a non-normative example" text is, in all c= ases, actually a preamble attached to the diagram/example section. In the p= lain text it renders as a separate paragraph, which is why it might look od= d there. 

I've removed the line wrapping comments in my working draft -- those w= ere left over from previous examples, thanks for catching that. It's a smal= l change that will get rolled up with whatever shepherd/AD comments come in= at the next stage.

 -- Justin

On Dec 24, 2014, at 4:15 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

Hi,

A couple editorial remarks:

When introducing the first 2 examples, maybe merge the two p= aragraphs, starting with "The following non-normative example shows = =85".

Similarly, you talk about line wraps for display purpose but= the examples don't need/use wrapping.

Other than that, ready to go to the RFC state if you ask me.=


Le mar. 23 d=E9c. 2014 19:02, Richer, = Justin P. <jricher@mitre.org>= ; a =E9crit :
This draft makes two changes:

 - Removal of the "resource_id" input parameter, whose purpo= se has been largely supplanted by requiring authorization to call the intro= spection endpoint. I also don't know of any implementations that make use o= f this parameter. If there's later consensus on defining more context on the way in, we can easily have an extension for t= hat.

 - Re-shuffling of the examples out of an appendix and into the sectio= ns that they represent; it reads better this way.

 -- Justin

On Dec 23, 2014, at 12:59 PM, <internet-drafts@ietf.org> <internet-drafts@ietf.org&g= t; wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>        Title          &nb= sp;: OAuth 2.0 Token Introspection
>        Author          : = Justin Richer
>       Filename        : draft-= ietf-oauth-introspection-04.txt
>       Pages          &nbs= p;: 13
>       Date           = ; : 2014-12-23
>
> Abstract:
>   This specification defines a method for a protected resour= ce to query
>   an OAuth 2.0 authorization server to determine the active = state of an
>   OAuth 2.0 token and to determine meta-information about th= is token.
>   OAuth 2.0 deployments can use this method to convey inform= ation about
>   the authorization context of the token from the authorizat= ion server
>   to the protected resource.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspecti= on/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-introspection-04<= /a>
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspec= tion-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

--_000_E1B297BE08454735B71C54D723774C45mitreorg_-- From nobody Mon Dec 29 09:46:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1CB1A89FD for ; Mon, 29 Dec 2014 09:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0lf2AasIm-o for ; Mon, 29 Dec 2014 09:46:19 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53E61A89FC for ; Mon, 29 Dec 2014 09:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419875177; bh=Fz+3341wBvDVwmexnd79cIzEh3ph1tY4DH1/ctz/6LE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=ZEktQsGrcIodIxNC6BVa9uqSvv9vXVoQmF4Az12i2Fvd3B66lUtTmx11U40wBdLJl4vzGQ0ESDdNJUolXi+lS0CWlpr9IWYs97jpJbsN7zSK/p7F3Kw+GZ+fW7TBDijSSMCMXkCXYyjHcqgLkjA9s7nFRexeA42ZwtGZz9fUw33vDOHlJcsG4KJi/xG3HCA0JHR3UBXYw4elhYs5qDrDw/+LYHbIiy9sfMY5P9adlWMvFZeT75C2h5WXLGvvJk3wICZQzTWBP4wqMIbOLkkbq2w3/WicFRiV4G28UUB/p8A4POcWo5wtXiBgf/FD1XOYEQa3Kt6+Ctmm7epvPRO3vQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=m++DPxBKHXh0lGvCl1RqKBBRvZnMahk2qH0dtRtsjKVS+MVd4WETzbtjqdJRlFQQT/Utgx3AW8RXjYAi6dERPmj8m5+I4ThUEKpJsKZOypODB6LPFzc6iCl4GKUpWMhrGQ4iICjxncS6DJQnEVCPpmUxsLrPYEpBC7/HLtfJ/k1RkIHxtD+7Cxamw516ypn6PbxAQjb1bFzLjdAjUUZnfHKVUIyG9avKkMWaMldJKqPdA5ioi7ImwZBaRCxINEc9IwnuT2nq+Bp53KjT/ydHQ84pk3GBBm+wpwcYIAUnp3OXl0MNpsXAPfxCWNLQu3GfEPIP+JxqQKgULym3IVeCbA==; Received: from [66.196.81.173] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 29 Dec 2014 17:46:17 -0000 Received: from [98.139.212.202] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 29 Dec 2014 17:46:17 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 29 Dec 2014 17:46:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 777755.58084.bm@omp1011.mail.bf1.yahoo.com X-YMail-OSG: Cm4MwpAVM1n2UM0jUY7up3OJ1kyLxxBqkxpHcQXyHxxyLSvlm_T0WU35fFvmo0C rJm7qGhemilNKxxlgsSBSPbVZPBeVYdeSeNMo56ronQoxUOwYYPmCH6g3pczm3cjZlJZzrV9NVoP A6aMthm_uJTivjj2QrAb5FuW3iyzTVVqzbFigcTnnfl0.VhTEBsc.3xXMfokzz7RLZIetbgrCx9y jr2G1NT1VYz204b_PwllxHTpj3Wiu.o0ZkXVq1wc7A7BuzF6KO5c.AZU7bo52INEwW08dc9Ke6r1 WOFR8aYGHT17UFQVMdKgYyzuUG3oig5oFlk23DRxBY1yfAk2uWmtDWHjmm6RNNvyQ_jXqBnPUR5t nRqqpXKAjL3eyCbJRvUxVH01UqU4MZOtXOL8prPoA.O6A3KnCQ0chtMn0d1i3RvXl4ls2nveBQ9R VtlmRCtULaj6JU2naM.seSOVdr2DruND44jJywiq2dcRUtCMVmEaQvLFgNEy9USzHUwOX6TTFmmU qf_pXjnud.PxDtaTQXqqJ_zykmxiVShzXAe_6_gx0eMvc9odMSfB7K_7gW3YyR0BHKib_MU5ggpT nxmYO_AaK2HRRFCoRAHJF Received: by 66.196.81.119; Mon, 29 Dec 2014 17:46:17 +0000 Date: Mon, 29 Dec 2014 17:46:16 +0000 (UTC) From: Bill Mills To: "oauth@ietf.org" Message-ID: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2328532_1081559356.1419875176756" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kyizotDpcPbIzX8LjY2vUGEwjkk Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:46:20 -0000 ------=_Part_2328532_1081559356.1419875176756 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No other comments on this? =C2=A0Any "It's ready to go."?=20 On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk w= rote: =20 Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben ---------- Forwarded message ---------- Date: Mon, 15 Dec 2014 12:14:30 -0500 From: Benjamin Kaduk To: kitten@ietf.org Cc: kitten-chairs@tools.ietf.org Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 This message begins the fourth Working Group Last Call (WGLC) of "A set of SASL Mechanisms for OAuth" .=C2=A0 Due= to the overlap of the last call period with holidays, the duration of the WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Because the changes between -15 and -18 involve behavior changes, including changes regarding discovery and dynamic registration, the Chairs decided to issue an additional last call. Please review the document and send comments to the Working Group mailing list < kitten at itef.org > or the co-chairs < kitten-chairs at tools.ietf.org > before the end of the WGLC.=C2=A0 Any and all comments on the document are sought in order to access the strength of consensus.=C2=A0 Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again.=C2=A0 This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_2328532_1081559356.1419875176756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No = other comments on this?  Any "It's ready to go."?


On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk <kaduk@MIT.EDU&= gt; wrote:


Hi a= ll,

There may be some interested parties over here; please feel free= to chime
in on this WGLC over on the kitten list.

-Ben

--= -------- Forwarded message ----------
Date: Mon, 15 Dec 2014 12:14:30 -0= 500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
Cc: <= a ymailto=3D"mailto:kitten-chairs@tools.ietf.org" href=3D"mailto:kitten-cha= irs@tools.ietf.org">kitten-chairs@tools.ietf.org
Subject: [kitten] W= GLC of draft-ietf-kitten-sasl-oauth-18

This message begins the fourt= h Working Group Last Call (WGLC) of "A set of
SASL Mechanisms for OAuth"= <draft-ietf-kitten-sasl-oauth-18.txt>.  Due to
the overlap o= f the last call period with holidays, the duration of the
WGLC is extend= ed to four weeks, so the WGLC will end on 12 January 2015.
The draft is = available at:

https://tools.ietf.org/html/draft-ietf-= kitten-sasl-oauth-18

Because the changes between -15 and -18 inv= olve behavior changes,
including changes regarding discovery and dynamic= registration, the Chairs
decided to issue an additional last call.
<= br>Please review the document and send comments to the Working Group
mai= ling list < kitten at itef.org > or the co-chairs < kitten-chairs<= br>at tools.ietf.org > before the end of the WGLC.  Any and all com= ments
on the document are sought in order to access the strength of
c= onsensus.  Even if you have read and commented on this or earlier
v= ersions of the draft, please feel free to comment again.  This is
p= articularly important if you found issues with the previous version.
As a reminder, comments can be anything from "this looks fine" to
"this= is a horrible idea"; they can include suggestions for minor
editorial c= orrections to significant editorial changes.


- Your Kitten Chair= s

_______________________________________________
Kitten mailing = list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten<= br>
_______________________________________________
OAuth mailing lis= t
OA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
------=_Part_2328532_1081559356.1419875176756-- From nobody Mon Dec 29 09:59:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E91A8884 for ; Mon, 29 Dec 2014 09:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxLOLMAgiayQ for ; Mon, 29 Dec 2014 09:58:58 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 690F91A00DF for ; Mon, 29 Dec 2014 09:58:58 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E258342E10C; Mon, 29 Dec 2014 12:58:57 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id D6D2642E0F1; Mon, 29 Dec 2014 12:58:57 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.143]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Mon, 29 Dec 2014 12:58:57 -0500 From: "Richer, Justin P." To: Bill Mills Thread-Topic: [OAUTH-WG] [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 Thread-Index: AQHQI5EdZH17H5Xz2USf67cTGmlEtQ== Date: Mon, 29 Dec 2014 17:58:57 +0000 Message-ID: <660CF6F3-8BB3-4C60-8C3B-1426ABF87AE8@mitre.org> References: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> In-Reply-To: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_660CF6F38BB34C608C3B1426ABF87AE8mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fepOu8zthowl4U0X4DIOtFJe8ME Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:59:01 -0000 --_000_660CF6F38BB34C608C3B1426ABF87AE8mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read this over a little while ago, and I think it's ready to go. The a= ctual core mechanism is pretty straight forward. -- Justin On Dec 29, 2014, at 12:46 PM, Bill Mills > wrote: No other comments on this? Any "It's ready to go."? On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk > wrote: Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben ---------- Forwarded message ---------- Date: Mon, 15 Dec 2014 12:14:30 -0500 From: Benjamin Kaduk > To: kitten@ietf.org Cc: kitten-chairs@tools.ietf.org Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 This message begins the fourth Working Group Last Call (WGLC) of "A set of SASL Mechanisms for OAuth" . Due to the overlap of the last call period with holidays, the duration of the WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Because the changes between -15 and -18 involve behavior changes, including changes regarding discovery and dynamic registration, the Chairs decided to issue an additional last call. Please review the document and send comments to the Working Group mailing list < kitten at itef.org > or the co-chairs < kit= ten-chairs at tools.ietf.org > before the end of the WGLC. Any= and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ 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 --_000_660CF6F38BB34C608C3B1426ABF87AE8mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable I've read this over a little while ago, and I think it's ready to go. The a= ctual core mechanism is pretty straight forward. 

 -- Justin

On Dec 29, 2014, at 12:46 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

No other comments= on this?  Any "It's ready to go."?


On Monday, December 15, 20= 14 9:34 AM, Benjamin Kaduk <kaduk@MIT.E= DU> wrote:


Hi all,

There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list.

-Ben

---------- Forwarded message ----------
Date: Mon, 15 Dec 2014 12:14:30 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: k= itten@ietf.org
Cc: kitten-chairs@tools.ietf.org
Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

This message begins the fourth Working Group Last Call (WGLC) of "A se= t of
SASL Mechanisms for OAuth" <draft-ietf-kitten-sasl-oauth-18.txt>= .  Due to
the overlap of the last call period with holidays, the duration of the
WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18<= /a>

Because the changes between -15 and -18 involve behavior changes,
including changes regarding discovery and dynamic registration, the Chairs<= br> decided to issue an additional last call.

Please review the document and send comments to the Working Group
mailing list < kitten at itef.org > o= r the co-chairs < kitten-chairs
at tools.ietf.org > before the end= of the WGLC.  Any and all comments
on the document are sought in order to access the strength of
consensus.  Even if you have read and commented on this or earlier
versions of the draft, please feel free to comment again.  This is
particularly important if you found issues with the previous version.

As a reminder, comments can be anything from "this looks fine" to=
"this is a horrible idea"; they can include suggestions for minor=
editorial corrections to significant editorial changes.


- Your Kitten Chairs

_______________________________________________
Kitten mailing list
Kitte= n@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten

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


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

--_000_660CF6F38BB34C608C3B1426ABF87AE8mitreorg_-- From nobody Mon Dec 29 10:01:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B18D1A8973 for ; Mon, 29 Dec 2014 10:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dd6y3-W5G9r for ; Mon, 29 Dec 2014 10:01:05 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A311A88A8 for ; Mon, 29 Dec 2014 10:01:04 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id a13so816236igq.5 for ; Mon, 29 Dec 2014 10:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3OCulrex48wRIExg6fhE7TydHF1c+sv8haRI2Ha1wjw=; b=QGtp5xfRIX+VZtdXDKYIDrIoNuHSe6hbumnBw9NyLrEhlYIu5GSKgqQ7POUX3hKgfZ gT0NOjbpkw07+WheSqSqZ5Ic38Xbv05/htufYvDgJc4h/xuhb2BkEag9darfdWnp7uWT UVBSKmfWtc5lP+5cUXTKSYmRqBb4affIrP+tPI599Yu0LvECA2thHFmtuYzx1f8C4Lk2 juGWFpxJb0KBZI33ObrHN9uwxQrjp5grNxiPd94P7K1ZzeNHIX7WwWLYNmM4EJ53ZsM4 nG7Zz3/BbhRpAkKG04xXlYlWluuzwjFZMPjApGdB94jP2VubDfEU2WFoVYtLiQPQSH3I P1Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3OCulrex48wRIExg6fhE7TydHF1c+sv8haRI2Ha1wjw=; b=eeJ3lW2tZjSN8muby+Uennmi/K9Dm8zLZy/DMV3NlWEP4A9xpoRNAp/fR7HggUYbSD BZPM+k3Ozjpct4gpzL/Cny4sqgPO31SoHz/f2ZaGZmWSxDg/C8e6fDOo/nsyT1APFNls vLcUcAvFphIIG43769XB4a5aXYl4HJRoaiAd/0RDX8pFDed0QymRnwHoEkFyr68b+pCl 9f1OFHFxp/PDCJsn/flZul34QqRkbwjXwIK21zr2bWx/ruGBW+74b675Ws2LWJEkk2U8 YLV5ImYaCWXkS5HHGIFbwqVG0bCm9dAzO0XFVTcevybToqMV74C48YI9KdCEUo2syTsi yFTg== X-Gm-Message-State: ALoCoQl9dxkjrYq4WMGVf749K9cMMc+AVYNhYjWosGY71NDGH1Mq2lZdRoJ3qNxPMxb5tn6mQ+aA X-Received: by 10.50.148.101 with SMTP id tr5mr46421834igb.12.1419876063682; Mon, 29 Dec 2014 10:01:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.168.134 with HTTP; Mon, 29 Dec 2014 10:00:32 -0800 (PST) In-Reply-To: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> References: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= Date: Mon, 29 Dec 2014 12:00:32 -0600 Message-ID: To: Bill Mills Content-Type: multipart/alternative; boundary=001a1134c7bc66c435050b5ea831 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dnWUoSzVV4GmMMYb8Z7DmWSAu44 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 18:01:06 -0000 --001a1134c7bc66c435050b5ea831 Content-Type: text/plain; charset=UTF-8 Still looks good to me. On Mon, Dec 29, 2014 at 11:46 AM, Bill Mills wrote: > No other comments on this? Any "It's ready to go."? > > > On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk > wrote: > > > Hi all, > > There may be some interested parties over here; please feel free to chime > in on this WGLC over on the kitten list. > > -Ben > > ---------- Forwarded message ---------- > Date: Mon, 15 Dec 2014 12:14:30 -0500 > From: Benjamin Kaduk > To: kitten@ietf.org > Cc: kitten-chairs@tools.ietf.org > Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 > > This message begins the fourth Working Group Last Call (WGLC) of "A set of > SASL Mechanisms for OAuth" . Due to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. > The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 > > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, the Chairs > decided to issue an additional last call. > > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.ietf.org > before the end of the WGLC. Any and all comments > on the document are sought in order to access the strength of > consensus. Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again. This is > particularly important if you found issues with the previous version. > > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. > > > - Your Kitten Chairs > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > 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 > > --001a1134c7bc66c435050b5ea831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Still looks good to me.
On Mon, Dec 29, 2014 at 11:46 AM, Bill Mills <= span dir=3D"ltr"><wmills_92105@yahoo.com> wrote:
No other comments on this?=C2=A0 Any "It= 9;s ready to go."?


On Mond= ay, December 15, 2014 9:34 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
=

Hi all,

There may be some interested parties over here= ; please feel free to chime
in on this WGLC over on the kitten list.
=
-Ben

---------- Forwarded message ----------
Date: Mon, 15 De= c 2014 12:14:30 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
Cc: kitten-chairs@tools.ietf= .org
Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18
This message begins the fourth Working Group Last Call (WGLC) of "A = set of
SASL Mechanisms for OAuth" <draft-ietf-kitten-sasl-oauth-= 18.txt>.=C2=A0 Due to
the overlap of the last call period with holida= ys, the duration of the
WGLC is extended to four weeks, so the WGLC will= end on 12 January 2015.
The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18

Be= cause the changes between -15 and -18 involve behavior changes,
includin= g changes regarding discovery and dynamic registration, the Chairs
decid= ed to issue an additional last call.

Please review the document and = send comments to the Working Group
mailing list < kitten at itef.org > or the co-chairs &= lt; kitten-chairs
at tools.ietf.org > before the end of the WGLC.=C2=A0 Any and all comm= ents
on the document are sought in order to access the strength of
co= nsensus.=C2=A0 Even if you have read and commented on this or earlier
ve= rsions of the draft, please feel free to comment again.=C2=A0 This is
pa= rticularly important if you found issues with the previous version.

= As a reminder, comments can be anything from "this looks fine" to=
"this is a horrible idea"; they can include suggestions for m= inor
editorial corrections to significant editorial changes.


= - Your Kitten Chairs

_______________________________________________=
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

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



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


--001a1134c7bc66c435050b5ea831-- From nobody Tue Dec 30 03:54:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFB51A0079 for ; Tue, 30 Dec 2014 03:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.449 X-Spam-Level: * X-Spam-Status: No, score=1.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhQ6JWKwGw2Y for ; Tue, 30 Dec 2014 03:54:37 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A631A0077 for ; Tue, 30 Dec 2014 03:54:36 -0800 (PST) Received: from [79.253.20.61] (helo=[192.168.71.100]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y5vNi-00023V-N8; Tue, 30 Dec 2014 12:54:34 +0100 Message-ID: <54A29277.8010903@lodderstedt.net> Date: Tue, 30 Dec 2014 12:54:31 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?IkphbWllIE5pY29sc29uICjlgKrlv5fmmI4pIg==?= , Bill Mills References: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080803090606070607040705" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BFVA9Uw0HQVW2ZcPZ992jfO1__s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 11:54:40 -0000 This is a multi-part message in MIME format. --------------080803090606070607040705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I think the document is ready to go. Am 29.12.2014 um 19:00 schrieb Jamie Nicolson (倪志明): > Still looks good to me. > > On Mon, Dec 29, 2014 at 11:46 AM, Bill Mills > wrote: > > No other comments on this? Any "It's ready to go."? > > > On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk > > wrote: > > > Hi all, > > There may be some interested parties over here; please feel free > to chime > in on this WGLC over on the kitten list. > > -Ben > > ---------- Forwarded message ---------- > Date: Mon, 15 Dec 2014 12:14:30 -0500 > From: Benjamin Kaduk > > To: kitten@ietf.org > Cc: kitten-chairs@tools.ietf.org > Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 > > This message begins the fourth Working Group Last Call (WGLC) of > "A set of > SASL Mechanisms for OAuth" . > Due to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January > 2015. > The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 > > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, > the Chairs > decided to issue an additional last call. > > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the > co-chairs < kitten-chairs > at tools.ietf.org > before the end of the > WGLC. Any and all comments > on the document are sought in order to access the strength of > consensus. Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again. This is > particularly important if you found issues with the previous version. > > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. > > > - Your Kitten Chairs > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > 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 --------------080803090606070607040705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I think the document is ready to go.

Am 29.12.2014 um 19:00 schrieb Jamie Nicolson (倪志明):
Still looks good to me.

On Mon, Dec 29, 2014 at 11:46 AM, Bill Mills <wmills_92105@yahoo.com> wrote:
No other comments on this?  Any "It's ready to go."?


On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


Hi all,

There may be some interested parties over here; please feel free to chime
in on this WGLC over on the kitten list.

-Ben

---------- Forwarded message ----------
Date: Mon, 15 Dec 2014 12:14:30 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
Cc: kitten-chairs@tools.ietf.org
Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

This message begins the fourth Working Group Last Call (WGLC) of "A set of
SASL Mechanisms for OAuth" <draft-ietf-kitten-sasl-oauth-18.txt>.  Due to
the overlap of the last call period with holidays, the duration of the
WGLC is extended to four weeks, so the WGLC will end on 12 January 2015.
The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18

Because the changes between -15 and -18 involve behavior changes,
including changes regarding discovery and dynamic registration, the Chairs
decided to issue an additional last call.

Please review the document and send comments to the Working Group
mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
at tools.ietf.org > before the end of the WGLC.  Any and all comments
on the document are sought in order to access the strength of
consensus.  Even if you have read and commented on this or earlier
versions of the draft, please feel free to comment again.  This is
particularly important if you found issues with the previous version.

As a reminder, comments can be anything from "this looks fine" to
"this is a horrible idea"; they can include suggestions for minor
editorial corrections to significant editorial changes.


- Your Kitten Chairs

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
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

--------------080803090606070607040705-- From nobody Tue Dec 30 05:28:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823311A00AE for ; Tue, 30 Dec 2014 05:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zfyLPMJemt9 for ; Tue, 30 Dec 2014 05:28:01 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1D41A00AA for ; Tue, 30 Dec 2014 05:28:01 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id c9so10456078qcz.33 for ; Tue, 30 Dec 2014 05:28:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zRP0H91lHNyQC1IuLCJiXKdGx+kJlLRMp3Zq7czyHOc=; b=jtrZ7b5nnG7RwpB0wZWJdcIhEi3ASS8dxc2c+mWDnEWvOB4/fdNjGd6uIslkWOf0B7 ZeSYwMS5OPGCCvyUdXgIeH5FGGWPiqOqvDPL93WsV05c/biIzNOi+Pk8js2fTA9cZfVA szo8g+XwA10i9x41chs8CjT4GER/A2lrupNWMbiygf8Mff4pMoWIkWYv8wOjA3XWvw6v wFPHOZnHgX8jygze74y50tSkuCv5c9qgnksqGpMO7KsPzdVi9cV9ggLxtK7VUI/cU9WO bCad6gXKKs656HXwTByigJDDli7doay0eUsYmToxpCpUX9PZb4j1T2M+UnGcLOQoSjxt pQ/w== X-Gm-Message-State: ALoCoQmP9O6mtYXdFN2ztHcUrXNjVagsnOUCtZqtfHXXXhS6M/JrFDXrXEK03/oHcIIiuTxCFq3o X-Received: by 10.224.37.5 with SMTP id v5mr102306183qad.25.1419946080535; Tue, 30 Dec 2014 05:28:00 -0800 (PST) Received: from [192.168.1.33] (186-79-119-124.baf.movistar.cl. [186.79.119.124]) by mx.google.com with ESMTPSA id o43sm19515033qge.31.2014.12.30.05.27.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 05:27:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B440) In-Reply-To: Date: Tue, 30 Dec 2014 10:27:55 -0300 Content-Transfer-Encoding: 7bit Message-Id: <36433644-59A7-4E02-A841-AEC3D0087BD6@ve7jtb.com> References: To: Benjamin Kaduk Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qK51qBQGz2zSPhn3a3oKngol7Lc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 13:28:03 -0000 I have been tracking it. It is ready. Sent from my iPhone > On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk wrote: > > Hi all, > > There may be some interested parties over here; please feel free to chime > in on this WGLC over on the kitten list. > > -Ben > > ---------- Forwarded message ---------- > Date: Mon, 15 Dec 2014 12:14:30 -0500 > From: Benjamin Kaduk > To: kitten@ietf.org > Cc: kitten-chairs@tools.ietf.org > Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 > > This message begins the fourth Working Group Last Call (WGLC) of "A set of > SASL Mechanisms for OAuth" . Due to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. > The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 > > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, the Chairs > decided to issue an additional last call. > > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.ietf.org > before the end of the WGLC. Any and all comments > on the document are sought in order to access the strength of > consensus. Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again. This is > particularly important if you found issues with the previous version. > > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. > > > - Your Kitten Chairs > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Dec 30 12:37:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1FC1A1BB0 for ; Tue, 30 Dec 2014 12:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD2YNMAkvOpJ for ; Tue, 30 Dec 2014 12:37:22 -0800 (PST) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F25E1A1BBC for ; Tue, 30 Dec 2014 12:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419971841; bh=fyK8PO6d0mLTPjFsOy0SFITiiHmOaPnD5BJRuEHhUSI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WPH03c/JE8drvtC7pleIRKW25Q4F7dqvPdYNtXmAWESZaej7jVZvohgrpbSkqnuBzMbX3u/vY2iUgRwUMCkubhcvnhKR4iM3iADtPYOf4FBuGXy83xCZ4tvythedz1wjgW+2v3gqCCOLMH0uyF08rub4HCn4NJKCgtlbSg6/q77Bym4Btw7WVuXq+5Jzy6zCbQILy2f7ziUKCcijkUMfLTwHY0n9SufBD4K0VZVCUEcaZdYHpL+FJDrmq6htJUUEbcSoascWJRMo8EDQVvpNuDqGKl4X7X0VtqE21orjZ1u+3nnVnCxwFGr+913scZpUKsf0OQkflFDa8+0p+5xAzw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=gDJFBYI/dUCmBPOZaVCO9hXzntdmpUOhRyarL2iDuHdlCjkLf+w+kzt4w36SnghgnIhXZCa2DDwz7flPBdPf5HH1TzhLcUi+jNrUI71FpS/0OHnNQtz40H3MmG1fRqz5PShH6OtYAt80FKDp1FymeWY5cA6SjRnYbMpgonHQGjYtIx/1u972YKOLBdYHCqbJradt0DXRTUUDc7QMB1x1YuttuO1is1c/KOM56HrXwrdRn6a6z3kKYjHbUpHy09wrABPSfheS+AAIxNINOjbVwH0PWaZq+I2xyAm+tNNV2B5HcMvhxsnVX5Fzoo4P9XDzFmW1IZ8Mi16jGTIFfjrvRw==; Received: from [98.139.215.142] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:37:21 -0000 Received: from [98.139.212.213] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:37:21 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:37:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 462289.18148.bm@omp1022.mail.bf1.yahoo.com X-YMail-OSG: OScJcKMVM1mZkqJB9kg0_EQbJyHG9IdDFGHe64_3dUs6XFyE7QCUuaKxjAY9tuF WlL07Fax9DhLJuRl0YgBdDzkXv0pl4cTND8f0EErXeCskYQxAzKgfKVAty7IBg5j3KZ1ld.ue5Cd 5h0Bh2vmzwi2J7x_MwXg6KTWwRl6BaOvWg1dhfff8azs5Aen1wAnFidsgMHV_SHeXwHUD.Mzg_C0 xkJz1E8miDHJKVhQlt._zyC1_xM5rp._JJXnaGHd3cvFrkycbWh3f.v8jUX63zxoy5oKXRYi2gbg aI7MS5Yt7jalhOrJqXvPEXmXQP6j0RVU1krvrHxdJ5iz0W0QMsnUftLl4fyaiBiJqzcB0bpbBxl_ wLddW55n89yFtASOXt8PXVgc1sSIJnAs44sQk9jM1GMEPd0MJZCynoevKe8iaJGUzJjoviG7J4DU kIQBiyU1HFLqQ7n2LZH.DxktGcPPHg4ziFgponcX.kuI9EX_afYMCRvStWPnByQmK38ctjrOsXtr AoR3SUjlSP4mYQbL5WyrwZ9Lox8VmLQGaHusQCQkq.bd9gf8GylkeIvyH5whGMYUS0wiB7gOCkyr PhH_CMjbISLR2mVNDmTPR Received: by 66.196.80.147; Tue, 30 Dec 2014 20:37:21 +0000 Date: Tue, 30 Dec 2014 20:37:20 +0000 (UTC) From: Bill Mills To: John Bradley , Benjamin Kaduk Message-ID: <1032414067.649954.1419971840703.JavaMail.yahoo@jws10650.mail.bf1.yahoo.com> In-Reply-To: <36433644-59A7-4E02-A841-AEC3D0087BD6@ve7jtb.com> References: <36433644-59A7-4E02-A841-AEC3D0087BD6@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_649953_1040353980.1419971840699" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ThYwnLlJfrvMO958q4m-t9nOwrU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 20:37:24 -0000 ------=_Part_649953_1040353980.1419971840699 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you both for the feedback.=20 On Tuesday, December 30, 2014 5:28 AM, John Bradley wrote: =20 I have been tracking it.=C2=A0 It is ready.=20 Sent from my iPhone > On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk wrote: >=20 > Hi all, >=20 > There may be some interested parties over here; please feel free to chime > in on this WGLC over on the kitten list. >=20 > -Ben >=20 > ---------- Forwarded message ---------- > Date: Mon, 15 Dec 2014 12:14:30 -0500 > From: Benjamin Kaduk > To: kitten@ietf.org > Cc: kitten-chairs@tools.ietf.org > Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 >=20 > This message begins the fourth Working Group Last Call (WGLC) of "A set o= f > SASL Mechanisms for OAuth" .=C2=A0 D= ue to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. > The draft is available at: >=20 > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 >=20 > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, the Chair= s > decided to issue an additional last call. >=20 > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.ietf.org > before the end of the WGLC.=C2=A0 Any and all comment= s > on the document are sought in order to access the strength of > consensus.=C2=A0 Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again.=C2=A0 This is > particularly important if you found issues with the previous version. >=20 > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. >=20 >=20 > - Your Kitten Chairs >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=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 ------=_Part_649953_1040353980.1419971840699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you both for the feedback= .


= On Tuesday, December 30, 2014 5:28 AM, Joh= n Bradley <ve7jtb@ve7jtb.com> wrote:


I have been tracking it.  It is ready.
Sent from my iPhone
> On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>= ; Hi all,
>
> There may be some = interested parties over here; please feel free to chime
&= gt; in on this WGLC over on the kitten list.
>
> -Ben
>
> ------= ---- Forwarded message ----------
> Date: Mon, 15 Dec = 2014 12:14:30 -0500
> From: Benjamin Kaduk <k= aduk@MIT.EDU>
> To: kitten@ietf.org=
> Cc: kitten-= chairs@tools.ietf.org
> Subject: [kitten] WGLC of = draft-ietf-kitten-sasl-oauth-18
>
&= gt; This message begins the fourth Working Group Last Call (WGLC) of "A set= of
> SASL Mechanisms for OAuth" <draft-ietf-kitten= -sasl-oauth-18.txt>.  Due to
> the overlap of = the last call period with holidays, the duration of the
&= gt; WGLC is extended to four weeks, so the WGLC will end on 12 January 2015= .
> The draft is available at:
> =
> https://tools.ietf.or= g/html/draft-ietf-kitten-sasl-oauth-18
>
> Because the changes between -15 and -18 involve behavior cha= nges,
> including changes regarding discovery and dyna= mic registration, the Chairs
> decided to issue an add= itional last call.
>
> Please re= view the document and send comments to the Working Group
= > mailing list < kitten at itef.org > or the co-chairs < kitten= -chairs
> at tools.ietf.org > before the end of the= WGLC.  Any and all comments
> on the document ar= e sought in order to access the strength of
> consensu= s.  Even if you have read and commented on this or earlier
> versions of the draft, please feel free to comment again. = This is
> particularly important if you found issues = with the previous version.
>
> A= s a reminder, comments can be anything from "this looks fine" to
> "this is a horrible idea"; they can include suggestions for = minor
> editorial corrections to significant editorial= changes.
>
>
> - Your Kitten Chairs
>
> _= ______________________________________________
> Kitte= n mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten=
>
> _______________________= ________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


____________= ___________________________________
OAuth mailing listOAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

------=_Part_649953_1040353980.1419971840699--