From internet-drafts@ietf.org Mon Oct 7 02:12:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC121E81AE; Mon, 7 Oct 2013 02:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYjpbrKpX-JQ; Mon, 7 Oct 2013 02:12:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0277C21E81B6; Mon, 7 Oct 2013 02:12:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007091251.16131.1618.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 02:12:51 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:12:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-12.txt Pages : 29 Date : 2013-10-07 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 suggested pronunciation of JWT is the same as the English word "jot". 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-12 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 Michael.Jones@microsoft.com Mon Oct 7 02:18:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AC921E81BA; Mon, 7 Oct 2013 02:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuwJs-jLnkSl; Mon, 7 Oct 2013 02:18:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id E042821E81AC; Mon, 7 Oct 2013 02:18:45 -0700 (PDT) Received: from BLUPR03CA033.namprd03.prod.outlook.com (10.141.30.26) by BLUPR03MB615.namprd03.prod.outlook.com (10.255.124.43) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 7 Oct 2013 09:18:43 +0000 Received: from BL2FFO11FD035.protection.gbl (2a01:111:f400:7c09::181) by BLUPR03CA033.outlook.office365.com (2a01:111:e400:879::26) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Mon, 7 Oct 2013 09:18:43 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD035.mail.protection.outlook.com (10.173.161.131) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Mon, 7 Oct 2013 09:18:42 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.157]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Mon, 7 Oct 2013 09:18:01 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" Thread-Topic: JOSE -17 and JWT -12 drafts reducing duplicated text Thread-Index: Ac7DPhttADpa682eRzmShk0jc0ZtBA== Date: Mon, 7 Oct 2013 09:18:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394376D7E79A@TK5EX14MBXC290.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.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394376D7E79ATK5EX14MBXC290r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(74366001)(74876001)(20776003)(63696002)(74706001)(77982001)(80022001)(65816001)(46102001)(79102001)(19300405004)(66066001)(83072001)(512954002)(81542001)(15975445006)(31966008)(54356001)(71186001)(74662001)(69226001)(77096001)(33656001)(74502001)(56776001)(47446002)(54316002)(84326002)(76482001)(80976001)(4396001)(49866001)(50986001)(47976001)(19580395003)(51856001)(16236675002)(59766001)(44976005)(81816001)(15202345003)(81342001)(53806001)(85306002)(83322001)(76796001)(81686001)(76786001)(6806004)(76176001)(47736001)(56816003)(55846006)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB615; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09928BEC91 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [OAUTH-WG] JOSE -17 and JWT -12 drafts reducing duplicated text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:18:55 -0000 --_000_4E1F6AAD24975D4BA5B168042967394376D7E79ATK5EX14MBXC290r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON Object Signing and Encryption (JOSE) -17 and JSON Web Token (JWT) -12 = drafts have been published with editorial changes that reduce duplicated te= xt between the JOSE specs. Also, the "typ" and "cty" header parameters wer= e revised to always refer to media type values. The text about which seria= lizations are mandatory to implement was updated. Finally, thanks to Matt = Miller for supplying an encryption example using PBES2. See the Document History appendices for more details on the changes made an= d issues addressed. The drafts are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-17 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-17 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-17 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-17= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-1= 7.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-17.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-1= 7.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-12.ht= ml -- Mike --_000_4E1F6AAD24975D4BA5B168042967394376D7E79ATK5EX14MBXC290r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON Object Signing and Encryption (JOSE) -17 and JS= ON Web Token (JWT) -12 drafts have been published with editorial changes th= at reduce duplicated text between the JOSE specs.  Also, the “ty= p” and “cty” header parameters were revised to always refer to media type values.  The text about which serializatio= ns are mandatory to implement was updated.  Finally, thanks to Matt Mi= ller for supplying an encryption example using PBES2.

 

See the Document History appendices for more details= on the changes made and issues addressed.

 

The drafts are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-17

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-17

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-17

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-17

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-12

 

HTML formatted versions are also available at:<= /o:p>

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-17.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-17.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-17.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-17.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-12.html

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394376D7E79ATK5EX14MBXC290r_-- From bcampbell@pingidentity.com Mon Oct 7 05:48:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0CE21E81E0 for ; Mon, 7 Oct 2013 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kjyaJ+8iGjW for ; Mon, 7 Oct 2013 05:48:44 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id A3E8721E8092 for ; Mon, 7 Oct 2013 05:48:42 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKUlKtqWr2wYLW1NRACun34JF3RqbMhKNK@postini.com; Mon, 07 Oct 2013 05:48:42 PDT Received: by mail-ie0-f177.google.com with SMTP id qd12so14802370ieb.8 for ; Mon, 07 Oct 2013 05:48:41 -0700 (PDT) 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=PV5xrGkNP9Ny5u3QzJMYf88gkJ/DnjrfyoUl+Lr36Ns=; b=lD84DNALNEtA+pIqrv1C6SdAX4+ESuloIpJKlVLCDZT0cwgRrHqmo/X9OEhr06IuTC SZkz2JxvsMWyatYCrCMs/qWq8siGD6HWCOehUhMAMItVSnF7Uf3JkU5w4t4hxjM+HvLW QjCzOMAZLwWFn995uyFMyDhoc0hrTmLCUZw67wFBVmePk/xjikxzFXmIzqkwU1nbhtmK vBL/BIPiwcFxDboOuaezNEFnCztlMAES4AmhRA3kMO6ZthmMtIWEsnjMtbH4V0By6MYq WcLhrixCIregFimD5jCymple1fqmAwEpXNNZfbzsKJWAgLCLuqbrpbQ6n9jvMr5Wlm5V u1pw== X-Gm-Message-State: ALoCoQnuHlgmd8rrt98XuK5J2G+vzoMq2/VxeBCviEZ9cjobQ96OoIAhcGs+bak/rt8I5LSgyTlc1+Lttx5YfUEWKc44Vur/lx2XtyKSdz32yFBNxqwVv0iTEZriGg37YiH4x7UJoUwXpNme3VszYQqJQkqqUPCGqg== X-Received: by 10.50.118.105 with SMTP id kl9mr16982618igb.3.1381150121543; Mon, 07 Oct 2013 05:48:41 -0700 (PDT) X-Received: by 10.50.118.105 with SMTP id kl9mr16982607igb.3.1381150121370; Mon, 07 Oct 2013 05:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.232.229 with HTTP; Mon, 7 Oct 2013 05:48:11 -0700 (PDT) In-Reply-To: <5246DB60.7080109@lodderstedt.net> References: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> <5246DB60.7080109@lodderstedt.net> From: Brian Campbell Date: Mon, 7 Oct 2013 05:48:11 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=089e011769cf5dd64204e8261221 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:48:50 -0000 --089e011769cf5dd64204e8261221 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review and feedback, Torsten, and apologies for the slow reply. Responses to your questions are inline below and in some cases have additional questions for you and/or the WG at large. On Sat, Sep 28, 2013 at 7:36 AM, Torsten Lodderstedt wrote: > Hi all, > > here are my comments: > > --- Assertion Draft --- > > section 4.1. > > "Authentication of the client is optional, as described in Section > 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is > only needed when a form of client authentication that relies on the > parameter is used." > > I'm a bit confused about this statement because RFC6749, Section 3.2.1. > states: > "Confidential clients or other clients issued client credentials MUST > authenticate with the authorization server as described in > Section 2.3 when making requests to the token endpoint." > > The client_id is optional but recommended for public clients, only. Same > text can be found in SAML/section 2.1 and JWT/section 2.1 > > The text is intended to convey that the client_id parameter is not, in general, required when doing SAML/JWT as an authorization grant. It will, for example, be omitted in the case of an anonymous client. It also isn't used for any "confidential" client where the client authentication method doesn't use client_id. HTTP Basic and the assertion based client authentication methods all work without using client_id. And one could imagine, for example, that a mutual TLS based client authentication method also wouldn't use client_id. Maybe another way to put it is - authorization grants don't know or care about the client_id so it only comes into play when the client is using an authentication or identification method that itself uses the client_id parameter. Does that help explain things? How do you think it could be clarified? > section 5.1. > > "the Issuer should identify the STS in a manner recognized by the > Authorization Server." > > Shouldn't the "should" be normative language? I would even prefer MUST > instead of should. > The STS is basically a conceptual entity in this document and not one of the direct protocol participants. As such, it didn't seem appropriate to try and say normative things about it. That text is intended to be more explanatory than normative or prescriptive. > > "Issuer values SHOULD be compared using the Simple String Comparison" - > better MUST? > I'd be okay making that a MUST as well as the corresponding text in JWT and SAML. I honestly can't recall why it's just a should for issuer. I believe there is need for flexibly in some of the identifiers in these docs but I'm not seeing the need with respect to issuer. But perhaps someone else has a better memory about that? What do other WG folks think about this? > > "When using assertions for client authentication, the Subject > MUST identify the client to the authorization server, typically > by using the value of the "client_id" of the OAuth client." > > Why not just "For client authentication, the subject MUST be the > "client_id" of the OAuth client" as in the JWT Bearer and SAML assertion > drafts? > Good question. Looking at the three documents again, I think you are correct and that the text in the base assertion doc should convey the same thing as in the JWT and SAML drafts. Any objections? > > Audience - "The URL of the Token Endpoint, as defined > in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate > that the authorization server as a valid intended audience of the > assertion." > > Who uses this approach? We don't use the concrete URL of the tokens > endpoint but the AS's base URL. I would prefer to have _a_ single, mandated > way of identifying the AS instead of a recommendation in order to > facilitate interop. > Google does for their JWT grant type implementation: https://developers.google.com/accounts/docs/OAuth2ServiceAccount And Ping's SAML grant implementation accepts either the token endpoint URL or the SAML entity id as the audience. Audience is a tricky one, especially in the base assertion document. The general idea here is to say that the assertion needs to have some construct that identifies whom/where it is intended to be consumed. The only identifiers available for an AS are the endpoint URIs. So token endpoint seemed like an option worth mentioning as something that could be used as an audience identifier for an AS. But it seemed to constraining to preclude other identifiers that might be more appropriate for a deployment. SAML, for example, has a pretty well defined use of the entity id as an audience identifier (as well as an additional construct of Recipient, which is similar but more about where than who) but what about an AS that wants to support the SAML profiles independent of a larger deployment? And you've used the AS's base URL, which is a reasonable thing to do, but what about a multi-tenant deployment that might have more than one logical AS beneath the base URL? I understand people's desire to have the audience treatment be more constrained. But I don't know how to get to a single, mandated way of identifying the AS, while accounting for common practices. > > section 6.2 > > Please replace "Client Credentials flow" by "Client Credentials _Grant_" > Will do. > > PLEASE NOTE: most comments on the assertion draft hold for JWT and SAML as > well because a lot of text is duplicated/shared among these drafts. > Noted. When I apply any changes based on your comments, I'll check to see if they apply to the other drafts as well. > --- JWT bearer token --- > > section 4 > > the example request is missing any client identifier/credentials, please > add BASIC header or client_id > That was very much intentional and done to help underscore the earlier point that assertion authorization grants are completely orthogonal to client authentication/identification and can even be done with no client info in the request. I strongly believe it should remain as it is. > > GENERAL NOTE: HTML links referencing to RFC 6749 are generally linked to > the respective drafts itself > > So this is an issue that I've noticed in a number of other drafts as well as these three. I'm not sure if it's a problem with the xml2rfc tooling or user error in how the XML source is being produced or both. Is there anyone more versed in IETF tooling and documents that can provide some guidance on this? Is there a recommended way to do references that will avoid this? Is this something the RFC editor fixes later? Something else? > regards, > Torsten. > > > --089e011769cf5dd64204e8261221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the review and feedback, Torsten, and apologies for the slow reply. Responses to your questi= ons are inline below and in some cases have a= dditional questions for you and/or the WG at = large.


On Sat, Sep 28, 2013 at 7:36 AM, Torsten Lodderstedt <<= span style class=3D"">torsten@lodderstedt.net> wrote:
Hi all,

here are my comments:

--- Assertion Draft ---

section 4.1.

"Authentication of the client is optional, as described in Section
=A0 =A03.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id&q= uot; is
=A0 =A0only needed when a form of client authentication that relies on the<= br> =A0 =A0parameter is used."

I'm a bit confused about this statement because RFC6749, Section 3.2.1.= states:
"Confidential clients or other clients issued client credentials MUST<= br> =A0 =A0authenticate with the authorization server as described in
=A0 =A0Section 2.3 when making requests to the token endpoint."

The client_id is optional but recommended for public clients, only. Same te= xt can be found in SAML/section 2.1 and JWT/section 2.1


The text is intended to convey that th= e client_id parameter is not, in general, required when doing SAML/JWT as an authorization= grant. It will, for example, be omitted in the case of an anonymous client= . It also isn't used for any "confidential" client where the = client authentication method doesn't use client_id. HTTP Basic and the = assertion based client authentication methods all work without using client= _id. And one could imagine, for example, that a mutual TLS based client authentication method also wouldn't use clie= nt_id.

Maybe another way to put it is - authorization grants don= 9;t know or care about the client_id so it only comes into play when the cl= ient is using an authentication or identification method that itself uses t= he client_id parameter.

Does that help explain things?

How do you= think it could be clarified?
=A0
section 5.1.

"the Issuer should identify the STS in a manner recognized by the Auth= orization Server."

Shouldn't the "should" be normative language? I would even pr= efer MUST instead of should.

The STS is basically a conceptual entity in this docume= nt and not one of the direct protocol participants. As such, it didn't = seem appropriate to try and say normative things about it. That text is int= ended to be more explanatory than normative or prescriptive.
=A0

"Issuer values SHOULD be compared using the Simple String Comparison&q= uot; - better MUST?

I'd be okay mak= ing that a MUST as well as the corresponding text in JWT and SAML. I honestly can't re= call why it's just a should for issuer. I believe there is need for fle= xibly in some of the identifiers in these docs but I'm not seeing the n= eed with respect to issuer.

But perhaps someone else has a better memory about that?

What d= o other WG folks think about this?
<= div>=A0

"When using assertions for client authentication, the Subject
=A0 =A0 =A0 =A0 =A0MUST identify the client to the authorization server, ty= pically
=A0 =A0 =A0 =A0 =A0by using the value of the "client_id" of the O= Auth client."

Why not just "For client authentication, the subject MUST be the "= ;client_id" of the OAuth client" as in the JWT Bearer and SAML as= sertion drafts?

Good question. Looking at the thre= e documents again, I think you are correct and that the text in the base as= sertion doc should convey the same thing as in the J= WT and SAML drafts.

Any objections?
=A0

Audience - "The URL of the Token Endpoint, as defined
=A0 =A0 =A0 in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate<= br> =A0 =A0 =A0 that the authorization server as a valid intended audience of t= he
=A0 =A0 =A0 assertion."

Who uses this approach? We don't use the concrete URL of the tokens end= point but the AS's base URL. I would prefer to have _a_ single, mandate= d way of identifying the AS instead of a recommendation in order to facilit= ate interop.

Google does for their JWT grant type imple= mentation: https://developers.google.com/accounts/docs/OAuth2ServiceAccou= nt

And Ping's SAML grant implementation accepts either the = token endpoint URL or the SAML entity id as the audience.

Audience is a tricky one, especially in the base assertion document. The = general idea here is to say that the assertion needs to have some construct= that identifies whom/where it is intended to be consumed. The only identif= iers available for an AS are the endpoint URIs. So token endpoint seemed li= ke an option worth mentioning as something that could be used as an audienc= e identifier for an AS.=A0 But it seemed to constraining to preclude other = identifiers that might be more appropriate for a deployment. SAML, for exam= ple, has a pretty well defined use of the entity id as an audience identifi= er (as well as an additional construct of Recipient, which is similar but m= ore about where than who) but what about an AS that wants to support the SA= ML profiles independent of a larger deployment? And you've used the AS&= #39;s base URL, which is a reasonable thing to do, but what about a multi-t= enant deployment that might have more than one logical AS beneath the base = URL?

I understand people's desire to have the audi= ence treatment be more constrained. But I don't know how to get to a si= ngle, mandated way of identifying the AS, while accounting for common pract= ices.=A0

=A0

section 6.2

Please replace "Client Credentials flow" by "Client Credenti= als _Grant_"

Will do.
=A0

PLEASE NOTE: most comments on the assertion draft hold for JWT and SAML as = well because a lot of text is duplicated/shared among these drafts.

Noted. When I apply any changes based on your = comments, I'll check to see if they apply to the other drafts as well.<= br>


--- JWT bearer token ---

section 4

the example request is missing any client identifier/credentials, please ad= d BASIC header or client_id

That was ve= ry much intentional and done to help underscore the earlier point that asse= rtion authorization grants are completely orthogonal to client authenticati= on/identification and can even be done with no client info in the request. = I strongly believe it should remain as it is.
=A0

GENERAL NOTE: HTML links referencing to RFC 6749 are generally linked to th= e respective drafts itself


So this is an issue that I've noti= ced in a number of other drafts as well as these three.

= I'm not sure if it's a problem with the xml2rfc tooling or user err= or in how the XML source is being produced or both.

Is there anyone more versed in IETF tooling and documents that can provide some guidance on this? Is ther= e a recommended way to do references that will avoid this? Is this somethin= g the RFC editor fixes later? Something else?
=A0
regards,
Torsten.



--089e011769cf5dd64204e8261221-- From sunilpal73@gmail.com Mon Oct 7 07:28:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47121F9EC8 for ; Mon, 7 Oct 2013 07:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5PfTuTbNpOc for ; Mon, 7 Oct 2013 07:28:35 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D69C421F9E54 for ; Mon, 7 Oct 2013 07:28:34 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so2701995bkh.11 for ; Mon, 07 Oct 2013 07:28:34 -0700 (PDT) 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=7jtzsXFWJtIw4jrE0jmZG8P6b1OxuzZh1bbwX4RGgTs=; b=0i+Id1hgGdagCBCYxDs54F0+EXcPPlezL40MUjtzMXZ8NdDxFeV0V8uNOejdSI8Oyh 7LqdObQYTCG25ellRzxMu/JnDHI+jWDy4rUPSkG1g1lqt/I8OFLOWkuuVi1z+fj5rYVw UPochW5xVe9nGHmxi+s6tFbzpqe3nmpPpsH5DIO6uDTeXpqV56ksDud6vLZ0W7LeOxCU SMkyh7lYaT7CQJPRf+5Itp4bt+Jp9cHtn/YSd1f524DBddwq8959l8CmFIP6Z06/OkTx VQBGh+szrA3gd5FeY2x8xhrgXe+H29xYC/Glkra4e8dAZFSEzzCPXUHrILqfAt73YjsV NLjA== MIME-Version: 1.0 X-Received: by 10.204.69.12 with SMTP id x12mr26797813bki.12.1381156113776; Mon, 07 Oct 2013 07:28:33 -0700 (PDT) Received: by 10.204.103.3 with HTTP; Mon, 7 Oct 2013 07:28:33 -0700 (PDT) Date: Mon, 7 Oct 2013 19:58:33 +0530 Message-ID: From: Sunil Pal To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a1132ec908ab1e704e827779a Subject: [OAUTH-WG] Google doc with salesforce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:28:35 -0000 --001a1132ec908ab1e704e827779a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Anyone have done integration with salesforce and google. I want to upload files to google drive by using the apex code, by the use of salesforce standard feature i am able to done, but by the use of apex code iam not bale to do. Please help me guys, Thanks --- Thanks And Warm Regards Sunil Kumar Pal --001a1132ec908ab1e704e827779a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
Anyone have done integration with salesforce a= nd google. I want to upload files to google drive by using the apex code, b= y the use of salesforce standard feature i am able to done, but by the use = of apex code iam not bale to do.
Please help me guys,=A0

Thanks
---<= div>
Thanks And Warm Regards
Sunil Kumar Pal=

--001a1132ec908ab1e704e827779a-- From cmortimore@salesforce.com Mon Oct 7 07:57:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF911E8152 for ; Mon, 7 Oct 2013 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb5vy4f4fClr for ; Mon, 7 Oct 2013 07:57:33 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8811E80FB for ; Mon, 7 Oct 2013 07:57:08 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k14so7131853wgh.1 for ; Mon, 07 Oct 2013 07:57:07 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=WgWIqVk9dVxmeHqm4KX/Pbeeo8ytmCb15IUwY5+mi/0=; b=V2PJqTdDqNpMCFDZwJApS681V9urRv26za2FOHQSsMQjfBDXwV3feXUGh0SJHEytTG IxXilK7COjlUXydb5qa/ACQV29Dz9DbT54HOLbRP+mh1QVbLSqDUym59H8XMOaTFfIFJ 1UZHPmXzYFLmx2doIsUUrYJWcGyimbz2zZWMOd+tbZyQVDm0EFTzOK7vqSrlsT1ZRQjw YmrKhpeCfE3rmXL6iFwKooUfRkmruwb6RcHGWt5JxS8N0XvOaV0zsV/zrBBLC6D4lWeZ Ymdo7TQOfSiN0W1URbdN5pftlcGvJTHRnfr1WQ11co3O9eRbrau/gKwjleLNQ9uqkf6F tK1A== X-Gm-Message-State: ALoCoQkJXzhpy74Q+ZMTYdh+EyVbIUtcmHPy7NXowsxA5e5o7wbluIBZ56A0YN1tEP6crMKXL72n MIME-Version: 1.0 X-Received: by 10.194.248.130 with SMTP id ym2mr1883749wjc.61.1381157827154; Mon, 07 Oct 2013 07:57:07 -0700 (PDT) Received: by 10.217.85.200 with HTTP; Mon, 7 Oct 2013 07:57:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 07:57:07 -0700 Message-ID: From: Chuck Mortimore To: Sunil Pal Content-Type: multipart/alternative; boundary=089e013d1442aab0e704e827dd58 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google doc with salesforce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:57:40 -0000 --089e013d1442aab0e704e827dd58 Content-Type: text/plain; charset=ISO-8859-1 This would be more appropriate to ask at http://developer.force.com/ That said, you may want to watch this: http://blogs.developerforce.com/developer-relations/2013/09/login-to-your-salesforce-org-with-openid-connect-in-winter-14.html On Mon, Oct 7, 2013 at 7:28 AM, Sunil Pal wrote: > Hi all, > Anyone have done integration with salesforce and google. I want to upload > files to google drive by using the apex code, by the use of salesforce > standard feature i am able to done, but by the use of apex code iam not > bale to do. > Please help me guys, > > Thanks > --- > Thanks And Warm Regards > Sunil Kumar Pal > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013d1442aab0e704e827dd58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon,= Oct 7, 2013 at 7:28 AM, Sunil Pal <sunilpal73@gmail.com>= wrote:
Hi all,
Anyone have don= e integration with salesforce and google. I want to upload files to google = drive by using the apex code, by the use of salesforce standard feature i a= m able to done, but by the use of apex code iam not bale to do.
Please help me guys,=A0

Thanks
---<= div>
Thanks And Warm Regards
Sunil Kumar Pal=


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


--089e013d1442aab0e704e827dd58-- From ppatterson@salesforce.com Mon Oct 7 10:22:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3444821F9CA5 for ; Mon, 7 Oct 2013 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n0wL4tVaKXA for ; Mon, 7 Oct 2013 10:22:13 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AB11E80F2 for ; Mon, 7 Oct 2013 10:22:08 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so5187602wib.3 for ; Mon, 07 Oct 2013 10:22:08 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=PWUP4oMlOnMWClg3aICDlZqxhjdLrxoWyp7z8zV/lQk=; b=FCIZfGTeIKwXqNd3nidWp9O4acVpBKpLJKZ6YdSjdyRTx99s82y3AsfJ17vhYuSF4v sG2wvGRXBxFX1W3P31Q2vaq35XKIxSZpfMPS4HXZ8Bw9ZV3Z42POTCaCkeKHd/XS6YyX RxQECxHZ0jweDcgCSO079u/EZjc8p4c2MHebD4ThwT0AKddMOW0VfKSxWaoihAMMHYPc p2hnM+sU/WtRBLHlBEKhEP2b7RzLnn1DJy0V+Y+7178gI943S/bQMNsp2IrmMKOH2Uc9 fTMdm96ZaMQf2+QGx0TenAq/GA3LQPbGOW5pZKkk5DLZCIf+tG30qImH1d4RRDP09sXB xniA== X-Gm-Message-State: ALoCoQkLdQxyGWf6hHP1L+P/D/egSMHfuHduUlkGWPL2/96uGBb5lLDgQh6IvFrEVI/BETysTrpJ MIME-Version: 1.0 X-Received: by 10.194.80.39 with SMTP id o7mr3576351wjx.39.1381166527932; Mon, 07 Oct 2013 10:22:07 -0700 (PDT) Received: by 10.194.46.166 with HTTP; Mon, 7 Oct 2013 10:22:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 10:22:07 -0700 Message-ID: From: Pat Patterson To: Sunil Pal Content-Type: multipart/alternative; boundary=047d7bb045c446058804e829e4cb Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google doc with salesforce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:22:17 -0000 --047d7bb045c446058804e829e4cb Content-Type: text/plain; charset=ISO-8859-1 Hi Sunil, What have you tried from Apex so far? Have you asked at either (or both) of boards.developerforce.com or salesforce.stackexchange.com? Those would be better forums for discussion - you should get some help there. If you do post a question, or have already done so, let me know the URL and I'll take a look. I have some code that worked with the Google Contacts API a couple of years ago - I might be able to adapt it to Google Drive. Cheers, Pat -- Pat Patterson | Principal Developer Evangelist | 408-849-4681 | http://about.me/patpatterson On Mon, Oct 7, 2013 at 7:28 AM, Sunil Pal wrote: > Hi all, > Anyone have done integration with salesforce and google. I want to upload > files to google drive by using the apex code, by the use of salesforce > standard feature i am able to done, but by the use of apex code iam not > bale to do. > Please help me guys, > > Thanks > --- > Thanks And Warm Regards > Sunil Kumar Pal > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bb045c446058804e829e4cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sunil,

What have you tried from Apex= so far? Have you asked at either (or both) of=A0boards.developerforce.com or=A0salesforce.stackexchange.com? Those would be= better forums for discussion - you should get some help there. If you do p= ost a question, or have already done so, let me know the URL and I'll t= ake a look. I have some code that worked with the Google Contacts API a cou= ple of years ago - I might be able to adapt it to Google Drive.

Cheers,

Pat

--=A0

Pat Patterson |=A0Princ= ipal Developer Evangelist | 408-849-4681 | http://about.me/patpatterson



On Mon, Oct 7, 2013 at 7:28 AM, Sunil Pa= l <sunilpal73@gmail.com> wrote:
Hi all,
Anyone have done integration with salesforce a= nd google. I want to upload files to google drive by using the apex code, b= y the use of salesforce standard feature i am able to done, but by the use = of apex code iam not bale to do.
Please help me guys,=A0

Thanks
---<= div>
Thanks And Warm Regards
Sunil Kumar Pal=


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


--047d7bb045c446058804e829e4cb-- From prateek.mishra@oracle.com Mon Oct 7 14:39:08 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D862011E813A for ; Mon, 7 Oct 2013 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leYtvyP2i0hR for ; Mon, 7 Oct 2013 14:39:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B11E813D for ; Mon, 7 Oct 2013 14:39:00 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r97LcxQw019528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Oct 2013 21:39:00 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r97Lcwow018583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Oct 2013 21:38:59 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r97LcwRp006598 for ; Mon, 7 Oct 2013 21:38:58 GMT Received: from [130.35.50.182] (/130.35.50.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Oct 2013 14:38:58 -0700 Message-ID: <525329EE.5040403@oracle.com> Date: Mon, 07 Oct 2013 14:38:54 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: IETF oauth WG References: <524F53E2.6050901@oracle.com> In-Reply-To: <524F53E2.6050901@oracle.com> X-Forwarded-Message-Id: <524F53E2.6050901@oracle.com> Content-Type: multipart/alternative; boundary="------------040601030902030509020000" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:39:09 -0000 This is a multi-part message in MIME format. --------------040601030902030509020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks interested in OAuth interop/implementation testing may want to participate in this discussion. Details at: http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html -------- Original Message -------- Subject: [oauth-interop] scope and reach of testing activity Date: Fri, 04 Oct 2013 16:48:50 -0700 From: Prateek Mishra Organization: Oracle Corporation To: oauth-interop@elists.isoc.org Hello OAuth Interop list, I would be interested in kicking off a discussion around the definition of scope and reach of the proposed testing activity. OAuth interop, of course, is the core activity. I assume this would take the form of testing the exchanges described in Sections 4-6 of RFC 6749 for each of the different client and grant types. Both positive and negative tests would presumably be included. But OAuth is also a security specification, and there are constraints defined over OAuth server and client behavior with respect to redirect_uri checking, access code and token lifetimes and so on. In addition to the material in Sections 4-6, there are additional constraints described in Section 10 and, of course, RFC 6819. So thats another area that would benefit from a set of tests, but I can see that describing these tests might be more challenging. I would be interested in other opinions on the scope and nature of tests being developed by this group. - prateek _______________________________________________ Oauth-interop mailing list Oauth-interop@elists.isoc.org https://elists.isoc.org/mailman/listinfo/oauth-interop --------------040601030902030509020000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks interested in OAuth interop/implementation testing may want to participate in this discussion.

Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

-------- Original Message --------
Subject: [oauth-interop] scope and reach of testing activity
Date: Fri, 04 Oct 2013 16:48:50 -0700
From: Prateek Mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
To: oauth-interop@elists.isoc.org 


Hello OAuth Interop list,

I would be interested in kicking off a discussion around the definition 
of scope and reach of the proposed testing activity.

OAuth interop, of course, is the core activity. I assume this would take 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different client and grant 
types. Both positive and negative tests would presumably be included.

But OAuth is also a security specification, and there are constraints 
defined over OAuth server and client behavior with respect to 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the material 
in Sections 4-6, there are additional constraints described in
Section 10 and, of course, RFC 6819. So thats another area that would 
benefit from a set of tests, but I can see that describing these tests
might be more challenging.

I would be interested in other opinions on the scope and nature of tests 
being developed by this group.

- prateek

_______________________________________________
Oauth-interop mailing list
Oauth-interop@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/oauth-interop


--------------040601030902030509020000-- From tonynad@microsoft.com Tue Oct 8 04:22:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9DB11E81AF for ; Tue, 8 Oct 2013 04:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lynVAfJ2+XxU for ; Tue, 8 Oct 2013 04:22:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id 302A421E8189 for ; Tue, 8 Oct 2013 04:22:11 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 11:22:08 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.204]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.31]) with mapi id 15.00.0785.001; Tue, 8 Oct 2013 11:22:02 +0000 From: Anthony Nadalin To: Prateek Mishra , IETF oauth WG Thread-Topic: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity Thread-Index: AQHOw6WsfqytXuqiEEiPXocUnGMXpZnqqakw Date: Tue, 8 Oct 2013 11:22:02 +0000 Message-ID: References: <524F53E2.6050901@oracle.com> <525329EE.5040403@oracle.com> In-Reply-To: <525329EE.5040403@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.245.87.29] x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(2473001)(189002)(199002)(13464003)(76482001)(15975445006)(74502001)(47446002)(69226001)(50986001)(47976001)(16236675002)(81342001)(54316002)(4396001)(56776001)(49866001)(47736001)(83322001)(19580405001)(74876001)(19580395003)(74706001)(46102001)(81686001)(81816001)(74662001)(31966008)(15202345003)(83072001)(85306002)(74366001)(80976001)(76786001)(63696002)(76796001)(33646001)(76576001)(53806001)(77982001)(59766001)(19300405004)(54356001)(51856001)(81542001)(74316001)(66066001)(80022001)(65816001)(79102001)(77096001)(56816003)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB189; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:94.245.87.29; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_cd890c5028424db6b7f78df6e2bad6f3BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:22:17 -0000 --_000_cd890c5028424db6b7f78df6e2bad6f3BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One thing to look at are the OpenID Connect interop tests and the portions/= flows of OAuth that it covers, as that is going on now. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= rateek Mishra Sent: Monday, October 7, 2013 2:39 PM To: IETF oauth WG Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activit= y Folks interested in OAuth interop/implementation testing may want to partic= ipate in this discussion. Details at: http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html -------- Original Message -------- Subject: [oauth-interop] scope and reach of testing activity Date: Fri, 04 Oct 2013 16:48:50 -0700 From: Prateek Mishra Organization: Oracle Corporation To: oauth-interop@elists.isoc.org Hello OAuth Interop list, I would be interested in kicking off a discussion around the definition of scope and reach of the proposed testing activity. OAuth interop, of course, is the core activity. I assume this would take the form of testing the exchanges described in Sections 4-6 of RFC 6749 for each of the different client and grant types. Both positive and negative tests would presumably be included. But OAuth is also a security specification, and there are constraints defined over OAuth server and client behavior with respect to redirect_uri checking, access code and token lifetimes and so on. In addition to the material in Sections 4-6, there are additional constraints described in Section 10 and, of course, RFC 6819. So thats another area that would benefit from a set of tests, but I can see that describing these tests might be more challenging. I would be interested in other opinions on the scope and nature of tests being developed by this group. - prateek _______________________________________________ Oauth-interop mailing list Oauth-interop@elists.isoc.org https://elists.isoc.org/mailman/listinfo/oauth-interop --_000_cd890c5028424db6b7f78df6e2bad6f3BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One thing to look at are = the OpenID Connect interop tests and the portions/flows of OAuth that it co= vers, as that is going on now.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ie= tf.org] On Behalf Of Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing = activity

 

Folks interested in OAuth interop/implementation tes= ting may want to participate in this discussion.


Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

-------- Original Message --------

Subjec= t:

[oauth-interop] scope and reach of testing activity<= o:p>

Date: =

Fri, 04 Oct 2013 16:48:50 -0700

From: =

Prateek Mishra <prateek.mishra@oracle.com>

Organi= zation:

Oracle Corporation

To:

oau= th-interop@elists.isoc.org

 

Hello OAuth Interop list,
 
I would be interested in kicking off a discussion around the definitio=
n 
of scope and reach of the proposed testing activity.
 
OAuth interop, of course, is the core activity. I assume this would ta=
ke 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different client and=
 grant 
types. Both positive and negative tests would presumably be included.<=
o:p>
 
But OAuth is also a security specification, and there are constraints =

defined over OAuth server and client behavior with respect to 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the material=
 
in Sections 4-6, there are additional constraints described in
Section 10 and, of course, RFC 6819. So thats another area that would =

benefit from a set of tests, but I can see that describing these tests=

might be more challenging.
 
I would be interested in other opinions on the scope and nature of tes=
ts 
being developed by this group.
 
- prateek
 
_______________________________________________
Oauth-interop mailing list
Oauth-interop@elists.=
isoc.org
htt=
ps://elists.isoc.org/mailman/listinfo/oauth-interop

 

 

--_000_cd890c5028424db6b7f78df6e2bad6f3BY2PR03MB189namprd03pro_-- From Michael.Jones@microsoft.com Tue Oct 8 16:26:37 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABC11E810D for ; Tue, 8 Oct 2013 16:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJY3VY6U8dCu for ; Tue, 8 Oct 2013 16:26:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2D21F9998 for ; Tue, 8 Oct 2013 16:25:50 -0700 (PDT) Received: from SN2PR03MB063.namprd03.prod.outlook.com (10.255.175.151) by SN2PR03MB030.namprd03.prod.outlook.com (10.255.175.40) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 23:25:28 +0000 Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by SN2PR03MB063.namprd03.prod.outlook.com (10.255.175.151) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 23:25:27 +0000 Received: from BY2FFO11FD041.protection.gbl (2a01:111:f400:7c0c::108) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Tue, 8 Oct 2013 23:25:27 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Tue, 8 Oct 2013 23:25:26 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.157]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0136.001; Tue, 8 Oct 2013 23:24:53 +0000 From: Mike Jones To: IETF oauth WG Thread-Topic: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity Thread-Index: AQHOw6XNhps1rbVgEUqbRL6DV1H4I5nqqewAgADIrQA= Date: Tue, 8 Oct 2013 23:24:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394376D838DA@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <524F53E2.6050901@oracle.com> <525329EE.5040403@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394376D838DATK5EX14MBXC290r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(189002)(199002)(13464003)(2473001)(69234005)(77096001)(84326002)(74662001)(31966008)(81686001)(16236675002)(69226001)(74502001)(76796001)(47446002)(76786001)(54356001)(76482001)(512954002)(51856001)(46102001)(81816001)(6806004)(74706001)(74876001)(66066001)(83322001)(15975445006)(81542001)(19300405004)(63696002)(83072001)(80022001)(65816001)(59766001)(20776003)(54316002)(33656001)(71186001)(79102001)(53806001)(19580395003)(74366001)(19580405001)(77982001)(56816003)(44976005)(56776001)(4396001)(15202345003)(49866001)(85306002)(47736001)(55846006)(80976001)(47976001)(81342001)(50986001)(85806001); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB063; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0993689CD1 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:26:37 -0000 --_000_4E1F6AAD24975D4BA5B168042967394376D838DATK5EX14MBXC290r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, the implementations participating in the current round of OpenID Conne= ct interop testing are described at http://osis.idcommons.net/wiki/Category= :OC5_Solution. You'll see the list of the 110 feature tests by going to an= y of the solution pages, such as http://osis.idcommons.net/wiki/OC5:MITREid= _Connect. While many are specific to OpenID Connect, you'll find that many= are actually testing OAuth functionality. For instance, the test Support = Authentication to Token Endpoint using HTTP Basic with POST is testing pure OAuth functionality. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= nthony Nadalin Sent: Tuesday, October 08, 2013 4:22 AM To: Prateek Mishra; IETF oauth WG Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing act= ivity One thing to look at are the OpenID Connect interop tests and the portions/= flows of OAuth that it covers, as that is going on now. From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Prateek Mishra Sent: Monday, October 7, 2013 2:39 PM To: IETF oauth WG Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activit= y Folks interested in OAuth interop/implementation testing may want to partic= ipate in this discussion. Details at: http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html -------- Original Message -------- Subject: [oauth-interop] scope and reach of testing activity Date: Fri, 04 Oct 2013 16:48:50 -0700 From: Prateek Mishra Organization: Oracle Corporation To: oauth-interop@elists.isoc.org Hello OAuth Interop list, I would be interested in kicking off a discussion around the definition of scope and reach of the proposed testing activity. OAuth interop, of course, is the core activity. I assume this would take the form of testing the exchanges described in Sections 4-6 of RFC 6749 for each of the different client and grant types. Both positive and negative tests would presumably be included. But OAuth is also a security specification, and there are constraints defined over OAuth server and client behavior with respect to redirect_uri checking, access code and token lifetimes and so on. In addition to the material in Sections 4-6, there are additional constraints described in Section 10 and, of course, RFC 6819. So thats another area that would benefit from a set of tests, but I can see that describing these tests might be more challenging. I would be interested in other opinions on the scope and nature of tests being developed by this group. - prateek _______________________________________________ Oauth-interop mailing list Oauth-interop@elists.isoc.org https://elists.isoc.org/mailman/listinfo/oauth-interop --_000_4E1F6AAD24975D4BA5B168042967394376D838DATK5EX14MBXC290r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, the implementations = participating in the current round of OpenID Connect interop testing are de= scribed at http://osi= s.idcommons.net/wiki/Category:OC5_Solution.  You’ll see the = list of the 110 feature tests by going to any of the solution pages, such a= s http://osis.= idcommons.net/wiki/OC5:MITREid_Connect.  While many are specific t= o OpenID Connect, you’ll find that many are actually testing OAuth fu= nctionality.  For instance, the test Support Authentication to Token Endpoint using HTTP Basic with POST is = testing pure OAuth functionality.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Anthony Nadalin
Sent: Tuesday, October 08, 2013 4:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of test= ing activity

 

One thing to look at are = the OpenID Connect interop tests and the portions/flows of OAuth that it co= vers, as that is going on now.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing = activity

 

Folks interested in OAuth interop/implementation tes= ting may want to participate in this discussion.


Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

-------- Original Message --------

Subjec= t:

[oauth-interop] scope and reach of testing activity<= o:p>

Date: =

Fri, 04 Oct 2013 16:48:50 -0700

From: =

Prateek Mishra <prateek.mishra@oracle.com>

Organi= zation:

Oracle Corporation

To:

oau= th-interop@elists.isoc.org

 

Hello OAuth Interop list,
 
I would be interested in kicking off a discussion around the definitio=
n 
of scope and reach of the proposed testing activity.
 
OAuth interop, of course, is the core activity. I assume this would ta=
ke 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different client and=
 grant 
types. Both positive and negative tests would presumably be included.<=
o:p>
 
But OAuth is also a security specification, and there are constraints =

defined over OAuth server and client behavior with respect to 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the material=
 
in Sections 4-6, there are additional constraints described in
Section 10 and, of course, RFC 6819. So thats another area that would =

benefit from a set of tests, but I can see that describing these tests=

might be more challenging.
 
I would be interested in other opinions on the scope and nature of tes=
ts 
being developed by this group.
 
- prateek
 
_______________________________________________
Oauth-interop mailing list
Oauth-interop@elists.=
isoc.org
htt=
ps://elists.isoc.org/mailman/listinfo/oauth-interop

 

 

--_000_4E1F6AAD24975D4BA5B168042967394376D838DATK5EX14MBXC290r_-- From jricher@mitre.org Wed Oct 9 08:01:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8B21F9D15 for ; Wed, 9 Oct 2013 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-PF+QoWAhEB for ; Wed, 9 Oct 2013 08:01:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED6D21F9D2B for ; Wed, 9 Oct 2013 08:00:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 155D41F1970; Wed, 9 Oct 2013 11:00:39 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CE63C1F0963; Wed, 9 Oct 2013 11:00:38 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 11:00:38 -0400 Message-ID: <52556F7B.6030406@mitre.org> Date: Wed, 9 Oct 2013 11:00:11 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "oauth@ietf.org" , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Subject: [OAUTH-WG] A Note on OAuth Interoperability X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:01:07 -0000 From many conversations that I've had with people over the past few years, it's been clear to me that there's a significant amount of confusion about the state of interoperability in OAuth. All notions of profiles and deployments aside, I believe that many people have different ideas about *what* exactly is meant to be interoperable within OAuth, and these expectations lead to premature declarations of OAuth being non-interoperable. The truth is that there are a lot of moving parts in OAuth and different parts of the protocol family deal with interoperability between different pieces. I'm going to attempt, here, to lay out what I see as the fundamental interop concerns that each component deals with, and hopefully this can help drive the conversation forward in a constructive manner: RFC6749: client <-> AS The core spec deals with interop between the client and the authorization server, in four different flows that tell the client what it needs to do to get a token. (Five if you count refresh tokens.) The resource owner/user agent are used as mechanisms to facilitate the interaction between these parts, but they are by and large passive carriers of the information being passed along the front channel. It's important to realize that RFC6749 doesn't say anything about interoperating with the protected resource. It's also important to realize that RFC6749 doesn't say anything about interop between the resource owner/user agent and the client, or between the resource owner/user agent and the AS. The core is, by design, silent on these matters. RFC6750: client <-> PR The bearer token spec deals with interop between the client and the protected resource by defining one kind of token and telling the client how to use it at the PR. In defining the token type, it does define what would is returned from the AS. This, however, I think is an unfortunate artifact of the core not defining an abstract object structure representing the token, and instead defining only the JSON serialization coming from the token endpoint's output (which is then serialized in parameters in the implicit flow, and maybe we can fix this all in OAuth 2.1, but I digress). However, the core of this spec is to tell the client what to do once it gets a token. Ultimately, RFC6750 doesn't care how you get a bearer token, and we've seen many instances of issuance of bearer tokens that don't use any RFC6749 constructs. But once you get that token, and it is a bearer token, then a client can use RFC6750 to hand that to a protected resource. RFC6750 is also silent about what the protected resource does to figure out what the token's good for, or if it's any good at all. JWT, Introspection: PR <-> AS Since everything to this point has been completely hand-wavy about how the heck a PR and an AS can agree on what to do with a token, these two specs (and their associated ecosystems) solve it in different ways. Of course, the most common approach, and the one assumed in OAuth 1.0, was that the AS and PR were actually the same thing. But since we can theoretically split these two in OAuth 2.0, we need some means to get them talking. JWTs pack information into the token itself, building directly on top of RFC6750's bearer token (for the most part), and use JOSE to provide different flavors of protection and assurance. A common pattern with JWT that I've seen is to have something that can facilitate service discovery in the "iss" field (like a URL), and then asymmetrically sign it with the AS's key so that the PR can check the signature. Then everything in the token can be used to figure out important things like who the token's for and what it should be used for. Introspection uses a web-API approach to solving the same problem, where the PR makes an HTTP GET and passes the token along back to the AS to get this information. Both have their benefits and drawbacks and can even be used together (ie: parse the JWT to find the issuer, then call introspection on that issuer). Then you have things like Revocation which deal with token-holder <-> AS, where token-holder can be either the client or the PR depending on what's trying to be accomplished. Registration deals with client <-> AS, resource provisioning deals with PR <-> AS, and of course there's UMA which connects everybody to everybody else by using most of these components in a single, comprehensive application of awesomeness. Where have we gone awry on this? For starters, current revision of the signed token spec attempts to solve both client <-> PR and PR <-> AS interoperability simultaneously, and I think that's a mistake. There are also those who assume client <-> AS and client <-> PR interoperability as indivisible from each other, which is also a mistake. And then there are those that see that one spec or another doesn't specify interop between all points on its own, so they conclude OAuth is fundamentally non-interoperable. This is a grave mistake but it's a very real problem of perception that OAuth has in the real world. I think that as we go forward with OAuth interop testing and continued profiling, we need to keep in mind *what* is interoperating with *what* for each piece that we care about. -- Justin From prateek.mishra@oracle.com Wed Oct 9 13:15:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E92611E80ED for ; Wed, 9 Oct 2013 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEuG4PPyOCtr for ; Wed, 9 Oct 2013 13:15:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1E11E80FB for ; Wed, 9 Oct 2013 13:14:59 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r99KEwmM026271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Oct 2013 20:14:59 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 r99KEwoP022662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 20:14:58 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r99KEv0T010662; Wed, 9 Oct 2013 20:14:58 GMT Received: from [130.35.50.182] (/130.35.50.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Oct 2013 13:14:57 -0700 Message-ID: <5255B940.5040202@oracle.com> Date: Wed, 09 Oct 2013 13:14:56 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: Mike Jones References: <524F53E2.6050901@oracle.com> <525329EE.5040403@oracle.com> <4E1F6AAD24975D4BA5B168042967394376D838DA@TK5EX14MBXC290.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394376D838DA@TK5EX14MBXC290.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------090101040907090709070701" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:15:17 -0000 This is a multi-part message in MIME format. --------------090101040907090709070701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thats a good suggestion; it looks the tests are all listed under http://osis.idcommons.net/wiki/Category:OC5_FeatureTests Is there an IP regime under which they have been published? I suppose all materials would follow OSIS rules in general. - prateek > > FYI, the implementations participating in the current round of OpenID > Connect interop testing are described at > http://osis.idcommons.net/wiki/Category:OC5_Solution. You'll see the > list of the 110 feature tests by going to any of the solution pages, > such as http://osis.idcommons.net/wiki/OC5:MITREid_Connect. While many > are specific to OpenID Connect, you'll find that many are actually > testing OAuth functionality. For instance, the test /Support > Authentication to Token Endpoint using HTTP Basic with POST > /is > testing pure OAuth functionality. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Anthony Nadalin > *Sent:* Tuesday, October 08, 2013 4:22 AM > *To:* Prateek Mishra; IETF oauth WG > *Subject:* Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of > testing activity > > One thing to look at are the OpenID Connect interop tests and the > portions/flows of OAuth that it covers, as that is going on now. > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Prateek Mishra > *Sent:* Monday, October 7, 2013 2:39 PM > *To:* IETF oauth WG > *Subject:* [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing > activity > > Folks interested in OAuth interop/implementation testing may want to > participate in this discussion. > > > Details at: > http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html > > -------- Original Message -------- > > *Subject: * > > > > [oauth-interop] scope and reach of testing activity > > *Date: * > > > > Fri, 04 Oct 2013 16:48:50 -0700 > > *From: * > > > > Prateek Mishra > > > *Organization: * > > > > Oracle Corporation > > *To: * > > > > oauth-interop@elists.isoc.org > > Hello OAuth Interop list, > > I would be interested in kicking off a discussion around the definition > of scope and reach of the proposed testing activity. > > OAuth interop, of course, is the core activity. I assume this would take > the form of testing the exchanges described > in Sections 4-6 of RFC 6749 for each of the different client and grant > types. Both positive and negative tests would presumably be included. > > But OAuth is also a security specification, and there are constraints > defined over OAuth server and client behavior with respect to > redirect_uri checking, > access code and token lifetimes and so on. In addition to the material > in Sections 4-6, there are additional constraints described in > Section 10 and, of course, RFC 6819. So thats another area that would > benefit from a set of tests, but I can see that describing these tests > might be more challenging. > > I would be interested in other opinions on the scope and nature of tests > being developed by this group. > > - prateek > > _______________________________________________ > Oauth-interop mailing list > Oauth-interop@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/oauth-interop > --------------090101040907090709070701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thats a good suggestion; it looks the tests are all listed under http://osis.idcommons.net/wiki/Category:OC5_FeatureTests

Is there an IP regime under which they have been published? I suppose all materials would follow OSIS rules in general.

- prateek

FYI, the implementations participating in the current round of OpenID Connect interop testing are described at http://osis.idcommons.net/wiki/Category:OC5_Solution.  You’ll see the list of the 110 feature tests by going to any of the solution pages, such as http://osis.idcommons.net/wiki/OC5:MITREid_Connect.  While many are specific to OpenID Connect, you’ll find that many are actually testing OAuth functionality.  For instance, the test Support Authentication to Token Endpoint using HTTP Basic with POST is testing pure OAuth functionality.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Tuesday, October 08, 2013 4:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

 

One thing to look at are the OpenID Connect interop tests and the portions/flows of OAuth that it covers, as that is going on now.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

 

Folks interested in OAuth interop/implementation testing may want to participate in this discussion.


Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

-------- Original Message --------

Subject:

[oauth-interop] scope and reach of testing activity

Date:

Fri, 04 Oct 2013 16:48:50 -0700

From:

Prateek Mishra <prateek.mishra@oracle.com>

Organization:

Oracle Corporation

To:

oauth-interop@elists.isoc.org

 

Hello OAuth Interop list,
 
I would be interested in kicking off a discussion around the definition 
of scope and reach of the proposed testing activity.
 
OAuth interop, of course, is the core activity. I assume this would take 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different client and grant 
types. Both positive and negative tests would presumably be included.
 
But OAuth is also a security specification, and there are constraints 
defined over OAuth server and client behavior with respect to 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the material 
in Sections 4-6, there are additional constraints described in
Section 10 and, of course, RFC 6819. So thats another area that would 
benefit from a set of tests, but I can see that describing these tests
might be more challenging.
 
I would be interested in other opinions on the scope and nature of tests 
being developed by this group.
 
- prateek
 
_______________________________________________
Oauth-interop mailing list
Oauth-interop@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/oauth-interop

 

 


--------------090101040907090709070701-- From Michael.Jones@microsoft.com Wed Oct 9 14:39:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24D121E81F4 for ; Wed, 9 Oct 2013 14:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jm7m5g6tDVc for ; Wed, 9 Oct 2013 14:39:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E921E81EC for ; Wed, 9 Oct 2013 14:39:39 -0700 (PDT) Received: from BY2PR03CA031.namprd03.prod.outlook.com (10.242.234.152) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 9 Oct 2013 21:39:37 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::183) by BY2PR03CA031.outlook.office365.com (2a01:111:e400:2c2c::24) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Wed, 9 Oct 2013 21:39:37 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Wed, 9 Oct 2013 21:39:36 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.157]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Wed, 9 Oct 2013 21:38:51 +0000 From: Mike Jones To: Prateek Mishra Thread-Topic: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity Thread-Index: AQHOw6XNhps1rbVgEUqbRL6DV1H4I5nqqewAgADIrQCAAV6MAIAAE/Wg Date: Wed, 9 Oct 2013 21:38:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943777A50ED@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <524F53E2.6050901@oracle.com> <525329EE.5040403@oracle.com> <4E1F6AAD24975D4BA5B168042967394376D838DA@TK5EX14MBXC290.redmond.corp.microsoft.com> <5255B940.5040202@oracle.com> In-Reply-To: <5255B940.5040202@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943777A50EDTK5EX14MBXC290r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(2473001)(13464003)(69234005)(199002)(189002)(377454003)(80022001)(16236675002)(20776003)(19580405001)(76786001)(15975445006)(74876001)(19300405004)(66066001)(83072001)(81686001)(85306002)(81816001)(84326002)(54316002)(77982001)(59766001)(83322001)(74706001)(77096001)(74366001)(44976005)(15202345003)(33656001)(47736001)(74502001)(71186001)(55846006)(4396001)(56816003)(50986001)(47976001)(49866001)(6806004)(46102001)(80976001)(31966008)(69226001)(54356001)(76482001)(81342001)(65816001)(56776001)(76796001)(63696002)(74662001)(47446002)(512954002)(79102001)(51856001)(81542001)(53806001)(19580395003)(85806001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0994F5E0C5 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:39:44 -0000 X-List-Received-Date: Wed, 09 Oct 2013 21:39:44 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943777A50EDTK5EX14MBXC290r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, these interop tests are being conducted under the auspices of OSIS, wh= ich is a working group of Identity Commons. You can read about OSIS at htt= p://osis.idcommons.net/wiki/Main_Page. In particularly note this section: What the OSIS Interops Are and Are Not The OSIS Interops provide an opportunity for implementers to try their code= against one another's in a systematic way, providing data to help improve = their implementations. The OSIS Interops are not conformance tests. Partici= pants do not "pass" or "fail". There is no requirement that you must suppor= t particular features to participate or that you must participate in all as= pects of the Interop. -- Mike From: Prateek Mishra [mailto:prateek.mishra@oracle.com] Sent: Wednesday, October 09, 2013 1:15 PM To: Mike Jones Cc: IETF oauth WG; Anthony Nadalin Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing act= ivity Thats a good suggestion; it looks the tests are all listed under http://osi= s.idcommons.net/wiki/Category:OC5_FeatureTests Is there an IP regime under which they have been published? I suppose all m= aterials would follow OSIS rules in general. - prateek FYI, the implementations participating in the current round of OpenID Conne= ct interop testing are described at http://osis.idcommons.net/wiki/Category= :OC5_Solution. You'll see the list of the 110 feature tests by going to an= y of the solution pages, such as http://osis.idcommons.net/wiki/OC5:MITREid= _Connect. While many are specific to OpenID Connect, you'll find that many= are actually testing OAuth functionality. For instance, the test Support = Authentication to Token Endpoint using HTTP Basic with POST is testing pure OAuth functionality. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Tuesday, October 08, 2013 4:22 AM To: Prateek Mishra; IETF oauth WG Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing act= ivity One thing to look at are the OpenID Connect interop tests and the portions/= flows of OAuth that it covers, as that is going on now. From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Prateek Mishra Sent: Monday, October 7, 2013 2:39 PM To: IETF oauth WG Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activit= y Folks interested in OAuth interop/implementation testing may want to partic= ipate in this discussion. Details at: http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html -------- Original Message -------- Subject: [oauth-interop] scope and reach of testing activity Date: Fri, 04 Oct 2013 16:48:50 -0700 From: Prateek Mishra Organization: Oracle Corporation To: oauth-interop@elists.isoc.org Hello OAuth Interop list, I would be interested in kicking off a discussion around the definition of scope and reach of the proposed testing activity. OAuth interop, of course, is the core activity. I assume this would take the form of testing the exchanges described in Sections 4-6 of RFC 6749 for each of the different client and grant types. Both positive and negative tests would presumably be included. But OAuth is also a security specification, and there are constraints defined over OAuth server and client behavior with respect to redirect_uri checking, access code and token lifetimes and so on. In addition to the material in Sections 4-6, there are additional constraints described in Section 10 and, of course, RFC 6819. So thats another area that would benefit from a set of tests, but I can see that describing these tests might be more challenging. I would be interested in other opinions on the scope and nature of tests being developed by this group. - prateek _______________________________________________ Oauth-interop mailing list Oauth-interop@elists.isoc.org https://elists.isoc.org/mailman/listinfo/oauth-interop --_000_4E1F6AAD24975D4BA5B1680429673943777A50EDTK5EX14MBXC290r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, these interop tests = are being conducted under the auspices of OSIS, which is a working group of= Identity Commons.  You can read about OSIS at http://osis.idcommons.= net/wiki/Main_Page.  In particularly note this section:=

 <= /p>

W= hat the OSIS Interops Are and Are Not

The OSIS Interops pro= vide an opportunity for implementers to try their code against one another'= s in a systematic way, providing data to help improve their implementations. The OSIS Interops are not conformance = tests. Participants do not "pass" or "fail". There is n= o requirement that you must support particular features to participate or t= hat you must participate in all aspects of the Interop.

 <= /p>

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

 <= /p>

From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
Sent: Wednesday, October 09, 2013 1:15 PM
To: Mike Jones
Cc: IETF oauth WG; Anthony Nadalin
Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of test= ing activity

 

Thats a good suggestion; it looks the tests are all = listed under http:/= /osis.idcommons.net/wiki/Category:OC5_FeatureTests


Is there an IP regime under which they have been published? I suppose all m= aterials would follow OSIS rules in general.

- prateek

FYI, the implementations = participating in the current round of OpenID Connect interop testing are de= scribed at http://osi= s.idcommons.net/wiki/Category:OC5_Solution.  You’ll see the = list of the 110 feature tests by going to any of the solution pages, such a= s http://osis.= idcommons.net/wiki/OC5:MITREid_Connect.  While many are specific t= o OpenID Connect, you’ll find that many are actually testing OAuth fu= nctionality.  For instance, the test Support Authentication to Token Endpoint using HTTP Basic with POST is testing pure OAuth functionality.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Tuesday, October 08, 2013 4:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of test= ing activity

 

One thing to look at are = the OpenID Connect interop tests and the portions/flows of OAuth that it co= vers, as that is going on now.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing = activity

 

Folks interested in OAuth interop/implementation tes= ting may want to participate in this discussion.


Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

-------- Original Message --------

Subjec= t:

[oauth-interop] scope and reach of testing activity<= o:p>

Date: =

Fri, 04 Oct 2013 16:48:50 -0700

From: =

Prateek Mishra <prateek.mishra@oracle.com>

Organi= zation:

Oracle Corporation

To:

oau= th-interop@elists.isoc.org

 

Hello OAuth Interop list,
 
I would be interested in kicking off a discussion around the definitio=
n 
of scope and reach of the proposed testing activity.
 
OAuth interop, of course, is the core activity. I assume this would ta=
ke 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different client and=
 grant 
types. Both positive and negative tests would presumably be included.<=
o:p>
 
But OAuth is also a security specification, and there are constraints =

defined over OAuth server and client behavior with respect to 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the material=
 
in Sections 4-6, there are additional constraints described in
Section 10 and, of course, RFC 6819. So thats another area that would =

benefit from a set of tests, but I can see that describing these tests=

might be more challenging.
 
I would be interested in other opinions on the scope and nature of tes=
ts 
being developed by this group.
 
- prateek
 
_______________________________________________
Oauth-interop mailing list
Oauth-interop@elists.=
isoc.org
htt=
ps://elists.isoc.org/mailman/listinfo/oauth-interop

 

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943777A50EDTK5EX14MBXC290r_-- From ve7jtb@ve7jtb.com Wed Oct 9 14:51:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46321F9BF3 for ; Wed, 9 Oct 2013 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXjFOq6syTkC for ; Wed, 9 Oct 2013 14:51:17 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id EA3D721F88A9 for ; Wed, 9 Oct 2013 14:51:11 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t60so1510609wes.26 for ; Wed, 09 Oct 2013 14:51:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=OniVxQZktrcsQejkLHimyYx+b2uNeLBe8EF0U3j1f24=; b=UuH3TjhpUNcLlel7dTz+cNr8ESKA2fIwlfydDNzCWTDiiWGV79aE6JxOzj1b8TI80d Z+HJQNCdHBnXX8t2OAUKMpwtHH7WbSqXOVdAZR/aH0Wctnf0ot+hqduictMOeDc7RkJd 4CwyxxQirTkENI7qd/nLH7IlAJborypGSHYWaYiPufH7GjkGfNVeWSMH1Ei+NVVBIHfM DMdkZwsCZoqM6uzOjLx14XoUuLAzFS88a9oWzPwjpmRbtQ+KwJIeT+DAJ2gURhzuxTHd ZIOe8iojTC6CZ13hVJPmgynV4JXKtI6Wjg0jSfDYH8CDAhpGvAvzmODGX4HUSTknhZLm kjjw== X-Gm-Message-State: ALoCoQk9ZAbCGE+KOr18IDHtTJvFTlA9qdHyHq3kWJuySIHVSBHcoBBbLdozjbSQsmzu1JDRSM9R X-Received: by 10.180.73.113 with SMTP id k17mr4647901wiv.6.1381355470840; Wed, 09 Oct 2013 14:51:10 -0700 (PDT) Received: from [10.4.102.197] (188.29.165.247.threembb.co.uk. [188.29.165.247]) by mx.google.com with ESMTPSA id ma3sm19367536wic.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 14:51:09 -0700 (PDT) References: <524F53E2.6050901@oracle.com> <525329EE.5040403@oracle.com> <4E1F6AAD24975D4BA5B168042967394376D838DA@TK5EX14MBXC290.redmond.corp.microsoft.com> <5255B940.5040202@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5255B940.5040202@oracle.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-46AF92A2-C598-4028-921F-7BCF640FB266; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11A501) From: John Bradley Date: Wed, 9 Oct 2013 22:50:57 +0100 To: Prateek Mishra Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:51:21 -0000 --Apple-Mail-46AF92A2-C598-4028-921F-7BCF640FB266 Content-Type: multipart/alternative; boundary=Apple-Mail-3FAE3C15-EB69-4B1D-B2FC-0DD531D70A9E Content-Transfer-Encoding: 7bit --Apple-Mail-3FAE3C15-EB69-4B1D-B2FC-0DD531D70A9E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes they are all under OSIS IPR rules.=20 Sent from my iPhone > On Oct 9, 2013, at 9:14 PM, Prateek Mishra wro= te: >=20 > Thats a good suggestion; it looks the tests are all listed under http://os= is.idcommons.net/wiki/Category:OC5_FeatureTests >=20 > Is there an IP regime under which they have been published? I suppose all m= aterials would follow OSIS rules in general. >=20 > - prateek >> FYI, the implementations participating in the current round of OpenID Con= nect interop testing are described at http://osis.idcommons.net/wiki/Categor= y:OC5_Solution. You=E2=80=99ll see the list of the 110 feature tests by goi= ng to any of the solution pages, such as http://osis.idcommons.net/wiki/OC5:= MITREid_Connect. While many are specific to OpenID Connect, you=E2=80=99ll f= ind that many are actually testing OAuth functionality. For instance, the t= est Support Authentication to Token Endpoint using HTTP Basic with POST is t= esting pure OAuth functionality. >> =20 >> -- Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Anthony Nadalin >> Sent: Tuesday, October 08, 2013 4:22 AM >> To: Prateek Mishra; IETF oauth WG >> Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing a= ctivity >> =20 >> One thing to look at are the OpenID Connect interop tests and the portion= s/flows of OAuth that it covers, as that is going on now. >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Prateek Mishra >> Sent: Monday, October 7, 2013 2:39 PM >> To: IETF oauth WG >> Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activ= ity >> =20 >> Folks interested in OAuth interop/implementation testing may want to part= icipate in this discussion. >>=20 >> Details at: >> http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html >>=20 >> -------- Original Message -------- >> Subject: >> [oauth-interop] scope and reach of testing activity >> Date: >> Fri, 04 Oct 2013 16:48:50 -0700 >> From: >> Prateek Mishra >> Organization: >> Oracle Corporation >> To: >> oauth-interop@elists.isoc.org >> =20 >>=20 >> Hello OAuth Interop list, >> =20 >> I would be interested in kicking off a discussion around the definition=20= >> of scope and reach of the proposed testing activity. >> =20 >> OAuth interop, of course, is the core activity. I assume this would take=20= >> the form of testing the exchanges described >> in Sections 4-6 of RFC 6749 for each of the different client and grant=20= >> types. Both positive and negative tests would presumably be included. >> =20 >> But OAuth is also a security specification, and there are constraints=20 >> defined over OAuth server and client behavior with respect to=20 >> redirect_uri checking, >> access code and token lifetimes and so on. In addition to the material=20= >> in Sections 4-6, there are additional constraints described in >> Section 10 and, of course, RFC 6819. So thats another area that would=20 >> benefit from a set of tests, but I can see that describing these tests >> might be more challenging. >> =20 >> I would be interested in other opinions on the scope and nature of tests=20= >> being developed by this group. >> =20 >> - prateek >> =20 >> _______________________________________________ >> Oauth-interop mailing list >> Oauth-interop@elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/oauth-interop >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3FAE3C15-EB69-4B1D-B2FC-0DD531D70A9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes they are all under OSIS IPR rules.=  

Sent from my iPhone

On Oct 9, 2013, at 9:14 PM, P= rateek Mishra <prateek.mishr= a@oracle.com> wrote:

=20 =20 =20 Thats a good suggestion; it looks the tests are all listed under http://osis.idcommons.net/wiki/Category:OC5_Fea= tureTests

Is there an IP regime under which they have been published? I suppose all materials would follow OSIS rules in general.

- prateek

FYI, the implementations participating in the current round of OpenID Connect interop testing are described at http://osis.idcommons.net/wiki/Category:OC5_Soluti= on.  You=E2=80=99ll see the list of the 110 feature tests by going to= any of the solution pages, such as http://osis.idcommons.net/wiki/OC5:MITREid_Connect.  While many are specific to OpenID Connect, you=E2=80=99ll find t= hat many are actually testing OAuth functionality.  For instance, the test Support Authentication to Token Endpoint using HTTP Basic with POST is testing pure OAuth functionality.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Anthony Nadalin
Sent: Tuesday, October 08, 2013 4:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

 

One thing to look at are the OpenID Connect interop tests and the portions/flows of OAuth that it covers, as that is going on now.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

 

Folks interested in OAuth interop/implementation testing may want to participate in this discussion.


Details at:
http://www.ietf.org/mail-archive/web/o= auth/current/msg12128.html

-------- Original Message --------

Subject:

[oauth-interop] scope and reach of testing activity

Date:

Fri, 04 Oct 2013 16:48:50 -0700

From:

Prateek Mishra <prateek.mishra@oracle.c= om>

Organization:

Oracle Corporation

To:

oauth-interop@elists.isoc.org

 <= /o:p>

Hello OAuth Interop list,
 
I would be interested in kicking off a discussion around the d=
efinition 
of scope and reach of the proposed testing activity.
 
OAuth interop, of course, is the core activity. I assume this=
 would take 
the form of testing the exchanges described
in Sections 4-6  of RFC 6749 for each of the different c=
lient and grant 
types. Both positive and negative tests would presumably be i=
ncluded.
 
But OAuth is also a security specification, and there are con=
straints 
defined over OAuth server and client behavior with respect to=
 
redirect_uri checking,
access code and token lifetimes and so on. In addition to the=
 material 
in Sections 4-6, there are additional constraints described i=
n
Section 10 and, of course, RFC 6819. So thats another area th=
at would 
benefit from a set of tests, but I can see that describing th=
ese tests
might be more challenging.
 
I would be interested in other opinions on the scope and natu=
re of tests 
being developed by this group.
 
- prateek
 
_______________________________________________
          
Oauth-interop mailing list

          
Oauth-interop@elists.isoc.org

          
https://elists.isoc.org/mailman/listinfo/oaut=
h-interop

          
 

 


=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-3FAE3C15-EB69-4B1D-B2FC-0DD531D70A9E-- --Apple-Mail-46AF92A2-C598-4028-921F-7BCF640FB266 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAwOTIxNTEwM1owIwYJKoZIhvcNAQkEMRYEFPA1 qtVm8/uE9W7Rq5m0Rg1g3CXBMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAGBNxFVB+iUpMlax9FfNt4QjW973pK3BVPAA kFJsZRZd6E/FU1RC4+nbGZffBqt/9XunE8inwiy9gpQSKvjwme/gDNyvg01DNlrMH07IKJ8oNae/ 6a9GEsYT25OdJg2bYEDAnCFhrC9pWiBqW4iDVBjkV+lTSceP4bjYrpOBm5ikCBbdqgF9+1vljFen JAQpqiQwu6Lb3We5L/JMeRquJOtnfWWD3mvvUIe02qGVe52yM/+ZTElYM8WJ07uNRdAtGp//PEc4 kFJvNCedqqcgblhORytKWes+jTgkqWmIfis8BfMIF7fktnKvoorLWKB+ar7eYgyVdRNfrCEElh37 r/EAAAAAAAA= --Apple-Mail-46AF92A2-C598-4028-921F-7BCF640FB266-- From ve7jtb@ve7jtb.com Mon Oct 14 17:01:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013A221E80DD for ; Mon, 14 Oct 2013 17:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fY281k-guKc for ; Mon, 14 Oct 2013 17:01:24 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68A21E80E5 for ; Mon, 14 Oct 2013 17:01:19 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id v1so2584756qcw.33 for ; Mon, 14 Oct 2013 17:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=uhT7IDSXz0VOESZtw/hkgFgIUarhhB3bSTWrL0j+9Ic=; b=mJupOiSewxxNpjqBD+3K6Oyjs5v8gV4K4G9+gVauXt31WXKvOpQyyD42opiRsQCjo8 wiKA7yqv964+QlswpZEfNZ9fcI2yhJxNnKZOE8fLC3CGzF1/UtghjkUfXtwriUNUYtSQ hAO6ihcHQrqNi35P2HNE4yYb1hyuCfoxqryQthMqSyTL876Av1lrrGwV2AkNRdooxYq4 fbKkCw2012b60b/Hf0vvelVXTbIWpWZa4voqb2+Ux1y2plishR3A4SYxWcalNVjZiXRJ RpuZeTkNV15L3GXqB3IdhbZsHmnWH4C4IfcP4I1rXas9dOUCX0boMazoy6B3t/dl+TFB cSug== X-Gm-Message-State: ALoCoQk7321Fr/r3fObFuQG0QUREIS9Y1SEPOHhpbxWj3yzQQvzVs6SLvzqXMo8r/P466jfy8NZb X-Received: by 10.224.11.68 with SMTP id s4mr7392747qas.88.1381795276634; Mon, 14 Oct 2013 17:01:16 -0700 (PDT) Received: from [192.168.1.216] (190-20-50-133.baf.movistar.cl. [190.20.50.133]) by mx.google.com with ESMTPSA id x1sm149565034qai.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 17:01:15 -0700 (PDT) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_08ADCDD5-14D2-4724-AF54-2FF5C77680A2"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Mon, 14 Oct 2013 21:01:12 -0300 To: oauth list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:01:29 -0000 --Apple-Mail=_08ADCDD5-14D2-4724-AF54-2FF5C77680A2 Content-Type: multipart/alternative; boundary="Apple-Mail=_3AAE5968-AD82-4EFA-833B-A38BB9675702" --Apple-Mail=_3AAE5968-AD82-4EFA-833B-A38BB9675702 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: = http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-0= 0.txt Status: = http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client Htmlized: = http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. 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. The IETF Secretariat= --Apple-Mail=_3AAE5968-AD82-4EFA-833B-A38BB9675702 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A new = version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been = successfully submitted by John Bradley and posted to the
IETF = repository.

Filename: =  draft-bradley-stateless-oauth-client
Revision: =  00
Title:  Stateless Client Identifier = for OAuth 2
Creation date:  2013-10-15
Group: =  Individual Submission
Number of pages: 4
URL: =             http://www.ietf.org/internet-drafts/draft-bradley-stateless= -oauth-client-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00

Abstract:
  This draft provides a method for = communicating information about an
  OAuth client through = its client identifier allowing for fully
  stateless = operation.





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.

The IETF = Secretariat= --Apple-Mail=_3AAE5968-AD82-4EFA-833B-A38BB9675702-- --Apple-Mail=_08ADCDD5-14D2-4724-AF54-2FF5C77680A2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE1MDAwMTEzWjAjBgkqhkiG9w0BCQQxFgQUClZtIAsh c72iO6NDHw11LGVDFGwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAhGoMrrSWY4DGkzrd4I/DIY/zoQQEyynTjeKwF+AK mWE7VKLBXFvBRQ0g4JECqjPh7ndfje3mIi5JYTHWVtqbV2HhbzxrEMusAMk6wwVAx1BY0kf6Fs/e E5G9HtZd24maBEQLTAkMAm7b1TamU7xE4dbvZjRfH+065CjSNTWzG0Fy/piAPdNgZEnV0AUAYx95 Ep7XjxIqT88z73A3aFZ9VA7D0v6WRob8w08sqswYJ+PNjpwWtVq832lJDQrgNn43ARV1U9++bbXz dNGh8txH3d4SUDwdUa3wvsxITPftmVvA0Q6tpKV9jZYzFfY9f89YpDWEuHUkI78m2iXn0TXYIQAA AAAAAA== --Apple-Mail=_08ADCDD5-14D2-4724-AF54-2FF5C77680A2-- From dan@respectnetwork.net Mon Oct 14 18:32:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DF11E8170 for ; Mon, 14 Oct 2013 18:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G01D2SjL2SO9 for ; Mon, 14 Oct 2013 18:32:33 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB511E8131 for ; Mon, 14 Oct 2013 18:32:30 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so6228ieb.30 for ; Mon, 14 Oct 2013 18:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5VGEuav8Z0ZfSjJ2cRkllSmNO/glIhWwePo+1CuPofA=; b=Sw6gt2KnabxVJOGM/VLQ9Ud94cUuPFqcMXMaDwL70wFvnkkKQsSOX+INVqK2Z6qAJE HPGBxyG3blp2OzoJBNNwEItF8u076SpPANuyyBxYL1OwYxHWn+O8mOpgnG1Lp2/erXt/ ibRcXVj+LSTOP6bQr4k1Nev58QyX4H5WQ5r85xxoOEm+V0Misy1uSB6DUYr0b0EXAh4c 8mb0zwdIfuZ6h9oRhkxtYg6O7CWENHWLsXKcvQJDGqZei0vsKE+7kerJFMm1cSTz+TUD +VRpvnNDwNoYNP9YzssLqYEIuh7dEgidZMQKrDpPBdP4OSRQQ00vV7ZiDckquspD+nEY qFWw== X-Gm-Message-State: ALoCoQlh+RLoUuZscHxoNhA89XH7G+uAWpYg/2jdihRotXh1BbgusVUKOGTihwv6dCUNq5uo/pT0 MIME-Version: 1.0 X-Received: by 10.50.117.40 with SMTP id kb8mr15223919igb.60.1381800750133; Mon, 14 Oct 2013 18:32:30 -0700 (PDT) Received: by 10.64.226.131 with HTTP; Mon, 14 Oct 2013 18:32:29 -0700 (PDT) X-Originating-IP: [108.45.69.60] Date: Mon, 14 Oct 2013 21:32:29 -0400 Message-ID: From: Dan Blum To: oauth list Content-Type: multipart/alternative; boundary=089e0115f49adcc80604e8bd8e60 Subject: [OAUTH-WG] Proposed OAuth 2.0 Assurance Panel at IIW next week X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 01:32:38 -0000 --089e0115f49adcc80604e8bd8e60 Content-Type: text/plain; charset=ISO-8859-1 After spending some time over the last few months looking into OAuth assurance issues, I decided that I'll propose a panel on the topic next week at IIW. My initial take on the proposed session is described in the blog post at this link and is summarized below as well. As I've written in several related articles, OAuth 2.0 has some significant assurance issues. And while the community did an excellent job documenting these issues in RFC 6819 on security considerations, to my knowledge there hasn't been much discussion on how the assurance of an implementation should be tested or on how customers or relying parties are supposed to know whether a given implementation has been implemented in a robust manner. With all the work on OAuth 2.0 interoperability testing, I sense an opportunity to inject some assurance testing into the process. Not full penetration testing or vulnerability testing by any, but perhaps some basic robustness testing. I would be interested in how we could define that and whether interest is there in creating more intensive assurance tests separately from basic interoperability ones. *Title: *OAuth 2.0 Assurance * * *Outline* * * *Problem statement: *Provide an introduction to OAuth assurance based on my blogs and RFC 6819 *General recommendations: *Also part of intro presentation, explain that its necessary to address issues through profiling, testing and secure implementation and operations *Scope: *Focus on the basic OAuth 2.0 specification, not getting into unresolved issues related to the many proposed extensions, such as token contents, or semantics *Discussion topic 1: *What would be a reasonable framework for OAuth 2.0 assurance levels, and how might those map to NIST Levels of Assurance (LOAs) 1 or 2? *Discussion topic 2:* What are "10 commandments" for Secure OAuth 2.0 (or "10 deadly sins to avoid") and how would we test for them? *Discussion topic 3:* Future plans - how can we carry the output of this session forward? Is there a home somewhere for an OAuth 2.0 assurance standards group? Would some organization (or group) be willing to work on standing up a test server to look for the 10 deadly sins? Would some organization (or group) be willing to work developing secure, open source OAuth libraries validated to follow the 10 commandments? I already have a few folks interested in this panel and contributing ideas but would welcome a lot more. If you're attending IIW 17 and interested in contributing, please let me know via one of my communications channels such as @danblumSS or the comments thread on this post. *Related posts* - REST Uneasy: Do we Need to Worry about OAuth 2.0? - OAuth 2.0 Assurance Issues - Mitigating OAuth Security Issues with Good Profiling - OAuth 2.0 and RESTful Protocol Security Testing Challenges - Piling on OAuth *Information on Internet Identity Workshop (IIW) * - http://iiw.idcommons.net/Main_Page - http://iiw.idcommons.net/images/1/13/IIW16_Book_of_Proceedings.PDF Best regards, Dan Blum Respect Network Principal Consultant and Chief Architect http://security-architect.blogspot.com --089e0115f49adcc80604e8bd8e60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After spending some time over the last few months looking = into OAuth assurance issues, I decided that I'll propose a panel on the= topic next week at IIW. My initial take on the proposed session is describ= ed in the blog post at this link=A0and is = summarized below as well. As I've written in several related articles, = OAuth 2.0 has some significant assurance issues. And while the community di= d an excellent job documenting these issues in RFC 6819 on security conside= rations, to my knowledge there hasn't been much discussion on how the a= ssurance of an implementation should be tested or on how customers or relyi= ng parties are supposed to know whether a given implementation has been imp= lemented in a robust manner.

With all the work on OAuth 2.0 interoperability testing, I s= ense an opportunity to inject some assurance testing into the process. Not = full penetration testing or vulnerability testing by any, but perhaps some = basic robustness testing. I would be interested in how we could define that= and whether interest is there in creating more intensive assurance tests s= eparately from basic interoperability ones.

Title:=A0OAuth 2.0 Assurance

Outli= ne

Problem statement:=A0Provide an introduction to OAuth assurance base= d on my blogs and RFC 6819

General recommendations:=A0Also part of intro p= resentation, explain that its necessary to address issues through profiling= , testing and secure implementation and operations

Scope:=A0Focus on the basic OAuth 2.0 specifica= tion, not getting into unresolved issues related to the many proposed exten= sions, such as token contents, or semantics

Discussion topic 1:=A0What would be a reasonabl= e framework for OAuth 2.0 assurance levels, and how might those map to NIST= Levels of Assurance (LOAs) 1 or 2?

Discussion topic 2:=A0What are "10 command= ments" for Secure OAuth 2.0 (or "10 deadly sins to avoid") a= nd how would we test for them?

Discussion topic 3:=A0Future plans - how can we carry the output of this= session forward? Is there a home somewhere for an OAuth 2.0 assurance stan= dards group? Would some organization (or group) be willing to work on stand= ing up a test server to look for the 10 deadly sins? Would some organizatio= n (or group) be willing to work developing secure, open source OAuth librar= ies validated to follow the 10 commandments?

I already have a few folks interested in this panel an= d contributing ideas but would welcome a lot more. If you're attending = IIW 17 and interested in contributing, please let me know via one of my com= munications channels such as @danblumSS or the comments thread on this post= .

Related posts
Information on Internet Identity Workshop (IIW)=A0<= /b>

Best regards,
Dan Blum
R= espect Network
Principal Consultant and Chief Architect
http://security-archite= ct.blogspot.com
--089e0115f49adcc80604e8bd8e60-- From pmhsfelix@gmail.com Tue Oct 15 02:06:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E3611E817C for ; Tue, 15 Oct 2013 02:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaqO-cQJuP+K for ; Tue, 15 Oct 2013 02:06:25 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5E11E8179 for ; Tue, 15 Oct 2013 02:06:14 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hu8so5170743vcb.3 for ; Tue, 15 Oct 2013 02:06:14 -0700 (PDT) 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=Hbc8rv3VhOFawyhc2d3wgAxa4L0dSnu1aqKQslgeLrU=; b=RdhEXVqmsoGy/ATtFs4WhwjbXv0Z6auFBwg73/W5Kp2xFsX8NbJeyGaRLyJSAR3gvO wixb414FLPN9hzZVlsSSxofBh8aoGzRPvkiXsg+U7pW7YIUyndKFpnCtFW2nmIjQhDsE xBxLgIuzYb5oW5+Cbhktqd+JFDY0VWRp8bEn9nGLP07TBb5U1wHrGuTYAn5pz+FosKoQ D9PSJKjlK/el7InrXPKHYpaBbVxMWC0muPgYXxoGIWP7fp2mrZIITACXiZDbFsT86+l1 bNRWKeKZA9eyRDbYuX9YWx3aCxi6r9RqB6IMLEUIGMZj5GV89HTRDEyKKl6gwCS6mePX RhcA== MIME-Version: 1.0 X-Received: by 10.52.230.102 with SMTP id sx6mr32713891vdc.15.1381827974326; Tue, 15 Oct 2013 02:06:14 -0700 (PDT) Received: by 10.220.169.3 with HTTP; Tue, 15 Oct 2013 02:06:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 10:06:14 +0100 Message-ID: From: Pedro Felix To: oauth list Content-Type: multipart/alternative; boundary=089e0111ae348cf12c04e8c3e5fb Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 09:06:34 -0000 --089e0111ae348cf12c04e8c3e5fb Content-Type: text/plain; charset=ISO-8859-1 Hi, Is this applicable to public (non-confidential) clients only? For confidential clients, the verification of the client_secret doesn't seem to be addressed by this proposal (token endpoint interactions). We could however extend it to address this scenario, namely by using encrypted JWTs with client_secret verification information. Thanks Pedro On Tue, Oct 15, 2013 at 1:01 AM, John Bradley wrote: > A new version of I-D, draft-bradley-stateless-oauth-client-00.txt > has been successfully submitted by John Bradley and posted to the > IETF repository. > > Filename: draft-bradley-stateless-oauth-client > Revision: 00 > Title: Stateless Client Identifier for OAuth 2 > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client > Htmlized: > http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 > > > Abstract: > This draft provides a method for communicating information about an > OAuth client through its client identifier allowing for fully > stateless operation. > > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0111ae348cf12c04e8c3e5fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Is this applicable to public = (non-confidential) clients only? For confidential clients, the verification= of the client_secret doesn't seem to be addressed by this proposal (to= ken endpoint interactions).
We could however extend it to address this scenario, namely by using encryp= ted JWTs with client_secret verification information.

Thanks
Pedro



On Tue, Oct 15, 2013 at 1:01 AM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
A new version of I-D, draft-bradley-sta= teless-oauth-client-00.txt
has been successfully submitted by John Bradl= ey and posted to the
IETF repository.

Filename: =A0draft-bradley-stateless-oauth-client
Revision: =A000
Title: =A0Stateless Client Identifier for OAuth 2
Creation date: =A02013-10-15
Group: =A0Individual Submission
Number of pages: 4
URL:= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0htt= p://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.tx= t
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatrack= er.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized: =A0= =A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-br= adley-stateless-oauth-client-00


Abstract:
=A0=A0This draft provides a method for communicating i= nformation about an
=A0=A0OAuth client through its client identifier all= owing for fully
=A0=A0stateless operation.





Please= note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at=A0tools.ietf.org.

The IETF Secret= ariat

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


--089e0111ae348cf12c04e8c3e5fb-- From ve7jtb@ve7jtb.com Tue Oct 15 03:43:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6DF11E81C9 for ; Tue, 15 Oct 2013 03:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-F4tF+QfdPT for ; Tue, 15 Oct 2013 03:43:42 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id BA4A311E81C7 for ; Tue, 15 Oct 2013 03:43:39 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id nc12so6125653qeb.30 for ; Tue, 15 Oct 2013 03:43:38 -0700 (PDT) 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=TkJmgwCCuFyV9PCeTFY4U7/kD+Ifexp7MusukXX7C2Q=; b=Rhzz/4AhdnZFiMrTy4wIgeDWXKx+FRht4BmVNMFXzUN6V2/5Fqt1DFJSzQNrZWotET ANSHkk0MMdQKnJhWdYcSPKdbRMovsu9gQjImBC1lL2JyGJ2OEw8IQzmclejm6WNPfAAn e45o/0PCeKCuCMqt3QA5OcofR7bRaK8w37/m1+y+WMyv0r89r2h3WiYKpvy2gNgA6HAv zrfzJ/U8NJEGHn+h2spki4VTxngOksEP4y3qYrrVW9D4ABti/NwNFtbEQ9SvNBltQFaO 0dyZlrf7ucjNV8plE8TecbXWlrziqbE0l28EXKey/cNRzSDvzyaI7X5NkI+ZEciR5Oup AUew== X-Gm-Message-State: ALoCoQlsC5O4mPwBGfi0cHRtGnBa8oPFWKHKTIYTs1dZvGlxpTbZ+Z9qIpjDGB1aTG/R31CGMuyQ X-Received: by 10.49.117.133 with SMTP id ke5mr15261734qeb.53.1381833818702; Tue, 15 Oct 2013 03:43:38 -0700 (PDT) Received: from [192.168.1.216] (190-20-0-56.baf.movistar.cl. [190.20.0.56]) by mx.google.com with ESMTPSA id n7sm154308496qai.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 03:43:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5C62CAD6-43D1-4683-9A75-B771CB80F148"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: John Bradley In-Reply-To: Date: Tue, 15 Oct 2013 07:43:09 -0300 Message-Id: <31253A3D-F51B-4D5D-A6DC-CCA107396581@ve7jtb.com> References: To: Pedro Felix X-Mailer: Apple Mail (2.1510) Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:43:47 -0000 --Apple-Mail=_5C62CAD6-43D1-4683-9A75-B771CB80F148 Content-Type: multipart/alternative; boundary="Apple-Mail=_7AC2C332-2473-4BD4-965B-95C5634CA8D0" --Apple-Mail=_7AC2C332-2473-4BD4-965B-95C5634CA8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It is intended for confidential clients. In 2 it states that you may encrypt the JWT. =20 If asymmetric authentication using the assertion profile is used the = registration endpoint would put the client's public key in the JWT and = would not need to encrypt it. I expect that encrypting the JWT with integrity AES+HMAC would be a good = solution for clients using symmetric secrets. =20 The exact method for doing this can be determined by the AS as it is a = token from the AS to the AS there are no interoperability issues with = the symmetric case. In the case of a client using asymmetric assertion profile = authentication it is possible that the registration endpoint is not = tightly coupled to the registration endpoint. A single registration endpoint could issue stateless client_id that are = accepted and verified by multiple AS. In this case the format of the = JWT needs standardization for interoperability. John B. On 2013-10-15, at 6:06 AM, Pedro Felix wrote: > Hi, >=20 > Is this applicable to public (non-confidential) clients only? For = confidential clients, the verification of the client_secret doesn't seem = to be addressed by this proposal (token endpoint interactions). > We could however extend it to address this scenario, namely by using = encrypted JWTs with client_secret verification information. >=20 > Thanks > Pedro >=20 >=20 >=20 > On Tue, Oct 15, 2013 at 1:01 AM, John Bradley = wrote: > A new version of I-D, draft-bradley-stateless-oauth-client-00.txt > has been successfully submitted by John Bradley and posted to the > IETF repository. >=20 > Filename: draft-bradley-stateless-oauth-client > Revision: 00 > Title: Stateless Client Identifier for OAuth 2 > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-0= 0.txt > Status: = http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client > Htmlized: = http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 >=20 >=20 > Abstract: > This draft provides a method for communicating information about an > OAuth client through its client identifier allowing for fully > stateless operation. >=20 >=20 >=20 >=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 > The IETF Secretariat >=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=_7AC2C332-2473-4BD4-965B-95C5634CA8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It is = intended for confidential clients.

In 2 it states = that you may encrypt the JWT.   

If = asymmetric authentication using the assertion profile is used the = registration endpoint would put the client's public key in the JWT and = would not need to encrypt it.

I expect that = encrypting the JWT with integrity AES+HMAC would be a good solution for = clients using symmetric secrets.  

The = exact method for doing this can be determined by the AS as it is a token = from the AS to the AS there are no interoperability issues with the = symmetric case.

In the case of a client using = asymmetric assertion profile authentication it is possible that the = registration endpoint is not tightly coupled to the registration = endpoint.
A single registration endpoint could issue stateless = client_id that are accepted and verified by multiple AS.  In this = case the format of the JWT needs standardization for = interoperability.

John = B.



On 2013-10-15, = at 6:06 AM, Pedro Felix <pmhsfelix@gmail.com> = wrote:

Hi,

Is this = applicable to public (non-confidential) clients only? For confidential = clients, the verification of the client_secret doesn't seem to be = addressed by this proposal (token endpoint interactions).
We could however extend it to address this scenario, namely by using = encrypted JWTs with client_secret verification = information.

Thanks
Pedro
=


On Tue, Oct 15, 2013 at 1:01 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
A new version of I-D, = draft-bradley-stateless-oauth-client-00.txt
has been successfully = submitted by John Bradley and posted to the
IETF = repository.

Filename: =  draft-bradley-stateless-oauth-client
Revision: =  00
Title: =  Stateless = Client Identifier for OAuth 2
Creation date:  2013-10-15
Group:  Individual = Submission
Number of pages: 4
URL: =             http://www.ietf.org/internet-drafts/draft-bradley-statel= ess-oauth-client-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bradley-stateless-= oauth-client
Htmlized: =        http://tools.ietf.org/html/draft-bradley-stateless-oauth= -client-00


Abstract:
  This draft provides a method for = communicating information about an
  OAuth client through = its client identifier allowing for fully
  stateless = operation.





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.

The IETF = Secretariat

_______________________________________________
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=_7AC2C332-2473-4BD4-965B-95C5634CA8D0-- --Apple-Mail=_5C62CAD6-43D1-4683-9A75-B771CB80F148 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE1MTA0MzA5WjAjBgkqhkiG9w0BCQQxFgQU+AHWcJic QhfjfyzquTW6tusGob0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEACi8GpJ+gT75OuIe9sDQFHa6C5QGp1NC4OETMfpCt PYnxlYygekILDO0vROyc7heiJ+e+qCrL5PTrJ8KfZS2UcF+051KKOTfwmG/t40oMx6KQhLd3PnWm txYttTchsgUdImaNEbDvsKf3XD15YPHWeSPiAnjgHL0psekhj/EaWozwRMTd71rC6oq0AUaYWgtg xrZjZ5IK4PH1QGZPWYPDggeCNwRcO5/mawRqVpBFHkM0RATSfSm+QTHXw4mDprjoRsVo8nuEFYIL 0McodSPOELntcPNeJSex1CJveCPohLNjIeu3AkpIw+KO1zcraobJlNnjM87iUDFMorvs2mJVSwAA AAAAAA== --Apple-Mail=_5C62CAD6-43D1-4683-9A75-B771CB80F148-- From vladimir@nimbusds.com Thu Oct 17 23:34:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8921F9F23 for ; Thu, 17 Oct 2013 23:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR75SLC1RD5Z for ; Thu, 17 Oct 2013 23:34:31 -0700 (PDT) Received: from n1plsmtp07-04.prod.ams1.secureserver.net (n1plsmtp07-04-02.prod.ams1.secureserver.net [188.121.52.8]) by ietfa.amsl.com (Postfix) with SMTP id 8D62A21F9F34 for ; Thu, 17 Oct 2013 23:34:28 -0700 (PDT) Received: (qmail 13653 invoked from network); 18 Oct 2013 06:34:24 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plsmtp07-04.prod.ams1.secureserver.net with SMTP; 18 Oct 2013 06:34:20 -0000 Received: (qmail 17464 invoked by uid 99); 18 Oct 2013 06:34:20 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.250.96 User-Agent: Workspace Webmail 5.6.43 Message-Id: <20131017233419.cc40c4f3d92d2001859047cd8cabb9ab.3b32704b26.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "John Bradley" , "oauth list" Date: Thu, 17 Oct 2013 23:34:19 -0700 Mime-Version: 1.0 Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 06:34:35 -0000 This stuff is brilliant and very useful, thank you guys for writing it=0Aup= !=0A=0AOne question about the spec: Is the "kid" JOSE header field=0Aintent= ionally duplicated in the JWT claims set?=0A=0A=0AVladimir=0A=0A--=0AVladim= ir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A =0A=0A=0A=0A=0A= =0A-------- Original Message --------=0ASubject: [OAUTH-WG] FYI per a reque= st on the last conference call, this=0Ais a method for making client regist= ration stateless.=0AFrom: John Bradley =0ADate: Tue, Oct= ober 15, 2013 1:01 am=0ATo: oauth list =0A=0AA new version = of I-D, draft-bradley-stateless-oauth-client-00.txt=0Ahas been successfully= submitted by John Bradley and posted to the=0AIETF repository.=0A=0AFilena= me: draft-bradley-stateless-oauth-client=0ARevision: 00=0ATitle: Statel= ess Client Identifier for OAuth 2=0ACreation date: 2013-10-15=0AGroup: I= ndividual Submission=0ANumber of pages: 4=0AURL: =0Ahttp://www.i= etf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt=0AStatu= s: =0Ahttp://datatracker.ietf.org/doc/draft-bradley-stateless-oauth= -client=0AHtmlized: =0Ahttp://tools.ietf.org/html/draft-bradley-state= less-oauth-client-00=0A=0A=0AAbstract:=0A This draft provides a method for= communicating information about an=0A OAuth client through its client ide= ntifier allowing for fully=0A stateless operation.=0A=0A=0A=0A=0A=0APlease= note that it may take a couple of minutes from the time of=0Asubmission=0A= until the htmlized version and diff are available at tools.ietf.org.=0A=0AT= he IETF Secretariat_______________________________________________=0AOAuth = mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth= From sakimura@gmail.com Sat Oct 19 03:15:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D381721F9FF6 for ; Sat, 19 Oct 2013 03:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8qH2UUadOib for ; Sat, 19 Oct 2013 03:15:38 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DF7FC11E8164 for ; Sat, 19 Oct 2013 03:15:37 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so1611786lab.11 for ; Sat, 19 Oct 2013 03:15:36 -0700 (PDT) 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=FiPNWZFckQbfgGs3Yi2K6q4BHFyizjl8bIpGbhtU7oI=; b=Bhym6Wip4KmoAxCHOT6DqFJzDHBt32xFZccMOJmgsy1bGTLzHM/5ady3FuBssJphQ/ jchrCt1YG4eJaRiP9PIvFHZJ0DgYensCHJGN5KnKxCGxE6IXxGpXaryRkyEx91Giks4l pxyCsOROulMdYDADKYbusFrXQVhkZlVL9aBYEWBhYVhumFANHgTAtFxy2ql1679flYVR GZ/taR1Zl2/bShu3pJD2js2RRSQvQ8nXD7P785gPIY+uTBXJiNCZ+Uzrhv7RAvG72Yf0 /txdCVexOrOSDm/yzLlTGlX4UNwZ6VBL8eMaEPD8rjiHBTSOAn/bbFoyW7S83U7sXNxo BI9g== MIME-Version: 1.0 X-Received: by 10.112.235.3 with SMTP id ui3mr658971lbc.44.1382177736602; Sat, 19 Oct 2013 03:15:36 -0700 (PDT) Received: by 10.112.134.38 with HTTP; Sat, 19 Oct 2013 03:15:36 -0700 (PDT) In-Reply-To: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 19:15:36 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a11c3172001b8ad04e91555fe Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 10:15:40 -0000 --001a11c3172001b8ad04e91555fe Content-Type: text/plain; charset=ISO-8859-1 Incorporated the discussion at Berlin meeting and after in the ML. Best, Nat ---------- Forwarded message ---------- From: Date: 2013/10/19 Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt To: Nat Sakimura , John Bradley < jbradley@pingidentity.com>, Naveen Agarwal A new version of I-D, draft-sakimura-oauth-tcse-02.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Filename: draft-sakimura-oauth-tcse Revision: 02 Title: OAuth Symmetric Proof of Posession for Code Extension Creation date: 2013-10-19 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 Abstract: The OAuth 2.0 public client utilizing authorization code grant is susceptible to the code interception attack. This specification describe a mechanism that acts as a control against this threat. 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. The IETF Secretariat -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3172001b8ad04e91555fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Incorporated the discussion at Berlin meeting and after in= the ML.=A0

Best,=A0

Nat
---------- Forwarded message ----------
From= : <internet-drafts@ietf.org>
Date: 2013/10/19
Subject: New Version Notification for draft-sakimura-oa= uth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sakimura-oauth-tcse
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 OAuth Symmetric Proof of Posession for Code Exte= nsion
Creation date: =A0 2013-10-19
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/in= ternet-drafts/draft-sakimura-oauth-tcse-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra= ft-sakimura-oauth-tcse
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-sakimu= ra-oauth-tcse-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff= ?url2=3Ddraft-sakimura-oauth-tcse-02

Abstract:
=A0 =A0The OAuth 2.0 public client utilizing authorization code grant is =A0 =A0susceptible to the code interception attack. =A0This specification =A0 =A0describe a mechanism that acts as a control against this threat.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3172001b8ad04e91555fe-- From jricher@mitre.org Sun Oct 20 22:26:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E42D11E8159 for ; Sun, 20 Oct 2013 22:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnanMSziGoNW for ; Sun, 20 Oct 2013 22:26:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB2FC11E8153 for ; Sun, 20 Oct 2013 22:26:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1A9D21F0526; Mon, 21 Oct 2013 01:26:27 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E86D51F051D; Mon, 21 Oct 2013 01:26:26 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 01:26:26 -0400 From: "Richer, Justin P." To: Pedro Felix Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. Thread-Index: AQHOzh4WOjkR+xv0VkG8Vuns2tz0jQ== Date: Mon, 21 Oct 2013 05:26:25 +0000 Message-ID: <866CAAB1-3BA8-4776-9F53-9E2A461F1D44@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: [172.31.39.159] Content-Type: multipart/alternative; boundary="_000_866CAAB13BA847769F539E2A461F1D44mitreorg_" MIME-Version: 1.0 Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 05:26:47 -0000 --_000_866CAAB13BA847769F539E2A461F1D44mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have a confidential client using a traditional symmetric secret, fro= m the client's perspective you wouldn't pack the secret into the client_id = with this method any more than you would pack it into the client_id using a= normal method -- at least as far as the client is concerned, they're two s= eparate and unrelated values, generally treated as opaque. Ideally with a s= tateless client you'd be using some kind of asymmetric key with the asserti= on profile or something like that for client auth, and I think that's going= to be the most common case for people who are doing a truly stateless serv= er environment, but there are a few other ways you could handle it. As John points out in another thread, you could encrypt the claims set to t= he AS's key. This would let you put the secret itself directly inside the c= lient_id without the client being able to muck about with it, and without e= xposing it to the browser or other agents that get the client_id (which, yo= u must remember, is essentially public information). Alternatively, you could tie the client ID to the secret by issuing a signe= d JWT as the client_secret as well, with the client_secret's JWT containing= the same subject as the client_id's JWT. There are probably some other tricks you could do, but these are the cleane= st two that come to mind for me. Maybe others can fill in on what those mig= ht be. -- Justin On Oct 15, 2013, at 5:06 AM, Pedro Felix > wrote: Hi, Is this applicable to public (non-confidential) clients only? For confident= ial clients, the verification of the client_secret doesn't seem to be addre= ssed by this proposal (token endpoint interactions). We could however extend it to address this scenario, namely by using encryp= ted JWTs with client_secret verification information. Thanks Pedro On Tue, Oct 15, 2013 at 1:01 AM, John Bradley > wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateles= s-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oa= uth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-c= lient-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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_866CAAB13BA847769F539E2A461F1D44mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <077E6EA72F0AD94FA02867871A470D46@imc.mitre.org> Content-Transfer-Encoding: quoted-printable If you have a confidential client using a traditional symmetric secret, fro= m the client's perspective you wouldn't pack the secret into the client_id = with this method any more than you would pack it into the client_id using a= normal method -- at least as far as the client is concerned, they're two separate and unrelated values, gen= erally treated as opaque. Ideally with a stateless client you'd be using so= me kind of asymmetric key with the assertion profile or something like that= for client auth, and I think that's going to be the most common case for people who are doing a truly stateles= s server environment, but there are a few other ways you could handle it.

As John points out in another thread, you could encrypt the claims set= to the AS's key. This would let you put the secret itself directly inside = the client_id without the client being able to muck about with it, and with= out exposing it to the browser or other agents that get the client_id (which, you must remember, is essentia= lly public information).

Alternatively, you could tie the client ID to the secret by issuing a = signed JWT as the client_secret as well, with the client_secret's JWT conta= ining the same subject as the client_id's JWT.

There are probably some other tricks you could do, but these are the c= leanest two that come to mind for me. Maybe others can fill in on what thos= e might be.

 -- Justin

On Oct 15, 2013, at 5:06 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Hi,

Is this applicable to public (non-confidential) clients only? For confident= ial clients, the verification of the client_secret doesn't seem to be addre= ssed by this proposal (token endpoint interactions).
We could however extend it to address this scenario, namely by using e= ncrypted JWTs with client_secret verification information.

Thanks
Pedro



On Tue, Oct 15, 2013 at 1:01 AM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:
A new version of I-D, draft-bradley-sta= teless-oauth-client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:  draft-bradley-s= tateless-oauth-client
Revision:  00
Title:  Stateless Client Identifier for OAuth 2
Creation date:  2013-10-15=
Group:  Individual Submission
Number of pages: 4
URL:            &nbs= p;http://www.ietf.org/internet-drafts/dr= aft-bradley-stateless-oauth-client-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-c= lient
Htmlized:        h= ttp://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information abou= t an
  OAuth client through its client identifier allowing for fully   stateless operation.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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


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

--_000_866CAAB13BA847769F539E2A461F1D44mitreorg_-- From phil.hunt@oracle.com Mon Oct 21 10:21:38 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F511E8201 for ; Mon, 21 Oct 2013 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgJ6FRziuK+1 for ; Mon, 21 Oct 2013 10:21:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA711E827E for ; Mon, 21 Oct 2013 10:21:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LHLPGo023911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 17:21:26 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 r9LHLO6U016442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 17:21:24 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LHLOtI019050; Mon, 21 Oct 2013 17:21:24 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Oct 2013 10:21:23 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B9F8B899-D0D4-4480-B716-B599B307E6E9" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Mon, 21 Oct 2013 10:21:29 -0700 Message-Id: References: To: John Bradley X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:21:38 -0000 --Apple-Mail=_B9F8B899-D0D4-4480-B716-B599B307E6E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am assuming that this draft fits with the dyn reg draft. It makes the = assumption that every single client is somehow potentially different in = terms of registration. This draft encodes the registration values in = the JWT so that stateless registration can be achieved. Dynamic registration takes a different view from client association, in = that dynamic registration has no notion of fixed client software = releases that are deployed many times. As such there is no fixed = registration profile. Every client is potentially different. In contrast = Client Association + Software statements, clients are identified as a = particular software and are fixed.=20 Have I read this correctly? =46rom a policy perspective, how would a service provider handle = registration of clients that are all potentially different? Why would = individual clients need to differ in registration (other than in the = tokens negotiated with a particular deployment SP)? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-14, at 5:01 PM, John Bradley wrote: > A new version of I-D, draft-bradley-stateless-oauth-client-00.txt > has been successfully submitted by John Bradley and posted to the > IETF repository. >=20 > Filename: draft-bradley-stateless-oauth-client > Revision: 00 > Title: Stateless Client Identifier for OAuth 2 > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-0= 0.txt > Status: = http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client > Htmlized: = http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 >=20 >=20 > Abstract: > This draft provides a method for communicating information about an > OAuth client through its client identifier allowing for fully > stateless operation. >=20 >=20 >=20 >=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 > The IETF Secretariat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B9F8B899-D0D4-4480-B716-B599B307E6E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

A new = version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been = successfully submitted by John Bradley and posted to the
IETF = repository.

Filename: =  draft-bradley-stateless-oauth-client
Revision: =  00
Title:  Stateless Client Identifier = for OAuth 2
Creation date:  2013-10-15
Group: =  Individual Submission
Number of pages: 4
URL: =             http://www.ietf.org/internet-drafts/draft-bradley-stateless= -oauth-client-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00

Abstract:
  This draft provides a method for = communicating information about an
  OAuth client through = its client identifier allowing for fully
  stateless = operation.





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.

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

= --Apple-Mail=_B9F8B899-D0D4-4480-B716-B599B307E6E9-- From phil.hunt@oracle.com Mon Oct 21 10:22:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E84611E86A3 for ; Mon, 21 Oct 2013 10:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMfPKniGetUS for ; Mon, 21 Oct 2013 10:22:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18111E835E for ; Mon, 21 Oct 2013 10:22:51 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LHMoTO025455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Oct 2013 17:22:51 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LHMn9L020919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Oct 2013 17:22:50 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LHMnJ6019330 for ; Mon, 21 Oct 2013 17:22:49 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Oct 2013 10:22:49 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_3A6458F3-006A-4E03-AEF6-C97ED288489A" Message-Id: <77A63E1E-71D9-42DA-891A-1090606CEC28@oracle.com> Date: Mon, 21 Oct 2013 10:22:54 -0700 To: oauth list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] IIW meet up? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:22:58 -0000 --Apple-Mail=_3A6458F3-006A-4E03-AEF6-C97ED288489A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is anyone attending IIW tomorrow or Wednesday? It would be good to informally go through and compare the outstanding = registration drafts. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_3A6458F3-006A-4E03-AEF6-C97ED288489A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Is = anyone attending IIW tomorrow or Wednesday?

It would = be good to informally go through and compare the outstanding = registration drafts.

Phil
= --Apple-Mail=_3A6458F3-006A-4E03-AEF6-C97ED288489A-- From Michael.Jones@microsoft.com Mon Oct 21 10:55:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2B11E8218 for ; Mon, 21 Oct 2013 10:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhZdHVEN7yt9 for ; Mon, 21 Oct 2013 10:55:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 147C011E823F for ; Mon, 21 Oct 2013 10:55:11 -0700 (PDT) Received: from BY2PR03CA036.namprd03.prod.outlook.com (10.242.234.157) by BY2PR03MB287.namprd03.prod.outlook.com (10.242.37.26) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 21 Oct 2013 17:55:07 +0000 Received: from BN1AFFO11FD027.protection.gbl (2a01:111:f400:7c10::114) by BY2PR03CA036.outlook.office365.com (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Mon, 21 Oct 2013 17:55:07 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD027.mail.protection.outlook.com (10.58.52.87) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Mon, 21 Oct 2013 17:55:06 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.212]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0158.002; Mon, 21 Oct 2013 17:54:26 +0000 From: Mike Jones To: Phil Hunt , oauth list Thread-Topic: [OAUTH-WG] IIW meet up? Thread-Index: AQHOzoJKdhVamEc2fkW7d4qGOaoF4pn/b+sg Date: Mon, 21 Oct 2013 17:54:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377E08DC6@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <77A63E1E-71D9-42DA-891A-1090606CEC28@oracle.com> In-Reply-To: <77A63E1E-71D9-42DA-891A-1090606CEC28@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394377E08DC6TK5EX14MBXC286r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454003)(15974865002)(19300405004)(15202345003)(16601075003)(85306002)(74502001)(77982001)(59766001)(71186001)(81342001)(81816001)(81542001)(47446002)(85806002)(80022001)(15975445006)(74366001)(81686001)(77096001)(74662001)(83072001)(56776001)(33656001)(84326002)(76482001)(66066001)(54356001)(53806001)(55846006)(69226001)(54316002)(31966008)(6806004)(79102001)(46102001)(76786001)(65816001)(76796001)(56816003)(83322001)(19580395003)(19580405001)(74876001)(50986001)(4396001)(47736001)(63696002)(80976001)(16236675002)(74706001)(51856001)(49866001)(44976005)(20776003)(512954002)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB287; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 00064751B6 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [OAUTH-WG] IIW meet up? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:55:30 -0000 --_000_4E1F6AAD24975D4BA5B168042967394377E08DC6TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many of us are. See the attendee list at http://iiw17.eventbrite.com/. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, October 21, 2013 10:23 AM To: oauth list Subject: [OAUTH-WG] IIW meet up? Is anyone attending IIW tomorrow or Wednesday? It would be good to informally go through and compare the outstanding regis= tration drafts. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_4E1F6AAD24975D4BA5B168042967394377E08DC6TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many of us are.  See= the attendee list at http://iiw17.eventbrite.com/.<= o:p>

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 21, 2013 10:23 AM
To: oauth list
Subject: [OAUTH-WG] IIW meet up?

 

Is anyone attending IIW tomorrow or Wednesday?<= /o:p>

 

It would be good to informally go through and compar= e the outstanding registration drafts.

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

--_000_4E1F6AAD24975D4BA5B168042967394377E08DC6TK5EX14MBXC286r_-- From Michael.Jones@microsoft.com Mon Oct 21 10:58:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9811E83AF for ; Mon, 21 Oct 2013 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yib2nuEMbQod for ; Mon, 21 Oct 2013 10:57:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 03BAD11E832C for ; Mon, 21 Oct 2013 10:57:38 -0700 (PDT) Received: from BL2PR03CA015.namprd03.prod.outlook.com (10.141.66.23) by BL2PR03MB099.namprd03.prod.outlook.com (10.255.230.22) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 21 Oct 2013 17:57:36 +0000 Received: from BN1BFFO11FD041.protection.gbl (2a01:111:f400:7c10::143) by BL2PR03CA015.outlook.office365.com (2a01:111:e400:c1b::23) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Mon, 21 Oct 2013 17:57:36 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD041.mail.protection.outlook.com (10.58.53.199) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Mon, 21 Oct 2013 17:57:36 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.212]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0158.002; Mon, 21 Oct 2013 17:56:50 +0000 From: Mike Jones To: Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. Thread-Index: AQHOyTnWK6Aumw1QBUOu6SY4hC1n9Jn/cYGAgAAJSzA= Date: Mon, 21 Oct 2013 17:56:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394377E08E0BTK5EX14MBXC286r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(30513003)(377424004)(69234005)(377454003)(24454002)(199002)(189002)(52084003)(55846006)(74502001)(16236675002)(31966008)(56776001)(15975445006)(76796001)(54316002)(76482001)(56816003)(20776003)(77096001)(81816001)(47446002)(79102001)(66066001)(65816001)(77982001)(81686001)(16601075003)(15974865002)(80022001)(54356001)(59766001)(19300405004)(76786001)(14971765001)(74876001)(74706001)(63696002)(80976001)(74662001)(4396001)(44976005)(46102001)(51856001)(6806004)(83072001)(47976001)(50986001)(85306002)(19580405001)(19580395003)(83322001)(53806001)(512954002)(69226001)(15202345003)(84326002)(49866001)(33656001)(47736001)(81342001)(85806002)(81542001)(71186001)(74366001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB099; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 00064751B6 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:58:09 -0000 --_000_4E1F6AAD24975D4BA5B168042967394377E08E0BTK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For what it's worth, the latest public dynamic registration working group d= raft has software_id and software_version fields to allow statements to be = made about the fixed client software releases that are deployed many times,= of which you speak. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, October 21, 2013 10:21 AM To: John Bradley Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this= is a method for making client registration stateless. I am assuming that this draft fits with the dyn reg draft. It makes the as= sumption that every single client is somehow potentially different in terms= of registration. This draft encodes the registration values in the JWT so= that stateless registration can be achieved. Dynamic registration takes a different view from client association, in tha= t dynamic registration has no notion of fixed client software releases that= are deployed many times. As such there is no fixed registration profile. E= very client is potentially different. In contrast Client Association + Soft= ware statements, clients are identified as a particular software and are fi= xed. Have I read this correctly? >From a policy perspective, how would a service provider handle registration= of clients that are all potentially different? Why would individual client= s need to differ in registration (other than in the tokens negotiated with = a particular deployment SP)? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-14, at 5:01 PM, John Bradley > wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateles= s-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oa= uth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-c= lient-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394377E08E0BTK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For what it’s worth= , the latest public dynamic registration working group draft has software_i= d and software_version fields to allow statements to be made about the fixed client software releases that are deployed many times, of which = you speak.

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 21, 2013 10:21 AM
To: John Bradley
Cc: oauth list
Subject: Re: [OAUTH-WG] FYI per a request on the last conference cal= l, this is a method for making client registration stateless.

 

I am assuming that this draft fits with the dyn reg = draft.  It makes the assumption that every single client is somehow po= tentially different in terms of registration.  This draft encodes the = registration values in the JWT so that stateless registration can be achieved.

 

Dynamic registration takes a different view from cli= ent association, in that dynamic registration has no notion of fixed client= software releases that are deployed many times. As such there is no fixed = registration profile. Every client is potentially different. In contrast Client Association + Software st= atements, clients are identified as a particular software and are fixed.&nb= sp;

 

Have I read this correctly?

 

From a policy perspective, how would a service provi= der handle registration of clients that are all potentially different? Why = would individual clients need to differ in registration (other than in the = tokens negotiated with a particular deployment SP)?

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:



A new version of I-D, draft-bradley-stateless-oauth-= client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:      = ;   draft-bradley-stateless-oauth-client
Revision:      = ;   00
Title:      &n= bsp;         Stateless Clien= t Identifier for OAuth 2
Creation date:  2013-10-15
Group:      &n= bsp;       Individual Submission
Number of pages: 4
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-bradley-statel= ess-oauth-client-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.o= rg/html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information abou= t an
  OAuth client through its client identifier allowing for fully   stateless operation.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

 

--_000_4E1F6AAD24975D4BA5B168042967394377E08E0BTK5EX14MBXC286r_-- From phil.hunt@oracle.com Mon Oct 21 11:02:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C2111E8218 for ; Mon, 21 Oct 2013 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12ZWOEeii7kp for ; Mon, 21 Oct 2013 11:02:39 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0343411E8137 for ; Mon, 21 Oct 2013 11:02:38 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LI2be8012560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 18:02:38 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LI2big005052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 18:02:37 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LI2bEb005044; Mon, 21 Oct 2013 18:02:37 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Oct 2013 11:02:36 -0700 References: <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-26D70770-2B51-4238-8609-FCC5A43354A2 Content-Transfer-Encoding: 7bit Message-Id: <519B95AD-7286-4923-A09A-606AA5E676C6@oracle.com> X-Mailer: iPhone Mail (11A501) From: Phil Hunt Date: Mon, 21 Oct 2013 11:02:27 -0700 To: Mike Jones X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:02:44 -0000 --Apple-Mail-26D70770-2B51-4238-8609-FCC5A43354A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. But that does not use the signed jwt assertion which "locks" the regist= ration profile. =20 Phil > On Oct 21, 2013, at 10:56, Mike Jones wrote:= >=20 > For what it=E2=80=99s worth, the latest public dynamic registration workin= g group draft has software_id and software_version fields to allow statement= s to be made about the fixed client software releases that are deployed many= times, of which you speak. > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt > Sent: Monday, October 21, 2013 10:21 AM > To: John Bradley > Cc: oauth list > Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, thi= s is a method for making client registration stateless. > =20 > I am assuming that this draft fits with the dyn reg draft. It makes the a= ssumption that every single client is somehow potentially different in terms= of registration. This draft encodes the registration values in the JWT so t= hat stateless registration can be achieved. > =20 > Dynamic registration takes a different view from client association, in th= at dynamic registration has no notion of fixed client software releases that= are deployed many times. As such there is no fixed registration profile. Ev= ery client is potentially different. In contrast Client Association + Softwa= re statements, clients are identified as a particular software and are fixed= .=20 > =20 > Have I read this correctly? > =20 > =46rom a policy perspective, how would a service provider handle registrat= ion of clients that are all potentially different? Why would individual clie= nts need to differ in registration (other than in the tokens negotiated with= a particular deployment SP)? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On 2013-10-14, at 5:01 PM, John Bradley wrote: >=20 >=20 > A new version of I-D, draft-bradley-stateless-oauth-client-00.txt > has been successfully submitted by John Bradley and posted to the > IETF repository. >=20 > Filename: draft-bradley-stateless-oauth-client > Revision: 00 > Title: Stateless Client Identifier for OAuth 2 > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-bradley-statele= ss-oauth-client-00.txt > Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-o= auth-client > Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-= client-00 >=20 >=20 > Abstract: > This draft provides a method for communicating information about an > OAuth client through its client identifier allowing for fully > stateless operation. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-26D70770-2B51-4238-8609-FCC5A43354A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. But that does not use the signed j= wt assertion which "locks" the registration profile.  

Phil

On Oct 21, 2013, at 10:56, Mike Jones <Michael.Jones@microsoft.com>= wrote:

=

For what it=E2=80=99s worth= , the latest public dynamic registration working group draft has software_id= and software_version fields to allow statements to be made about the fixed client software releases that are deployed many times, of which y= ou speak.

 

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

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 21, 2013 10:21 AM
To: John Bradley
Cc: oauth list
Subject: Re: [OAUTH-WG] FYI per a request on the last conference call= , this is a method for making client registration stateless.

 

I am assuming that this draft fits with the dyn reg d= raft.  It makes the assumption that every single client is somehow pote= ntially different in terms of registration.  This draft encodes the reg= istration values in the JWT so that stateless registration can be achieved.

 

Dynamic registration takes a different view from clie= nt association, in that dynamic registration has no notion of fixed client s= oftware releases that are deployed many times. As such there is no fixed reg= istration profile. Every client is potentially different. In contrast Client Association + Software stateme= nts, clients are identified as a particular software and are fixed. 

 

Have I read this correctly?

 

=46rom a policy perspective, how would a service prov= ider handle registration of clients that are all potentially different? Why w= ould individual clients need to differ in registration (other than in the to= kens negotiated with a particular deployment SP)?

 

 

On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:



A new version of I-D, draft-bradley-stateless-oauth-c= lient-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:      =    draft-bradley-stateless-oauth-client
Revision:      =    00
Title:      &nb= sp;         Stateless Client I= dentifier for OAuth 2
Creation date:  2013-10-15
Group:      &nb= sp;       Individual Submission
Number of pages: 4
URL:             = ;http://www.ietf.org/internet-drafts/draft-bradley-stateless= -oauth-client-00.txt
Status:          http://da= tatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.org= /html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information about= an
  OAuth client through its client identifier allowing for fully   stateless operation.





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.

The IETF Secretariat

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

 

= --Apple-Mail-26D70770-2B51-4238-8609-FCC5A43354A2-- From ve7jtb@ve7jtb.com Mon Oct 21 11:08:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7811E83E6 for ; Mon, 21 Oct 2013 11:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL5LYlYWHs-I for ; Mon, 21 Oct 2013 11:08:53 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A211E82BE for ; Mon, 21 Oct 2013 11:08:14 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l12so5597501wiv.1 for ; Mon, 21 Oct 2013 11:08:13 -0700 (PDT) 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=iM2NI4sfENYQzxQmFMIFMeaw761qIGh/TGfYsktwQkM=; b=RBUfi4ohNFq6KolxTOts5Dzsvvx5QCmEYLctRrje0350FWP+XRfHjuhPyRBgrm5sJV jmdaF/nc/lGUeEeSuGlWMeYGGlwqtjBZwggfBmFvVwe6PDltzm1NH9xcIrhTmJio8f2l ahnJ6s3xo1nWeDR+ahGh8A9hqnuBvcUW8yOEb8XjZVnC8NQ1pjGXdLh8xvMrLzPCNC/F gI+3BcB7ZKdTzLdzQAzwrBji0Cr5GaYjMTzx2R4Gob9/SToNJDu75jlcVZY3E0pZxMqF GhtZ2IsUiChI+LeL+BAkUOD+gies0m+2dJ1pSLxOsXxklQqrD6tqr85ppPWf+G3Q+RGj dGKA== X-Gm-Message-State: ALoCoQkUEzaYg5H6zEdtJdyXSFsoIEuAoZIP3//xBjXw1wuK64UIRgXUHJvehQj3/o5aMY39xAX5 X-Received: by 10.194.176.163 with SMTP id cj3mr14785091wjc.8.1382378893557; Mon, 21 Oct 2013 11:08:13 -0700 (PDT) Received: from ?IPv6:2620::1000:fd84:d9bb:162d:d2f0:e9e7? ([2620:0:1000:fd84:d9bb:162d:d2f0:e9e7]) by mx.google.com with ESMTPSA id jf2sm34643965wic.2.2013.10.21.11.08.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 11:08:12 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0840835F-E320-4AA6-9A2A-71B25341EC6F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: John Bradley In-Reply-To: <77A63E1E-71D9-42DA-891A-1090606CEC28@oracle.com> Date: Mon, 21 Oct 2013 11:08:10 -0700 Message-Id: <6E4F5EFB-3CA4-4D7A-89B2-CAED3D128E48@ve7jtb.com> References: <77A63E1E-71D9-42DA-891A-1090606CEC28@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1510) Cc: oauth list Subject: Re: [OAUTH-WG] IIW meet up? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:08:58 -0000 --Apple-Mail=_0840835F-E320-4AA6-9A2A-71B25341EC6F Content-Type: multipart/alternative; boundary="Apple-Mail=_961D086F-9F7C-45D3-A933-8C26713D0A43" --Apple-Mail=_961D086F-9F7C-45D3-A933-8C26713D0A43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes On 2013-10-21, at 10:22 AM, Phil Hunt wrote: > Is anyone attending IIW tomorrow or Wednesday? >=20 > It would be good to informally go through and compare the outstanding = registration drafts. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_961D086F-9F7C-45D3-A933-8C26713D0A43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii phil.hunt@oracle.com> = wrote:

Is = anyone attending IIW tomorrow or Wednesday?

It would = be good to informally go through and compare the outstanding = registration drafts.

Phil
www.independentid.com
phil.hunt@oracle.com
=

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

= --Apple-Mail=_961D086F-9F7C-45D3-A933-8C26713D0A43-- --Apple-Mail=_0840835F-E320-4AA6-9A2A-71B25341EC6F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDIxMTgwODEwWjAjBgkqhkiG9w0BCQQxFgQU37iyLrIA FD6Cwo/41J2kJuo3AtQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAMQEyE4CmQHXk6m/GSWf6/jVh553RV7hpmrbbYVNE ItaFm93QPKgOCTCNmbBac/TlFukZAmlAaV4o8wCQVJy2uzCKCrpx4Tpx11+AopcQAdPCFMh/ERiv 9v5LbYUP7/xtsPRwJ78zwtgw+AN8IbCdZkML89JNINimxKdAQm5Ya2vOAVF3P0hIsvhTj0huyaDI Wc3jrjbUL0PPsLBa7JLlZsKuLux0/Kjej6XjH3kX+tlzeS6p0JtC7/EPlJsz7E4fi5mj1DDFmHiO vmmA2sJGh/8FMPSx/Hsc1Fw7MWT07pwMTppl1kWkBwLSMoPxEHkawD7D9TEDad1Z6H8E+l2e2wAA AAAAAA== --Apple-Mail=_0840835F-E320-4AA6-9A2A-71B25341EC6F-- From jricher@mitre.org Mon Oct 21 11:58:17 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853211E865A for ; Mon, 21 Oct 2013 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YegYg3pBJ5Cv for ; Mon, 21 Oct 2013 11:57:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F35011E865C for ; Mon, 21 Oct 2013 11:56:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8ABD41F09AB; Mon, 21 Oct 2013 14:56:33 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6C3C11F099A; Mon, 21 Oct 2013 14:56:33 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 14:56:33 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. Thread-Index: AQHOzoIDOfxvQ4OI/0qr3oy130L/sJn/xI0A Date: Mon, 21 Oct 2013 18:56:32 +0000 Message-ID: <5120DE9D-B302-4754-ADE1-3BE3679A5844@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: [172.31.4.80] Content-Type: multipart/alternative; boundary="_000_5120DE9DB3024754ADE13BE3679A5844mitreorg_" MIME-Version: 1.0 Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:58:17 -0000 --_000_5120DE9DB3024754ADE13BE3679A5844mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As it says in the draft, this could be used with dynamic registration, manu= al registration, or any other method of registration. How you get the clien= t_id and the nature of the client_id are orthogonal to each other. As such, you could easily issue this structured/signed stateless client_id = in response to a signed software statement presented during either dynamic = registration (which really should be a proper extension of dynamic registra= tion). Alternatively, you can issue this client_id from a manual registrati= on step and then you don't need to do a dynamic registration at the AS at a= ll, since the AS can recognize and validate the contents of the client_id (= because it's completely stateless). -- Justin On Oct 21, 2013, at 10:21 AM, Phil Hunt > wrote: I am assuming that this draft fits with the dyn reg draft. It makes the as= sumption that every single client is somehow potentially different in terms= of registration. This draft encodes the registration values in the JWT so= that stateless registration can be achieved. Dynamic registration takes a different view from client association, in tha= t dynamic registration has no notion of fixed client software releases that= are deployed many times. As such there is no fixed registration profile. E= very client is potentially different. In contrast Client Association + Soft= ware statements, clients are identified as a particular software and are fi= xed. Have I read this correctly? >From a policy perspective, how would a service provider handle registration= of clients that are all potentially different? Why would individual client= s need to differ in registration (other than in the tokens negotiated with = a particular deployment SP)? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-14, at 5:01 PM, John Bradley > wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateles= s-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oa= uth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-c= lient-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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_5120DE9DB3024754ADE13BE3679A5844mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <36E1D4C098BDA64AA50E4DCCA5D6B532@imc.mitre.org> Content-Transfer-Encoding: quoted-printable As it says in the draft, this could be used with dynamic registration, manu= al registration, or any other method of registration. How you get the clien= t_id and the nature of the client_id are orthogonal to each other. 

As such, you could easily issue this structured/signed stateless clien= t_id in response to a signed software statement presented during either dyn= amic registration (which really should be a proper extension of dynamic reg= istration). Alternatively, you can issue this client_id from a manual registration step and then you don't ne= ed to do a dynamic registration at the AS at all, since the AS can recogniz= e and validate the contents of the client_id (because it's completely state= less).

 -- Justin

On Oct 21, 2013, at 10:21 AM, Phil Hunt <phil.hunt@oracle.com>
 wrote:

I am assuming that this draft fits with the dyn reg draft.  It ma= kes the assumption that every single client is somehow potentially differen= t in terms of registration.  This draft encodes the registration value= s in the JWT so that stateless registration can be achieved.

Dynamic registration takes a different view from client association, i= n that dynamic registration has no notion of fixed client software releases= that are deployed many times. As such there is no fixed registration profi= le. Every client is potentially different. In contrast Client Association + Software statements, clien= ts are identified as a particular software and are fixed. 

Have I read this correctly?

From a policy perspective, how would a service provider handle registr= ation of clients that are all potentially different? Why would individual c= lients need to differ in registration (other than in the tokens negotiated = with a particular deployment SP)?


On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

A new version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:  draft-bradley-stateless-oauth-client
Revision:  00
Title: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> Sta= teless Client Identifier for OAuth 2
Creation date: =  2013-10-15
Group: <= span class=3D"Apple-tab-span" style=3D"white-space: pre; "> Ind= ividual Submission
Number of pages: 4
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-bradley-statel= ess-oauth-client-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.o= rg/html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information abou= t an
  OAuth client through its client identifier allowing for fully   stateless operation.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

--_000_5120DE9DB3024754ADE13BE3679A5844mitreorg_-- From tonynad@microsoft.com Mon Oct 21 17:49:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DBB11E82E6 for ; Mon, 21 Oct 2013 17:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4MGoUp2pVeU for ; Mon, 21 Oct 2013 17:49:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id F401611E82CC for ; Mon, 21 Oct 2013 17:49:33 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB190.namprd03.prod.outlook.com (10.242.36.141) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 22 Oct 2013 00:49:32 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) with mapi id 15.00.0800.005; Tue, 22 Oct 2013 00:49:31 +0000 From: Anthony Nadalin To: Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. Thread-Index: AQHOyTm2aie9oPTOZUyREoc9yH+Tz5n/cYGAgAB826A= Date: Tue, 22 Oct 2013 00:49:30 +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: [1.209.2.33] x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(30513003)(189002)(199002)(377424004)(52084003)(69234005)(24454002)(377454003)(81686001)(69226001)(81816001)(47446002)(74502001)(74662001)(31966008)(79102001)(85306002)(74876001)(14971765001)(81542001)(80022001)(65816001)(51856001)(46102001)(74366001)(74706001)(81342001)(63696002)(56816003)(80976001)(47736001)(47976001)(49866001)(50986001)(77096001)(54316002)(56776001)(59766001)(77982001)(15975445006)(4396001)(76482001)(19609705001)(76786001)(76576001)(76796001)(83322001)(19580405001)(19580395003)(54356001)(15202345003)(16236675002)(33646001)(53806001)(19300405004)(66066001)(83072001)(16601075003)(74316001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB190; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:1.209.2.33; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_c53ff2cc218949f7a425bf06aa9a6c5cBY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:49:41 -0000 --_000_c53ff2cc218949f7a425bf06aa9a6c5cBY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I agree with your observations, seem like its screwed up From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, October 21, 2013 10:21 AM To: John Bradley Cc: oauth list Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this= is a method for making client registration stateless. I am assuming that this draft fits with the dyn reg draft. It makes the as= sumption that every single client is somehow potentially different in terms= of registration. This draft encodes the registration values in the JWT so= that stateless registration can be achieved. Dynamic registration takes a different view from client association, in tha= t dynamic registration has no notion of fixed client software releases that= are deployed many times. As such there is no fixed registration profile. E= very client is potentially different. In contrast Client Association + Soft= ware statements, clients are identified as a particular software and are fi= xed. Have I read this correctly? >From a policy perspective, how would a service provider handle registration= of clients that are all potentially different? Why would individual client= s need to differ in registration (other than in the tokens negotiated with = a particular deployment SP)? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-14, at 5:01 PM, John Bradley > wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateles= s-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oa= uth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-c= lient-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_c53ff2cc218949f7a425bf06aa9a6c5cBY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil, I agree with your o= bservations, seem like its screwed up

 

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, October 21, 2013 10:21 AM
To: John Bradley
Cc: oauth list
Subject: Re: [OAUTH-WG] FYI per a request on the last conference cal= l, this is a method for making client registration stateless.

 

I am assuming that this draft fits with the dyn reg = draft.  It makes the assumption that every single client is somehow po= tentially different in terms of registration.  This draft encodes the = registration values in the JWT so that stateless registration can be achieved.

 

Dynamic registration takes a different view from cli= ent association, in that dynamic registration has no notion of fixed client= software releases that are deployed many times. As such there is no fixed = registration profile. Every client is potentially different. In contrast Client Association + Software st= atements, clients are identified as a particular software and are fixed.&nb= sp;

 

Have I read this correctly?

 

From a policy perspective, how would a service provi= der handle registration of clients that are all potentially different? Why = would individual clients need to differ in registration (other than in the = tokens negotiated with a particular deployment SP)?

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 

On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:



A new version of I-D, draft-bradley-stateless-oauth-= client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:      = ;    draft-bradley-stateless-oauth-client
Revision:      = ;    00
Title:      &n= bsp;          Stateless= Client Identifier for OAuth 2
Creation date:  2013-10-15
Group:      &n= bsp;       Individual Submission
Number of pages: 4
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-bradley-statel= ess-oauth-client-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:        http://tools.ietf.o= rg/html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information abou= t an
  OAuth client through its client identifier allowing for fully   stateless operation.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

 

--_000_c53ff2cc218949f7a425bf06aa9a6c5cBY2PR03MB189namprd03pro_-- From t.broyer@gmail.com Tue Oct 22 07:50:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA611E83D7 for ; Tue, 22 Oct 2013 07:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlpvncIlwdet for ; Tue, 22 Oct 2013 07:50:45 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C553411E81B6 for ; Tue, 22 Oct 2013 07:50:41 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id oy12so5525192veb.28 for ; Tue, 22 Oct 2013 07:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UorzQFrGQYHMpu6Gv41GwWntr90qwmnq5Kxgrg3gEIs=; b=SW4hCMQLfPOQznwzhntKmcvEqn9CiR2APlithFNDzmW228oOFG8MgeJvyuKiy0dpsc 9zETIGNFjDrDhjK1PajU5BbCePRhmIBKYMs9ThJMzozxLqo76/KKajQvvbbYIqWRX3ej 6ixkhN1jg1v8xJIgxsdtJllj5VR/vDmMGY1hJOO8LdTtLKTWj12UhVF8ieFm9ehz/RvY HQwxZ7WsVCRe60pL3eyICQNstpPud24Bg0qHOBOP+uKbKzWymC6vmqFa8AnEa1xZ0E1g vM/ZFlyXStHnqJsMWsx9sF1HbQP8+PxILq6aTXo0eJhrP5Wrcxh6QLhqxX9ZhhiuRfZx gTdw== X-Received: by 10.52.164.102 with SMTP id yp6mr13300231vdb.14.1382453441207; Tue, 22 Oct 2013 07:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Tue, 22 Oct 2013 07:50:21 -0700 (PDT) From: Thomas Broyer Date: Tue, 22 Oct 2013 16:50:21 +0200 Message-ID: To: oauth@ietf.org, jricher@mitre.org Content-Type: multipart/alternative; boundary=001a11c2c1ea48652304e95586b8 Subject: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:52:35 -0000 --001a11c2c1ea48652304e95586b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, In a platform we're building, we have AS, clients and PRs all as distinct parties managed/provided by distinct companies. There's a single AS though, doing SSO through OpenID Connect (i.e. the AS in an OP). I thus need a way for a PR to ask the AS whether the token presented by the client is valid and grants access to the PR. I've thus briefly evaluated draft-richer-oauth-introspection-04 which seemed to fulfill my needs. Here are my comments: First, I'm a bit disturbed about privacy and potential security issues about the way this is done (disclaimer: I'm in no way a security expert). This draft is really about "introspection", and not "validation" of a token, and that might be the problem: it returns the information about a token to whoever asks for it (provided it authenticates, and possibly only if the token grants it access, but that would mean there's an association in the AS between scopes and registered PRs, themselves identified by a client_id); this is IMO disclosing too much information. In case the PR is compromised, this information could be used to then reuse the token with other PRs inferred by the token's granted scopes and gain access to private information in a way that the End User didn't explicitly approved (he authorized the Client to access several PRs, he didn't authorize exchanges between PRs directly). This could be mitigated by *not* using Bearer tokens (using some sort of 'proof token' instead, e.g. either MAC or JWT), but there's no reason we couldn't have such a feature/endpoint that could work securely with Bearer tokens (I don't want to put too much burden on client and PR implementers). Before I saw this draft, my idea was to have an endpoint at the AS where the PR would send the token received by the Client *and* the scopes corresponding to the request being done (and the "sub" of the End-User if it was part of the request; in our case, we use it as a global identifier shared by all parties involved; we might change to per-party IDs and then use that endpoint to "translate" the ID as known by the Client to the ID as known by the PR, but this is another story), and the AS would answer with just a "yes" (HTTP/1.1 204 No Content) or "no" (400 Bad Request with a JSON payload similar to the Error Response from Section 5.2 or RFC 6749, with the same error codes as defined by RFC 6750; that way the PR can just "translate" the error response to a WWW-Authenticate: Bearer response header). That way, the PR does not know where else the token is "valid", i.e. what it could do with it. Second thing, the draft talks about a "resource_id" but doesn't say how it could be used, and whether it'll be used at all by the server, what impact it could have on the response, etc. Could that resource_id replace the "list of scopes" from my implementation idea? The PR would need to know the list of scopes to return the correct WWW-Authenticate header anyway (assuming a Bearer token is used here), so I'm not sure it's really better. And the resource_id is optional, so what would happen if it's not provided? you'd have *more* information returned? I understand that this is just a framework and each server would have its own rules, but you're then either saying too much or too few. Thanks in advance for any guidance about how to achieve my goal. Should I go with introspection? (maybe I misunderstood something, or saw a threats where there isn't) or should I use something else? Does my initial idea make sense? Should I go with it? --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --001a11c2c1ea48652304e95586b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

In a platform we're buildin= g, we have AS, clients and PRs all as distinct parties managed/provided by = distinct companies. There's a single AS though, doing SSO through OpenI= D Connect (i.e. the AS in an OP).

I thus need a way for a PR to ask the AS whether the to= ken presented by the client is valid and grants access to the PR. I've = thus briefly evaluated=C2=A0draft-richer-oauth-introspection-04 which seeme= d to fulfill my needs. Here are my comments:

First, I'm a bit disturbed about privacy and potent= ial security issues about the way this is done (disclaimer: I'm in no w= ay a security expert). This draft is really about "introspection"= , and not "validation" of a token, and that might be the problem:= it returns the information about a token to whoever asks for it (provided = it authenticates, and possibly only if the token grants it access, but that= would mean there's an association in the AS between scopes and registe= red PRs, themselves identified by a client_id); this is IMO disclosing too = much information.
In case the PR is compromised, this information could be used to then = reuse the token with other PRs inferred by the token's granted scopes a= nd gain access to private information in a way that the End User didn't= explicitly approved (he authorized the Client to access several PRs, he di= dn't authorize exchanges between PRs directly). This could be mitigated= by *not* using Bearer tokens (using some sort of 'proof token' ins= tead, e.g. either MAC or JWT), but there's no reason we couldn't ha= ve such a feature/endpoint that could work securely with Bearer tokens (I d= on't want to put too much burden on client and PR implementers).
Before I saw this draft, my idea was to have an endpoint at the AS whe= re the PR would send the token received by the Client *and* the scopes corr= esponding to the request being done (and the "sub" of the End-Use= r if it was part of the request; in our case, we use it as a global identif= ier shared by all parties involved; we might change to per-party IDs and th= en use that endpoint to "translate" the ID as known by the Client= to the ID as known by the PR, but this is another story), and the AS would= answer with just a "yes" (HTTP/1.1 204 No Content) or "no&q= uot; (400 Bad Request with a JSON payload similar to the Error Response fro= m Section 5.2 or RFC 6749, with the same error codes as defined by RFC 6750= ; that way the PR can just "translate" the error response to a WW= W-Authenticate: Bearer response header). That way, the PR does not know whe= re else the token is "valid", i.e. what it could do with it.

Second thing, the draft talks about a "resource_id= " but doesn't say how it could be used, and whether it'll be u= sed at all by the server, what impact it could have on the response, etc. C= ould that resource_id replace the "list of scopes" from my implem= entation idea? The PR would need to know the list of scopes to return the c= orrect WWW-Authenticate header anyway (assuming a Bearer token is used here= ), so I'm not sure it's really better. And the resource_id is optio= nal, so what would happen if it's not provided? you'd have *more* i= nformation returned? I understand that this is just a framework and each se= rver would have its own rules, but you're then either saying too much o= r too few.

Thanks in advance for any guidance about how to achieve= my goal. Should I go with introspection? (maybe I misunderstood something,= or saw a threats where there isn't) or should I use something else? Do= es my initial idea make sense? Should I go with it?

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--001a11c2c1ea48652304e95586b8-- From tonynad@microsoft.com Tue Oct 22 19:46:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1844A11E8107 for ; Tue, 22 Oct 2013 19:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpELtyFdMniN for ; Tue, 22 Oct 2013 19:46:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id EFAED11E80F6 for ; Tue, 22 Oct 2013 19:46:19 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB057.namprd03.prod.outlook.com (10.255.241.149) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 02:46:16 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) with mapi id 15.00.0800.005; Wed, 23 Oct 2013 02:46:16 +0000 From: Anthony Nadalin To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Magnus Nystrom" Thread-Topic: Proof of Possession Thread-Index: Ac7PmcORZK2uoG7ZSo+Pwl0LdyTwXA== Date: Wed, 23 Oct 2013 02:46:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [1.209.2.35] x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(81816001)(81686001)(66066001)(77096001)(15975445006)(80022001)(56816003)(33646001)(80976001)(69226001)(76576001)(16236675002)(59766001)(83322001)(77982001)(19580395003)(76796001)(76786001)(53806001)(4396001)(74502001)(47446002)(31966008)(74662001)(81342001)(63696002)(76482001)(51856001)(74876001)(49866001)(558084003)(47976001)(47736001)(50986001)(79102001)(83072001)(46102001)(74316001)(81542001)(1511001)(74706001)(65816001)(76176001)(54356001)(15202345003)(19300405004)(54316002)(74366001)(85306002)(56776001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB057; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:1.209.2.35; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_dfdfaf23e76a469eacfe2a2544e148d9BY2PR03MB189namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: oauth list Subject: [OAUTH-WG] Proof of Possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 02:46:26 -0000 --_000_dfdfaf23e76a469eacfe2a2544e148d9BY2PR03MB189namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hannes, we would like 10min on the agenda at the Vancouver IETF meeting to = present/discuss POP --_000_dfdfaf23e76a469eacfe2a2544e148d9BY2PR03MB189namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hannes, we would like 10min on the agenda at the Van= couver IETF meeting to present/discuss POP

--_000_dfdfaf23e76a469eacfe2a2544e148d9BY2PR03MB189namprd03pro_-- From eve@xmlgrrl.com Wed Oct 23 11:37:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928711E814F for ; Wed, 23 Oct 2013 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urpVuDGIUcCV for ; Wed, 23 Oct 2013 11:37:28 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B911E81F4 for ; Wed, 23 Oct 2013 11:37:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 74F8C2901D4F; Wed, 23 Oct 2013 11:37:02 -0700 (PDT) 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 R32xZ92B64Dx; Wed, 23 Oct 2013 11:37:01 -0700 (PDT) Received: from [192.168.168.107] (unknown [192.168.168.107]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 68D1A2901D36; Wed, 23 Oct 2013 11:37:01 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C4EEC9A-5139-4457-98D8-CC41B13A82B0" From: Eve Maler In-Reply-To: Date: Wed, 23 Oct 2013 11:37:01 -0700 Message-Id: <599199F8-DEE3-45B0-85DA-53DDD17975D7@xmlgrrl.com> References: To: Thomas Broyer X-Mailer: Apple Mail (2.1510) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:37:33 -0000 --Apple-Mail=_2C4EEC9A-5139-4457-98D8-CC41B13A82B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thomas-- You may want to take a look at UMA, which leverages both = OAuth and Justin's token introspection draft. Token introspection on its = own is a "shallow" kind of loose coupling between authorization servers = and resource servers. If these are operated by different organizations, = as appears to be the case for you, then "deep" loose coupling may be = need to answer questions about how the AS and RS onboard and establish = trust with each other. UMA provides one set of answers for how to do = this. You can find more info at http://tinyurl.com/umawg. Eve On 22 Oct 2013, at 7:50 AM, Thomas Broyer wrote: > Hi all, >=20 > In a platform we're building, we have AS, clients and PRs all as = distinct parties managed/provided by distinct companies. There's a = single AS though, doing SSO through OpenID Connect (i.e. the AS in an = OP). >=20 > I thus need a way for a PR to ask the AS whether the token presented = by the client is valid and grants access to the PR. I've thus briefly = evaluated draft-richer-oauth-introspection-04 which seemed to fulfill my = needs. Here are my comments: >=20 > First, I'm a bit disturbed about privacy and potential security issues = about the way this is done (disclaimer: I'm in no way a security = expert). This draft is really about "introspection", and not = "validation" of a token, and that might be the problem: it returns the = information about a token to whoever asks for it (provided it = authenticates, and possibly only if the token grants it access, but that = would mean there's an association in the AS between scopes and = registered PRs, themselves identified by a client_id); this is IMO = disclosing too much information. > In case the PR is compromised, this information could be used to then = reuse the token with other PRs inferred by the token's granted scopes = and gain access to private information in a way that the End User didn't = explicitly approved (he authorized the Client to access several PRs, he = didn't authorize exchanges between PRs directly). This could be = mitigated by *not* using Bearer tokens (using some sort of 'proof token' = instead, e.g. either MAC or JWT), but there's no reason we couldn't have = such a feature/endpoint that could work securely with Bearer tokens (I = don't want to put too much burden on client and PR implementers). > Before I saw this draft, my idea was to have an endpoint at the AS = where the PR would send the token received by the Client *and* the = scopes corresponding to the request being done (and the "sub" of the = End-User if it was part of the request; in our case, we use it as a = global identifier shared by all parties involved; we might change to = per-party IDs and then use that endpoint to "translate" the ID as known = by the Client to the ID as known by the PR, but this is another story), = and the AS would answer with just a "yes" (HTTP/1.1 204 No Content) or = "no" (400 Bad Request with a JSON payload similar to the Error Response = from Section 5.2 or RFC 6749, with the same error codes as defined by = RFC 6750; that way the PR can just "translate" the error response to a = WWW-Authenticate: Bearer response header). That way, the PR does not = know where else the token is "valid", i.e. what it could do with it. >=20 > Second thing, the draft talks about a "resource_id" but doesn't say = how it could be used, and whether it'll be used at all by the server, = what impact it could have on the response, etc. Could that resource_id = replace the "list of scopes" from my implementation idea? The PR would = need to know the list of scopes to return the correct WWW-Authenticate = header anyway (assuming a Bearer token is used here), so I'm not sure = it's really better. And the resource_id is optional, so what would = happen if it's not provided? you'd have *more* information returned? I = understand that this is just a framework and each server would have its = own rules, but you're then either saying too much or too few. >=20 > Thanks in advance for any guidance about how to achieve my goal. = Should I go with introspection? (maybe I misunderstood something, or saw = a threats where there isn't) or should I use something else? Does my = initial idea make sense? Should I go with it? >=20 > --=20 > Thomas Broyer > /t=C9=94.ma.b=CA=81wa.je/ > _______________________________________________ > 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=_2C4EEC9A-5139-4457-98D8-CC41B13A82B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 http://tinyurl.com/umawg.
=
= Eve

On 22 Oct 2013, at 7:50 AM, Thomas Broyer = <t.broyer@gmail.com> = wrote:

Hi all,

In a platform = we're building, we have AS, clients and PRs all as distinct parties = managed/provided by distinct companies. There's a single AS though, = doing SSO through OpenID Connect (i.e. the AS in an OP).

I thus need a way for a PR to ask the AS whether the = token presented by the client is valid and grants access to the PR. I've = thus briefly evaluated draft-richer-oauth-introspection-04 which = seemed to fulfill my needs. Here are my comments:

First, I'm a bit disturbed about privacy and = potential security issues about the way this is done (disclaimer: I'm in = no way a security expert). This draft is really about "introspection", = and not "validation" of a token, and that might be the problem: it = returns the information about a token to whoever asks for it (provided = it authenticates, and possibly only if the token grants it access, but = that would mean there's an association in the AS between scopes and = registered PRs, themselves identified by a client_id); this is IMO = disclosing too much information.
In case the PR is compromised, this information could be used to = then reuse the token with other PRs inferred by the token's granted = scopes and gain access to private information in a way that the End User = didn't explicitly approved (he authorized the Client to access several = PRs, he didn't authorize exchanges between PRs directly). This could be = mitigated by *not* using Bearer tokens (using some sort of 'proof token' = instead, e.g. either MAC or JWT), but there's no reason we couldn't have = such a feature/endpoint that could work securely with Bearer tokens (I = don't want to put too much burden on client and PR implementers).
Before I saw this draft, my idea was to have an endpoint at the AS = where the PR would send the token received by the Client *and* the = scopes corresponding to the request being done (and the "sub" of the = End-User if it was part of the request; in our case, we use it as a = global identifier shared by all parties involved; we might change to = per-party IDs and then use that endpoint to "translate" the ID as known = by the Client to the ID as known by the PR, but this is another story), = and the AS would answer with just a "yes" (HTTP/1.1 204 No Content) or = "no" (400 Bad Request with a JSON payload similar to the Error Response = from Section 5.2 or RFC 6749, with the same error codes as defined by = RFC 6750; that way the PR can just "translate" the error response to a = WWW-Authenticate: Bearer response header). That way, the PR does not = know where else the token is "valid", i.e. what it could do with = it.

Second thing, the draft talks about a "resource_id" = but doesn't say how it could be used, and whether it'll be used at all = by the server, what impact it could have on the response, etc. Could = that resource_id replace the "list of scopes" from my implementation = idea? The PR would need to know the list of scopes to return the correct = WWW-Authenticate header anyway (assuming a Bearer token is used here), = so I'm not sure it's really better. And the resource_id is optional, so = what would happen if it's not provided? you'd have *more* information = returned? I understand that this is just a framework and each server = would have its own rules, but you're then either saying too much or too = few.

Thanks in advance for any guidance about how to = achieve my goal. Should I go with introspection? (maybe I misunderstood = something, or saw a threats where there isn't) or should I use something = else? Does my initial idea make sense? Should I go with it?

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
_______________________________________________
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=_2C4EEC9A-5139-4457-98D8-CC41B13A82B0-- From jricher@mitre.org Wed Oct 23 12:22:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5171911E8358 for ; Wed, 23 Oct 2013 12:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep+9jA37vQP6 for ; Wed, 23 Oct 2013 12:22:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43F11E834A for ; Wed, 23 Oct 2013 12:22:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 770CF1F059C; Wed, 23 Oct 2013 15:22:39 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 27DDE1F059A; Wed, 23 Oct 2013 15:22:39 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 15:22:38 -0400 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: Comments on draft-richer-oauth-introspection-04 Thread-Index: AQHO0CU84Zn8ICoUOUaw6JzqL1n5yQ== Date: Wed, 23 Oct 2013 19:22:37 +0000 Message-ID: <63692DF5-4616-4F53-B12E-518397CFEFB3@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: [172.31.4.192] Content-Type: multipart/alternative; boundary="_000_63692DF546164F53B12E518397CFEFB3mitreorg_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:22:48 -0000 --_000_63692DF546164F53B12E518397CFEFB3mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzLA0KDQpZb3UncmUgcmlnaHQgaW4gdGhhdCB0aGUgaW50cm9zcGVjdGlvbiBwcm9j ZXNzIGlzIGFib3V0IGdldHRpbmcgbWV0YSBkYXRhIGFib3V0IGEgcGFydGljdWxhciB0b2tlbiBi eSBtYWtpbmcgYW4gYXV0aGVudGljYXRlZCBjYWxsLiBJdCBkb2VzIHJldmVhbCBhIGxvdCBvZiBp bmZvcm1hdGlvbiBhYm91dCB0aGUgdG9rZW4gLS0gYmVjYXVzZSB0aGF0J3MgZXhhY3RseSB0aGUg cG9pbnQgb2YgdGhlIHByb3RvY29sLiA6KQ0KDQpJZiB0aGUgUFIgaXMgY29tcHJvbWlzZWQsIHRo ZW4gdGhlIGF0dGFja2VyIHdvdWxkIGJlIGFibGUgdG8gZG8gYW55dGhpbmcgdGhlIFBSIGNhbiBk bywgaW5jbHVkaW5nIHJldXNpbmcgYW55IHRva2VucyBoYW5kZWQgdG8gdGhlIFBSIChhc3N1bWlu ZyB0aGV5J3JlIGJlYXJlciB0b2tlbnMpLiBUaGlzIGlzIHRydWUgd2l0aG91dCBkb2luZyBpbnRy b3NwZWN0aW9uIGF0IGFsbCwgc2luY2UgeW91IGNhbiBqdXN0IHN0ZWFsIGFuZCBzdGFydCBicm9h ZGNhc3RpbmcgdGhlIHRva2VuLiBBbHNvLCBpZiB0aGUgUFIgaXMgY29tcHJvbWlzZWQsIGFsbCB0 aGUgZGF0YSBwcm90ZWN0ZWQgYXQgdGhhdCBQUiBpcyBhbHNvIGNvbXByb21pc2VkLCBzbyB5b3Un dmUgZ290IG90aGVyIHByb2JsZW1zIHRvby4NCg0KVGhlICJyZXNvdXJjZV9pZCIgcGFyYW1ldGVy IGlzIG1lYW50IHRvIGJlIGEgc2VydmljZS1zcGVjaWZpYyBoaW50IHRoYXQgdGhlIFBSIGNhbiBo YW5kIHRvIHRoZSBBUyB0byBnaXZlIGNvbnRleHQgdG8gdGhlIHRyYW5zYWN0aW9uLiBZb3UgY291 bGQgZWFzaWx5IHVzZSB0aGlzIGZpZWxkIHRvIHBhc3MgYWxvbmcgdGhlIGxpc3Qgb2Ygc2NvcGVz IHRoYXQgeW91IG1lbnRpb24gYmVsb3cuIFlvdSBjYW4gaGF2ZSB5b3VyIEFTIHJldHVybiBubyBp bmZvcm1hdGlvbiBvdGhlciB0aGFuIHRoZSAidmFsaWQiIGZpZWxkIGluIHRoZSByZXNwb25zZSBh bmQgbGVhdmUgb3V0IHRoZSBzY29wZXMsIHN1YmplY3QsIGNsaWVudCBpZCwgYW5kIGV2ZXJ5dGhp bmcgZWxzZS4gQWxsIHRob3NlIGZpZWxkcyBhcmUgb3B0aW9uYWwuIEhvd2V2ZXIsIGluIHByYWN0 aWNlIHdlJ3ZlIGZvdW5kIGl0IHZlcnkgaGVscGZ1bCB0byByZXZlYWwgdG8gdGhlIFBSIHdoaWNo IHNjb3BlcyBhbmQgYXVkaWVuY2VzIHRoYXQgYSB0b2tlbiB3YXMgaXNzdWVkIGZvciBzbyB0aGF0 IHRoZSBQUiBjYW4gdXNlIHRoYXQgaW5mb3JtYXRpb24gdG8gbWFrZSBhdXRob3JpemF0aW9uIGRl Y2lzaW9ucy4gQnV0IGlmIGFsbCB5b3UncmUgYWZ0ZXIgaXMgYW5zd2VyaW5nIHRoZSBxdWVzdGlv biAiaXMgdGhpcyB0b2tlbiB2YWxpZCIgYW5kIHlvdSBkb24ndCB3YW50IGFueSBvdGhlciBpbmZv cm1hdGlvbiwgeW91ciBBUyBpcyBmdWxseSBhbGxvd2VkIHRvIGRvIGFuc3dlciBqdXN0IHRoYXQg cXVlc3Rpb24uDQoNCg0KQXMgRXZlIHBvaW50ZWQgb3V0IGluIHRoZSBvdGhlciBlbWFpbCwgdGhl IGludHJvc3BlY3Rpb24gZHJhZnQgYWxsb3dzIGZvciBhIGxpZ2h0ICJsb29zZSIgYmluZGluZyBi ZXR3ZWVuIHRoZSBBUyBhbmQgUFIsIGJ1dCB0aGVyZSdzIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUg cmVsYXRpb25zaGlwIHdhcyBzZXQgdXAgc29tZXdoZXJlLiBVTUEgYWRkcyB0aGUgcG9zc2liaWxp dGllcyBvZiBhIGRlZXBlciBhbmQgbW9yZSBkeW5hbWljIGJpbmRpbmcgYmV0d2VlbiBQUiBhbmQg QVMgYmVmb3JlIGludHJvc3BlY3Rpb24gdGFrZXMgcGxhY2UuIChJbiBmYWN0LCB0aGUgaW50cm9z cGVjdGlvbiBkcmFmdCB3YXMgcHJldHR5IG11Y2ggbGlmdGVkIG91dCBvZiBVTUEgb3JpZ2luYWxs eS4pIFVNQSBhbHNvIGhhcyBhIGNvbmNlcHQgb2YgcGVybWlzc2lvbiBzZXRzIHRoYXQgYXJlIG1v cmUgZmxleGlibGUgYW5kIGRlc2NyaXB0aXZlIHRoYW4gc2NvcGVzIGFsb25lIGFyZSwgYnV0IHRo b3NlIGFyZSBhZGRlZCB0byB0aGUgdG9wIG9mIHRoZSBiYXNlIGludHJvc3BlY3Rpb24gcmVzcG9u c2UuDQoNCiAtLSBKdXN0aW4NCg0KDQpPbiBPY3QgMjIsIDIwMTMsIGF0IDc6NTAgQU0sIFRob21h cyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj4g d3JvdGU6DQoNCkhpIGFsbCwNCg0KSW4gYSBwbGF0Zm9ybSB3ZSdyZSBidWlsZGluZywgd2UgaGF2 ZSBBUywgY2xpZW50cyBhbmQgUFJzIGFsbCBhcyBkaXN0aW5jdCBwYXJ0aWVzIG1hbmFnZWQvcHJv dmlkZWQgYnkgZGlzdGluY3QgY29tcGFuaWVzLiBUaGVyZSdzIGEgc2luZ2xlIEFTIHRob3VnaCwg ZG9pbmcgU1NPIHRocm91Z2ggT3BlbklEIENvbm5lY3QgKGkuZS4gdGhlIEFTIGluIGFuIE9QKS4N Cg0KSSB0aHVzIG5lZWQgYSB3YXkgZm9yIGEgUFIgdG8gYXNrIHRoZSBBUyB3aGV0aGVyIHRoZSB0 b2tlbiBwcmVzZW50ZWQgYnkgdGhlIGNsaWVudCBpcyB2YWxpZCBhbmQgZ3JhbnRzIGFjY2VzcyB0 byB0aGUgUFIuIEkndmUgdGh1cyBicmllZmx5IGV2YWx1YXRlZCBkcmFmdC1yaWNoZXItb2F1dGgt aW50cm9zcGVjdGlvbi0wNCB3aGljaCBzZWVtZWQgdG8gZnVsZmlsbCBteSBuZWVkcy4gSGVyZSBh cmUgbXkgY29tbWVudHM6DQoNCkZpcnN0LCBJJ20gYSBiaXQgZGlzdHVyYmVkIGFib3V0IHByaXZh Y3kgYW5kIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZXMgYWJvdXQgdGhlIHdheSB0aGlzIGlzIGRv bmUgKGRpc2NsYWltZXI6IEknbSBpbiBubyB3YXkgYSBzZWN1cml0eSBleHBlcnQpLiBUaGlzIGRy YWZ0IGlzIHJlYWxseSBhYm91dCAiaW50cm9zcGVjdGlvbiIsIGFuZCBub3QgInZhbGlkYXRpb24i IG9mIGEgdG9rZW4sIGFuZCB0aGF0IG1pZ2h0IGJlIHRoZSBwcm9ibGVtOiBpdCByZXR1cm5zIHRo ZSBpbmZvcm1hdGlvbiBhYm91dCBhIHRva2VuIHRvIHdob2V2ZXIgYXNrcyBmb3IgaXQgKHByb3Zp ZGVkIGl0IGF1dGhlbnRpY2F0ZXMsIGFuZCBwb3NzaWJseSBvbmx5IGlmIHRoZSB0b2tlbiBncmFu dHMgaXQgYWNjZXNzLCBidXQgdGhhdCB3b3VsZCBtZWFuIHRoZXJlJ3MgYW4gYXNzb2NpYXRpb24g aW4gdGhlIEFTIGJldHdlZW4gc2NvcGVzIGFuZCByZWdpc3RlcmVkIFBScywgdGhlbXNlbHZlcyBp ZGVudGlmaWVkIGJ5IGEgY2xpZW50X2lkKTsgdGhpcyBpcyBJTU8gZGlzY2xvc2luZyB0b28gbXVj aCBpbmZvcm1hdGlvbi4NCkluIGNhc2UgdGhlIFBSIGlzIGNvbXByb21pc2VkLCB0aGlzIGluZm9y bWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gdGhlbiByZXVzZSB0aGUgdG9rZW4gd2l0aCBvdGhlciBQ UnMgaW5mZXJyZWQgYnkgdGhlIHRva2VuJ3MgZ3JhbnRlZCBzY29wZXMgYW5kIGdhaW4gYWNjZXNz IHRvIHByaXZhdGUgaW5mb3JtYXRpb24gaW4gYSB3YXkgdGhhdCB0aGUgRW5kIFVzZXIgZGlkbid0 IGV4cGxpY2l0bHkgYXBwcm92ZWQgKGhlIGF1dGhvcml6ZWQgdGhlIENsaWVudCB0byBhY2Nlc3Mg c2V2ZXJhbCBQUnMsIGhlIGRpZG4ndCBhdXRob3JpemUgZXhjaGFuZ2VzIGJldHdlZW4gUFJzIGRp cmVjdGx5KS4gVGhpcyBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkgKm5vdCogdXNpbmcgQmVhcmVyIHRv a2VucyAodXNpbmcgc29tZSBzb3J0IG9mICdwcm9vZiB0b2tlbicgaW5zdGVhZCwgZS5nLiBlaXRo ZXIgTUFDIG9yIEpXVCksIGJ1dCB0aGVyZSdzIG5vIHJlYXNvbiB3ZSBjb3VsZG4ndCBoYXZlIHN1 Y2ggYSBmZWF0dXJlL2VuZHBvaW50IHRoYXQgY291bGQgd29yayBzZWN1cmVseSB3aXRoIEJlYXJl ciB0b2tlbnMgKEkgZG9uJ3Qgd2FudCB0byBwdXQgdG9vIG11Y2ggYnVyZGVuIG9uIGNsaWVudCBh bmQgUFIgaW1wbGVtZW50ZXJzKS4NCkJlZm9yZSBJIHNhdyB0aGlzIGRyYWZ0LCBteSBpZGVhIHdh cyB0byBoYXZlIGFuIGVuZHBvaW50IGF0IHRoZSBBUyB3aGVyZSB0aGUgUFIgd291bGQgc2VuZCB0 aGUgdG9rZW4gcmVjZWl2ZWQgYnkgdGhlIENsaWVudCAqYW5kKiB0aGUgc2NvcGVzIGNvcnJlc3Bv bmRpbmcgdG8gdGhlIHJlcXVlc3QgYmVpbmcgZG9uZSAoYW5kIHRoZSAic3ViIiBvZiB0aGUgRW5k LVVzZXIgaWYgaXQgd2FzIHBhcnQgb2YgdGhlIHJlcXVlc3Q7IGluIG91ciBjYXNlLCB3ZSB1c2Ug aXQgYXMgYSBnbG9iYWwgaWRlbnRpZmllciBzaGFyZWQgYnkgYWxsIHBhcnRpZXMgaW52b2x2ZWQ7 IHdlIG1pZ2h0IGNoYW5nZSB0byBwZXItcGFydHkgSURzIGFuZCB0aGVuIHVzZSB0aGF0IGVuZHBv aW50IHRvICJ0cmFuc2xhdGUiIHRoZSBJRCBhcyBrbm93biBieSB0aGUgQ2xpZW50IHRvIHRoZSBJ RCBhcyBrbm93biBieSB0aGUgUFIsIGJ1dCB0aGlzIGlzIGFub3RoZXIgc3RvcnkpLCBhbmQgdGhl IEFTIHdvdWxkIGFuc3dlciB3aXRoIGp1c3QgYSAieWVzIiAoSFRUUC8xLjEgMjA0IE5vIENvbnRl bnQpIG9yICJubyIgKDQwMCBCYWQgUmVxdWVzdCB3aXRoIGEgSlNPTiBwYXlsb2FkIHNpbWlsYXIg dG8gdGhlIEVycm9yIFJlc3BvbnNlIGZyb20gU2VjdGlvbiA1LjIgb3IgUkZDIDY3NDksIHdpdGgg dGhlIHNhbWUgZXJyb3IgY29kZXMgYXMgZGVmaW5lZCBieSBSRkMgNjc1MDsgdGhhdCB3YXkgdGhl IFBSIGNhbiBqdXN0ICJ0cmFuc2xhdGUiIHRoZSBlcnJvciByZXNwb25zZSB0byBhIFdXVy1BdXRo ZW50aWNhdGU6IEJlYXJlciByZXNwb25zZSBoZWFkZXIpLiBUaGF0IHdheSwgdGhlIFBSIGRvZXMg bm90IGtub3cgd2hlcmUgZWxzZSB0aGUgdG9rZW4gaXMgInZhbGlkIiwgaS5lLiB3aGF0IGl0IGNv dWxkIGRvIHdpdGggaXQuDQoNClNlY29uZCB0aGluZywgdGhlIGRyYWZ0IHRhbGtzIGFib3V0IGEg InJlc291cmNlX2lkIiBidXQgZG9lc24ndCBzYXkgaG93IGl0IGNvdWxkIGJlIHVzZWQsIGFuZCB3 aGV0aGVyIGl0J2xsIGJlIHVzZWQgYXQgYWxsIGJ5IHRoZSBzZXJ2ZXIsIHdoYXQgaW1wYWN0IGl0 IGNvdWxkIGhhdmUgb24gdGhlIHJlc3BvbnNlLCBldGMuIENvdWxkIHRoYXQgcmVzb3VyY2VfaWQg cmVwbGFjZSB0aGUgImxpc3Qgb2Ygc2NvcGVzIiBmcm9tIG15IGltcGxlbWVudGF0aW9uIGlkZWE/ IFRoZSBQUiB3b3VsZCBuZWVkIHRvIGtub3cgdGhlIGxpc3Qgb2Ygc2NvcGVzIHRvIHJldHVybiB0 aGUgY29ycmVjdCBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBhbnl3YXkgKGFzc3VtaW5nIGEgQmVh cmVyIHRva2VuIGlzIHVzZWQgaGVyZSksIHNvIEknbSBub3Qgc3VyZSBpdCdzIHJlYWxseSBiZXR0 ZXIuIEFuZCB0aGUgcmVzb3VyY2VfaWQgaXMgb3B0aW9uYWwsIHNvIHdoYXQgd291bGQgaGFwcGVu IGlmIGl0J3Mgbm90IHByb3ZpZGVkPyB5b3UnZCBoYXZlICptb3JlKiBpbmZvcm1hdGlvbiByZXR1 cm5lZD8gSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBqdXN0IGEgZnJhbWV3b3JrIGFuZCBlYWNo IHNlcnZlciB3b3VsZCBoYXZlIGl0cyBvd24gcnVsZXMsIGJ1dCB5b3UncmUgdGhlbiBlaXRoZXIg c2F5aW5nIHRvbyBtdWNoIG9yIHRvbyBmZXcuDQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkg Z3VpZGFuY2UgYWJvdXQgaG93IHRvIGFjaGlldmUgbXkgZ29hbC4gU2hvdWxkIEkgZ28gd2l0aCBp bnRyb3NwZWN0aW9uPyAobWF5YmUgSSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZywgb3Igc2F3IGEg dGhyZWF0cyB3aGVyZSB0aGVyZSBpc24ndCkgb3Igc2hvdWxkIEkgdXNlIHNvbWV0aGluZyBlbHNl PyBEb2VzIG15IGluaXRpYWwgaWRlYSBtYWtlIHNlbnNlPyBTaG91bGQgSSBnbyB3aXRoIGl0Pw0K DQotLQ0KVGhvbWFzIEJyb3llcg0KL3TJlC5tYS5iyoF3YS5qZS88aHR0cDovL3huLS1ubmEubWEu eG4tLWJ3YS14eGIuamUvPg0KDQo= --_000_63692DF546164F53B12E518397CFEFB3mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkhpIFRob21hcywNCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PllvdSdyZSByaWdodCBpbiB0aGF0IHRoZSBpbnRyb3NwZWN0aW9uIHByb2Nlc3MgaXMg YWJvdXQgZ2V0dGluZyBtZXRhIGRhdGEgYWJvdXQgYSBwYXJ0aWN1bGFyIHRva2VuIGJ5IG1ha2lu ZyBhbiBhdXRoZW50aWNhdGVkIGNhbGwuIEl0IGRvZXMgcmV2ZWFsIGEgbG90IG9mIGluZm9ybWF0 aW9uIGFib3V0IHRoZSB0b2tlbiAtLSBiZWNhdXNlIHRoYXQncyBleGFjdGx5IHRoZSBwb2ludCBv ZiB0aGUgcHJvdG9jb2wuIDopJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J ZiB0aGUgUFIgaXMgY29tcHJvbWlzZWQsIHRoZW4gdGhlIGF0dGFja2VyIHdvdWxkIGJlIGFibGUg dG8gZG8gYW55dGhpbmcgdGhlIFBSIGNhbiBkbywgaW5jbHVkaW5nIHJldXNpbmcgYW55IHRva2Vu cyBoYW5kZWQgdG8gdGhlIFBSIChhc3N1bWluZyB0aGV5J3JlIGJlYXJlciB0b2tlbnMpLiBUaGlz IGlzIHRydWUgd2l0aG91dCBkb2luZyBpbnRyb3NwZWN0aW9uIGF0IGFsbCwgc2luY2UgeW91IGNh biBqdXN0IHN0ZWFsIGFuZCBzdGFydA0KIGJyb2FkY2FzdGluZyB0aGUgdG9rZW4uIEFsc28sIGlm IHRoZSBQUiBpcyBjb21wcm9taXNlZCwgYWxsIHRoZSBkYXRhIHByb3RlY3RlZCBhdCB0aGF0IFBS IGlzIGFsc28gY29tcHJvbWlzZWQsIHNvIHlvdSd2ZSBnb3Qgb3RoZXIgcHJvYmxlbXMgdG9vLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlICZxdW90O3Jlc291cmNlX2lkJnF1b3Q7 IHBhcmFtZXRlciBpcyBtZWFudCB0byBiZSBhIHNlcnZpY2Utc3BlY2lmaWMgaGludCB0aGF0IHRo ZSBQUiBjYW4gaGFuZCB0byB0aGUgQVMgdG8gZ2l2ZSBjb250ZXh0IHRvIHRoZSB0cmFuc2FjdGlv bi4gWW91IGNvdWxkIGVhc2lseSB1c2UgdGhpcyBmaWVsZCB0byBwYXNzIGFsb25nIHRoZSBsaXN0 IG9mIHNjb3BlcyB0aGF0IHlvdSBtZW50aW9uIGJlbG93LiBZb3UgY2FuIGhhdmUgeW91ciBBUyBy ZXR1cm4gbm8NCiBpbmZvcm1hdGlvbiBvdGhlciB0aGFuIHRoZSAmcXVvdDt2YWxpZCZxdW90OyBm aWVsZCBpbiB0aGUgcmVzcG9uc2UgYW5kIGxlYXZlIG91dCB0aGUgc2NvcGVzLCBzdWJqZWN0LCBj bGllbnQgaWQsIGFuZCBldmVyeXRoaW5nIGVsc2UuIEFsbCB0aG9zZSBmaWVsZHMgYXJlIG9wdGlv bmFsLiBIb3dldmVyLCBpbiBwcmFjdGljZSB3ZSd2ZSBmb3VuZCBpdCB2ZXJ5IGhlbHBmdWwgdG8g cmV2ZWFsIHRvIHRoZSBQUiB3aGljaCBzY29wZXMgYW5kIGF1ZGllbmNlcyB0aGF0DQogYSB0b2tl biB3YXMgaXNzdWVkIGZvciBzbyB0aGF0IHRoZSBQUiBjYW4gdXNlIHRoYXQgaW5mb3JtYXRpb24g dG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucy4gQnV0IGlmIGFsbCB5b3UncmUgYWZ0ZXIg aXMgYW5zd2VyaW5nIHRoZSBxdWVzdGlvbiAmcXVvdDtpcyB0aGlzIHRva2VuIHZhbGlkJnF1b3Q7 IGFuZCB5b3UgZG9uJ3Qgd2FudCBhbnkgb3RoZXIgaW5mb3JtYXRpb24sIHlvdXIgQVMgaXMgZnVs bHkgYWxsb3dlZCB0byBkbyBhbnN3ZXIganVzdCB0aGF0DQogcXVlc3Rpb24uPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXMgRXZlIHBvaW50ZWQgb3V0 IGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGludHJvc3BlY3Rpb24gZHJhZnQgYWxsb3dzIGZvciBh IGxpZ2h0ICZxdW90O2xvb3NlJnF1b3Q7IGJpbmRpbmcgYmV0d2VlbiB0aGUgQVMgYW5kIFBSLCBi dXQgdGhlcmUncyBhbiBhc3N1bXB0aW9uIHRoYXQgdGhlIHJlbGF0aW9uc2hpcCB3YXMgc2V0IHVw IHNvbWV3aGVyZS4gVU1BIGFkZHMgdGhlIHBvc3NpYmlsaXRpZXMgb2YgYSBkZWVwZXIgYW5kIG1v cmUgZHluYW1pYyBiaW5kaW5nDQogYmV0d2VlbiBQUiBhbmQgQVMgYmVmb3JlIGludHJvc3BlY3Rp b24gdGFrZXMgcGxhY2UuIChJbiBmYWN0LCB0aGUgaW50cm9zcGVjdGlvbiBkcmFmdCB3YXMgcHJl dHR5IG11Y2ggbGlmdGVkIG91dCBvZiBVTUEgb3JpZ2luYWxseS4pIFVNQSBhbHNvIGhhcyBhIGNv bmNlcHQgb2YgcGVybWlzc2lvbiBzZXRzIHRoYXQgYXJlIG1vcmUgZmxleGlibGUgYW5kIGRlc2Ny aXB0aXZlIHRoYW4gc2NvcGVzIGFsb25lIGFyZSwgYnV0IHRob3NlIGFyZSBhZGRlZA0KIHRvIHRo ZSB0b3Agb2YgdGhlIGJhc2UgaW50cm9zcGVjdGlvbiByZXNwb25zZS48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOy0tIEp1c3RpbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24gT2N0IDIyLCAyMDEzLCBhdCA3OjUwIEFNLCBUaG9t YXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIj50LmJyb3ll ckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIi PkhpIGFsbCwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIGEgcGxhdGZvcm0gd2UncmUgYnVp bGRpbmcsIHdlIGhhdmUgQVMsIGNsaWVudHMgYW5kIFBScyBhbGwgYXMgZGlzdGluY3QgcGFydGll cyBtYW5hZ2VkL3Byb3ZpZGVkIGJ5IGRpc3RpbmN0IGNvbXBhbmllcy4gVGhlcmUncyBhIHNpbmds ZSBBUyB0aG91Z2gsIGRvaW5nIFNTTyB0aHJvdWdoIE9wZW5JRCBDb25uZWN0IChpLmUuIHRoZSBB UyBpbiBhbiBPUCkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRodXMgbmVlZCBh IHdheSBmb3IgYSBQUiB0byBhc2sgdGhlIEFTIHdoZXRoZXIgdGhlIHRva2VuIHByZXNlbnRlZCBi eSB0aGUgY2xpZW50IGlzIHZhbGlkIGFuZCBncmFudHMgYWNjZXNzIHRvIHRoZSBQUi4gSSd2ZSB0 aHVzIGJyaWVmbHkgZXZhbHVhdGVkJm5ic3A7ZHJhZnQtcmljaGVyLW9hdXRoLWludHJvc3BlY3Rp b24tMDQgd2hpY2ggc2VlbWVkIHRvIGZ1bGZpbGwgbXkgbmVlZHMuIEhlcmUgYXJlIG15IGNvbW1l bnRzOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rmlyc3QsIEknbSBhIGJpdCBkaXN0 dXJiZWQgYWJvdXQgcHJpdmFjeSBhbmQgcG90ZW50aWFsIHNlY3VyaXR5IGlzc3VlcyBhYm91dCB0 aGUgd2F5IHRoaXMgaXMgZG9uZSAoZGlzY2xhaW1lcjogSSdtIGluIG5vIHdheSBhIHNlY3VyaXR5 IGV4cGVydCkuIFRoaXMgZHJhZnQgaXMgcmVhbGx5IGFib3V0ICZxdW90O2ludHJvc3BlY3Rpb24m cXVvdDssIGFuZCBub3QgJnF1b3Q7dmFsaWRhdGlvbiZxdW90OyBvZiBhIHRva2VuLCBhbmQgdGhh dCBtaWdodCBiZSB0aGUgcHJvYmxlbToNCiBpdCByZXR1cm5zIHRoZSBpbmZvcm1hdGlvbiBhYm91 dCBhIHRva2VuIHRvIHdob2V2ZXIgYXNrcyBmb3IgaXQgKHByb3ZpZGVkIGl0IGF1dGhlbnRpY2F0 ZXMsIGFuZCBwb3NzaWJseSBvbmx5IGlmIHRoZSB0b2tlbiBncmFudHMgaXQgYWNjZXNzLCBidXQg dGhhdCB3b3VsZCBtZWFuIHRoZXJlJ3MgYW4gYXNzb2NpYXRpb24gaW4gdGhlIEFTIGJldHdlZW4g c2NvcGVzIGFuZCByZWdpc3RlcmVkIFBScywgdGhlbXNlbHZlcyBpZGVudGlmaWVkIGJ5IGENCiBj bGllbnRfaWQpOyB0aGlzIGlzIElNTyBkaXNjbG9zaW5nIHRvbyBtdWNoIGluZm9ybWF0aW9uLjwv ZGl2Pg0KPGRpdj5JbiBjYXNlIHRoZSBQUiBpcyBjb21wcm9taXNlZCwgdGhpcyBpbmZvcm1hdGlv biBjb3VsZCBiZSB1c2VkIHRvIHRoZW4gcmV1c2UgdGhlIHRva2VuIHdpdGggb3RoZXIgUFJzIGlu ZmVycmVkIGJ5IHRoZSB0b2tlbidzIGdyYW50ZWQgc2NvcGVzIGFuZCBnYWluIGFjY2VzcyB0byBw cml2YXRlIGluZm9ybWF0aW9uIGluIGEgd2F5IHRoYXQgdGhlIEVuZCBVc2VyIGRpZG4ndCBleHBs aWNpdGx5IGFwcHJvdmVkIChoZSBhdXRob3JpemVkIHRoZQ0KIENsaWVudCB0byBhY2Nlc3Mgc2V2 ZXJhbCBQUnMsIGhlIGRpZG4ndCBhdXRob3JpemUgZXhjaGFuZ2VzIGJldHdlZW4gUFJzIGRpcmVj dGx5KS4gVGhpcyBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkgKm5vdCogdXNpbmcgQmVhcmVyIHRva2Vu cyAodXNpbmcgc29tZSBzb3J0IG9mICdwcm9vZiB0b2tlbicgaW5zdGVhZCwgZS5nLiBlaXRoZXIg TUFDIG9yIEpXVCksIGJ1dCB0aGVyZSdzIG5vIHJlYXNvbiB3ZSBjb3VsZG4ndCBoYXZlIHN1Y2gg YSBmZWF0dXJlL2VuZHBvaW50DQogdGhhdCBjb3VsZCB3b3JrIHNlY3VyZWx5IHdpdGggQmVhcmVy IHRva2VucyAoSSBkb24ndCB3YW50IHRvIHB1dCB0b28gbXVjaCBidXJkZW4gb24gY2xpZW50IGFu ZCBQUiBpbXBsZW1lbnRlcnMpLjwvZGl2Pg0KPGRpdj5CZWZvcmUgSSBzYXcgdGhpcyBkcmFmdCwg bXkgaWRlYSB3YXMgdG8gaGF2ZSBhbiBlbmRwb2ludCBhdCB0aGUgQVMgd2hlcmUgdGhlIFBSIHdv dWxkIHNlbmQgdGhlIHRva2VuIHJlY2VpdmVkIGJ5IHRoZSBDbGllbnQgKmFuZCogdGhlIHNjb3Bl cyBjb3JyZXNwb25kaW5nIHRvIHRoZSByZXF1ZXN0IGJlaW5nIGRvbmUgKGFuZCB0aGUgJnF1b3Q7 c3ViJnF1b3Q7IG9mIHRoZSBFbmQtVXNlciBpZiBpdCB3YXMgcGFydCBvZiB0aGUgcmVxdWVzdDsg aW4gb3VyIGNhc2UsDQogd2UgdXNlIGl0IGFzIGEgZ2xvYmFsIGlkZW50aWZpZXIgc2hhcmVkIGJ5 IGFsbCBwYXJ0aWVzIGludm9sdmVkOyB3ZSBtaWdodCBjaGFuZ2UgdG8gcGVyLXBhcnR5IElEcyBh bmQgdGhlbiB1c2UgdGhhdCBlbmRwb2ludCB0byAmcXVvdDt0cmFuc2xhdGUmcXVvdDsgdGhlIElE IGFzIGtub3duIGJ5IHRoZSBDbGllbnQgdG8gdGhlIElEIGFzIGtub3duIGJ5IHRoZSBQUiwgYnV0 IHRoaXMgaXMgYW5vdGhlciBzdG9yeSksIGFuZCB0aGUgQVMgd291bGQgYW5zd2VyIHdpdGgNCiBq dXN0IGEgJnF1b3Q7eWVzJnF1b3Q7IChIVFRQLzEuMSAyMDQgTm8gQ29udGVudCkgb3IgJnF1b3Q7 bm8mcXVvdDsgKDQwMCBCYWQgUmVxdWVzdCB3aXRoIGEgSlNPTiBwYXlsb2FkIHNpbWlsYXIgdG8g dGhlIEVycm9yIFJlc3BvbnNlIGZyb20gU2VjdGlvbiA1LjIgb3IgUkZDIDY3NDksIHdpdGggdGhl IHNhbWUgZXJyb3IgY29kZXMgYXMgZGVmaW5lZCBieSBSRkMgNjc1MDsgdGhhdCB3YXkgdGhlIFBS IGNhbiBqdXN0ICZxdW90O3RyYW5zbGF0ZSZxdW90OyB0aGUgZXJyb3IgcmVzcG9uc2UgdG8gYSBX V1ctQXV0aGVudGljYXRlOg0KIEJlYXJlciByZXNwb25zZSBoZWFkZXIpLiBUaGF0IHdheSwgdGhl IFBSIGRvZXMgbm90IGtub3cgd2hlcmUgZWxzZSB0aGUgdG9rZW4gaXMgJnF1b3Q7dmFsaWQmcXVv dDssIGkuZS4gd2hhdCBpdCBjb3VsZCBkbyB3aXRoIGl0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+U2Vjb25kIHRoaW5nLCB0aGUgZHJhZnQgdGFsa3MgYWJvdXQgYSAmcXVvdDtyZXNv dXJjZV9pZCZxdW90OyBidXQgZG9lc24ndCBzYXkgaG93IGl0IGNvdWxkIGJlIHVzZWQsIGFuZCB3 aGV0aGVyIGl0J2xsIGJlIHVzZWQgYXQgYWxsIGJ5IHRoZSBzZXJ2ZXIsIHdoYXQgaW1wYWN0IGl0 IGNvdWxkIGhhdmUgb24gdGhlIHJlc3BvbnNlLCBldGMuIENvdWxkIHRoYXQgcmVzb3VyY2VfaWQg cmVwbGFjZSB0aGUgJnF1b3Q7bGlzdCBvZiBzY29wZXMmcXVvdDsgZnJvbSBteSBpbXBsZW1lbnRh dGlvbg0KIGlkZWE/IFRoZSBQUiB3b3VsZCBuZWVkIHRvIGtub3cgdGhlIGxpc3Qgb2Ygc2NvcGVz IHRvIHJldHVybiB0aGUgY29ycmVjdCBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBhbnl3YXkgKGFz c3VtaW5nIGEgQmVhcmVyIHRva2VuIGlzIHVzZWQgaGVyZSksIHNvIEknbSBub3Qgc3VyZSBpdCdz IHJlYWxseSBiZXR0ZXIuIEFuZCB0aGUgcmVzb3VyY2VfaWQgaXMgb3B0aW9uYWwsIHNvIHdoYXQg d291bGQgaGFwcGVuIGlmIGl0J3Mgbm90IHByb3ZpZGVkPw0KIHlvdSdkIGhhdmUgKm1vcmUqIGlu Zm9ybWF0aW9uIHJldHVybmVkPyBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGp1c3QgYSBmcmFt ZXdvcmsgYW5kIGVhY2ggc2VydmVyIHdvdWxkIGhhdmUgaXRzIG93biBydWxlcywgYnV0IHlvdSdy ZSB0aGVuIGVpdGhlciBzYXlpbmcgdG9vIG11Y2ggb3IgdG9vIGZldy48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgZ3VpZGFuY2UgYWJvdXQg aG93IHRvIGFjaGlldmUgbXkgZ29hbC4gU2hvdWxkIEkgZ28gd2l0aCBpbnRyb3NwZWN0aW9uPyAo bWF5YmUgSSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZywgb3Igc2F3IGEgdGhyZWF0cyB3aGVyZSB0 aGVyZSBpc24ndCkgb3Igc2hvdWxkIEkgdXNlIHNvbWV0aGluZyBlbHNlPyBEb2VzIG15IGluaXRp YWwgaWRlYSBtYWtlIHNlbnNlPyBTaG91bGQgSSBnbyB3aXRoIGl0PzxiciBjbGVhcj0iYWxsIj4N CjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQpUaG9tYXMgQnJveWVyPGJyPg0KL3Q8YSBocmVm PSJodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8iPsmULm1hLmLKgXdhLmplLzwvYT4g PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_63692DF546164F53B12E518397CFEFB3mitreorg_-- From t.broyer@gmail.com Wed Oct 23 17:27:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1111E829A for ; Wed, 23 Oct 2013 17:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4p86sd8QaKF for ; Wed, 23 Oct 2013 17:27:56 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8211E82A4 for ; Wed, 23 Oct 2013 17:27:53 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jx11so873207veb.21 for ; Wed, 23 Oct 2013 17:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=esoUN++Cwfs6bMZyanjBGRaEOwzTQ8jnQQVGejfxdnY=; b=IXc7f4bbqhS2PCfJNPtS7nE46603NrZgLtwb62uzgUCH98unoCTaIkvm0PlY+cho3P UcifCPEfV9ebgPpGEUO+bjoIiyNbWGdZRFVNYw/+phrKVCPVfjSB3OiYuJsJYzmJp1ev ZtxL6sBLk2mPPRTAhRlnDiv8XpjAFcaipdcZYHar5jLo5yYC/jTYootBgP9HKdCQAKZG JA69087RNSqObkyo9QKypujRN1vEtqcdBg6GciSbpuNWZJKyWs7wL4JGj4fal6Hcnpwb GJ4esJjYsY2JGkEmxwMBiYsIcy6lty4tI/9+7PqGuB0Ol6SdTHmsZibf9vj9zd/N6VpN DN7Q== X-Received: by 10.58.136.231 with SMTP id qd7mr2939026veb.1.1382574473297; Wed, 23 Oct 2013 17:27:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Wed, 23 Oct 2013 17:27:33 -0700 (PDT) In-Reply-To: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> From: Thomas Broyer Date: Thu, 24 Oct 2013 02:27:33 +0200 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=047d7b5d45d05b47c504e971b477 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 00:27:57 -0000 --047d7b5d45d05b47c504e971b477 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wrote: > Hi Thomas, > > You're right in that the introspection process is about getting meta > data about a particular token by making an authenticated call. It does > reveal a lot of information about the token -- because that's exactly the > point of the protocol. :) > > If the PR is compromised, then the attacker would be able to do anything > the PR can do, including reusing any tokens handed to the PR (assuming > they're bearer tokens). > Yes, this is the problem with bearer tokens. Is there any spec for 'proof tokens' besides http-mac? As a mean of mitigating the issue, I was thinking about delivering a refresh_token and asking Clients to generate (ask the AS) different access tokens for each PR (or "resource set"). That would of course solve the issue with introspection giving too much information (to my taste), but puts burden on Client implementors, with no guarantee that they'll actually do it. AFAICT, only a 'proof token' would really solve the issue; it's in our backlog. > This is true without doing introspection at all, since you can just steal > and start broadcasting the token. > But then the AS could revoke the access token when it detects a high rate of validation/introspection requests from many different PRs, particularly many such requests in error! Giving the compromised victim the list of scopes for the token would severely limits the number of errors and it would be much harder to detect such compromised entities. Also, if the PR is compromised, all the data protected at that PR is also > compromised, so you've got other problems too. > That's a problem between the PR and the ROs then, unrelated to the AS or even Clients. It becomes a problem with the whole system when compromising one entity (other than the AS) gives access to personal data in others. > The "resource_id" parameter is meant to be a service-specific hint that > the PR can hand to the AS to give context to the transaction. You could > easily use this field to pass along the list of scopes that you mention > below. > I had just skimmed through resource-reg and didn't remember the "resource set" concept. Now that I re-read it, I better understand what that resource_id can be. > You can have your AS return no information other than the "valid" field in > the response and leave out the scopes, subject, client id, and everything > else. All those fields are optional. However, in practice we've found it > very helpful to reveal to the PR which scopes and audiences that a token > was issued for so that the PR can use that information to make > authorization decisions. > But aren't authorization decisions the responsibility of the AS? If the PR sent the scopes (or resource_id, but that would closely couple the protocol with resource-reg, which I don't think is desirable) to the AS, then the PR could authorize access based only on a yes/no response (and the "no" response would give information about the "why", to be sent directly to the Client) > But if all you're after is answering the question "is this token valid" > and you don't want any other information, your AS is fully allowed to do > answer just that question. > As I said, I do need "more information", or rather, a more "contextual" information. I think I'll just go with my custom protocol for now. Thanks for your answer. --047d7b5d45d05b47c504e971b477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. <jricher@mitre.= org> wrote:
Hi Thomas,

You're right in that the introspection process is about getting me= ta data about a particular token by making an authenticated call. It does r= eveal a lot of information about the token -- because that's exactly th= e point of the protocol. :)=C2=A0

If the PR is compromised, then the attacker would be able to do anythi= ng the PR can do, including reusing any tokens handed to the PR (assuming t= hey're bearer tokens).

Yes, this is the problem with bearer tokens. Is there any spec for 'pro= of tokens' besides http-mac?
As a mean of mitigating the issu= e, I was thinking about delivering a refresh_token and asking Clients to ge= nerate (ask the AS) different access tokens for each PR (or "resource = set"). That would of course solve the issue with introspection giving = too much information (to my taste), but puts burden on Client implementors,= with no guarantee that they'll actually do it. AFAICT, only a 'pro= of token' would really solve the issue; it's in our backlog.
=C2=A0
This is true without doing introspection at all, since you ca= n just steal and start broadcasting the token.

But th= en the AS could revoke the access token when it detects a high rate of vali= dation/introspection requests from many different PRs, particularly many su= ch requests in error!
Giving the compromised victim the list of scopes for the token would s= everely limits the number of errors and it would be much harder to detect s= uch compromised entities.

Also, if the PR is compromised, al= l the data protected at that PR is also compromised, so you've got othe= r problems too.

That's a pr= oblem between the PR and the ROs then, unrelated to the AS or even Clients.=
It becomes a problem with the whole system when compromising one entit= y (other than the AS) gives access to personal data in others.
= =C2=A0
The "resource_id" parameter is meant to be a service-specifi= c hint that the PR can hand to the AS to give context to the transaction. Y= ou could easily use this field to pass along the list of scopes that you me= ntion below.

I had just skimmed through resource-= reg and didn't remember the "resource set" concept. Now that = I re-read it, I better understand what that resource_id can be.
=C2=A0
You can have your AS return no information other than the "valid" field in the response and lea= ve out the scopes, subject, client id, and everything else. All those field= s are optional. However, in practice we've found it very helpful to rev= eal to the PR which scopes and audiences that a token was issued for so that the PR can use that information to make aut= horization decisions.

But aren&= #39;t authorization decisions the responsibility of the AS?
If the PR sent the scopes (or resource_id, but that would closely couple th= e protocol with resource-reg, which I don't think is desirable) to the = AS, then the PR could authorize access based only on a yes/no response (and= the "no" response would give information about the "why&quo= t;, to be sent directly to the Client)
=C2=A0
But if all you're after is answering the question "i= s this token valid" and you don't want any other information, your= AS is fully allowed to do answer just that question.

As I said, I do need= "more information", or rather, a more "contextual" inf= ormation.

I think I'll just go with my custom = protocol for now. Thanks for your answer.
--047d7b5d45d05b47c504e971b477-- From t.broyer@gmail.com Wed Oct 23 17:36:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A2C11E8264 for ; Wed, 23 Oct 2013 17:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNTCyC7U8-NL for ; Wed, 23 Oct 2013 17:36:12 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2411E827C for ; Wed, 23 Oct 2013 17:36:10 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so695510vbb.36 for ; Wed, 23 Oct 2013 17:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ir9E5+SwouiE/7ND3LLiafdI1TIrGQHgPe5GKYQwA7M=; b=ZNwjU5Xb5dqSYZlZ4J5jQwxRomq8rsDPkUjPfdP8ToKOvXSz1gmBGkpz0CZIyte5ME 4U4OmxmMV92GELEnnQRSD1sQ2MZjuPiPLYiEFOYwV80iX8p9LAbaQuPfAp7dq/WcueN3 LK336hvsbLvZEfzr1IcbVrxC0KgrCDMngAftQ94QfQDROlqG4zC67dPwCVYCjuTrHdCB KHChJQGESUwZJF4EpzX94WpYLCmKHc5sWzzrbjQqJmO54w/kTJkcRMm5D/x+vmAxiQGX 4ti25QcxKYXsT1BVFOftY/LwTZa0SFK6tQ4CWDQOXqTdKYiouiIeOrc5Ynhi4jIUXRhT abJQ== X-Received: by 10.52.116.237 with SMTP id jz13mr16200vdb.74.1382574970158; Wed, 23 Oct 2013 17:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Wed, 23 Oct 2013 17:35:49 -0700 (PDT) In-Reply-To: <599199F8-DEE3-45B0-85DA-53DDD17975D7@xmlgrrl.com> References: <599199F8-DEE3-45B0-85DA-53DDD17975D7@xmlgrrl.com> From: Thomas Broyer Date: Thu, 24 Oct 2013 02:35:49 +0200 Message-ID: To: Eve Maler Content-Type: multipart/alternative; boundary=bcaec5486432f8f5e804e971d143 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 00:36:12 -0000 --bcaec5486432f8f5e804e971d143 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 23, 2013 at 8:37 PM, Eve Maler wrote: > Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth > and Justin's token introspection draft. Token introspection on its own is a > "shallow" kind of loose coupling between authorization servers and resource > servers. If these are operated by different organizations, as appears to be > the case for you, then "deep" loose coupling may be need to answer > questions about how the AS and RS onboard and establish trust with each > other. UMA provides one set of answers for how to do this. You can find > more info at http://tinyurl.com/umawg. > There are interesting concepts in UMA. In our case though, AS, PR and Clients are all operated by different organizations, but we do have "strong coupling" between them (a central registry of PRs and Clients). Thanks anyway. --bcaec5486432f8f5e804e971d143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 23, 2013 at 8:37 PM, Eve Maler <eve@xmlgrrl.com><= /span> wrote:
Hi = Thomas-- You may want to take a look at UMA, which leverages both OAuth and= Justin's token introspection draft. Token introspection on its own is = a "shallow" kind of loose coupling between authorization servers = and resource servers. If these are operated by different organizations, as = appears to be the case for you, then "deep" loose coupling may be= need to answer questions about how the AS and RS onboard and establish tru= st with each other. UMA provides one set of answers for how to do this. You= can find more info at http://tinyurl.com/umawg.

There are interesting concepts in UM= A. In our case though, AS, PR and Clients are all operated by different org= anizations, but we do have "strong coupling" between them (a cent= ral registry of PRs and Clients). Thanks anyway.
--bcaec5486432f8f5e804e971d143-- From torsten@lodderstedt.net Wed Oct 23 22:50:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F5011E814E for ; Wed, 23 Oct 2013 22:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwo6+WZv2kgF for ; Wed, 23 Oct 2013 22:50:14 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 92EBC11E8128 for ; Wed, 23 Oct 2013 22:50:13 -0700 (PDT) Received: from [80.187.109.136] (helo=[10.209.101.132]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VZDoA-0000VB-NQ; Thu, 24 Oct 2013 07:50:11 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----FHOQIQ9EQW8SBANL6JMQZXWT4VWZW4" From: Torsten Lodderstedt Date: Thu, 24 Oct 2013 07:50:07 +0200 To: Thomas Broyer , "Richer, Justin P." Message-ID: <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 05:50:18 -0000 ------FHOQIQ9EQW8SBANL6JMQZXWT4VWZW4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Thomas, we generate access tokens per resource server in order to mitigate this and other risks. You must issue those tokens to different audiences (resource server id) and the resource servers must validate if the token is issued for its particular audience. Otherwise a compromised resource server can still abuse the tokens. Talking about burden: You need to compare the effort needed to obtain different access tokens to the effort needed to implement proof of possession. I recommend you to take a look into the OAuth threat model for a discussion of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4). regards, Torsten. Thomas Broyer schrieb: >On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. >wrote: > >> Hi Thomas, >> >> You're right in that the introspection process is about getting meta >> data about a particular token by making an authenticated call. It >does >> reveal a lot of information about the token -- because that's exactly >the >> point of the protocol. :) >> >> If the PR is compromised, then the attacker would be able to do >anything >> the PR can do, including reusing any tokens handed to the PR >(assuming >> they're bearer tokens). >> > >Yes, this is the problem with bearer tokens. Is there any spec for >'proof >tokens' besides http-mac? >As a mean of mitigating the issue, I was thinking about delivering a >refresh_token and asking Clients to generate (ask the AS) different >access >tokens for each PR (or "resource set"). That would of course solve the >issue with introspection giving too much information (to my taste), but >puts burden on Client implementors, with no guarantee that they'll >actually >do it. AFAICT, only a 'proof token' would really solve the issue; it's >in >our backlog. > > >> This is true without doing introspection at all, since you can just >steal >> and start broadcasting the token. >> > >But then the AS could revoke the access token when it detects a high >rate >of validation/introspection requests from many different PRs, >particularly >many such requests in error! >Giving the compromised victim the list of scopes for the token would >severely limits the number of errors and it would be much harder to >detect >such compromised entities. > >Also, if the PR is compromised, all the data protected at that PR is >also >> compromised, so you've got other problems too. >> > >That's a problem between the PR and the ROs then, unrelated to the AS >or >even Clients. >It becomes a problem with the whole system when compromising one entity >(other than the AS) gives access to personal data in others. > > >> The "resource_id" parameter is meant to be a service-specific hint >that >> the PR can hand to the AS to give context to the transaction. You >could >> easily use this field to pass along the list of scopes that you >mention >> below. >> > >I had just skimmed through resource-reg and didn't remember the >"resource >set" concept. Now that I re-read it, I better understand what that >resource_id can be. > > >> You can have your AS return no information other than the "valid" >field in >> the response and leave out the scopes, subject, client id, and >everything >> else. All those fields are optional. However, in practice we've found >it >> very helpful to reveal to the PR which scopes and audiences that a >token >> was issued for so that the PR can use that information to make >> authorization decisions. >> > >But aren't authorization decisions the responsibility of the AS? >If the PR sent the scopes (or resource_id, but that would closely >couple >the protocol with resource-reg, which I don't think is desirable) to >the >AS, then the PR could authorize access based only on a yes/no response >(and >the "no" response would give information about the "why", to be sent >directly to the Client) > > >> But if all you're after is answering the question "is this token >valid" >> and you don't want any other information, your AS is fully allowed to >do >> answer just that question. >> > >As I said, I do need "more information", or rather, a more "contextual" >information. > >I think I'll just go with my custom protocol for now. Thanks for your >answer. > > >------------------------------------------------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------FHOQIQ9EQW8SBANL6JMQZXWT4VWZW4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Thomas,

we generate access tokens per resource server in order to mitigate this and other risks. You must issue those tokens to different audiences (resource server id) and the resource servers must validate if the token is issued for its particular audience. Otherwise a compromised resource server can still abuse the tokens.

Talking about burden: You need to compare the effort needed to obtain different access tokens to the effort needed to implement proof of possession.

I recommend you to take a look into the OAuth threat model for a discussion of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).

regards,
Torsten.





Thomas Broyer <t.broyer@gmail.com> schrieb:



On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. <jricher@mitre.org> wrote:
Hi Thomas,

You're right in that the introspection process is about getting meta data about a particular token by making an authenticated call. It does reveal a lot of information about the token -- because that's exactly the point of the protocol. :) 

If the PR is compromised, then the attacker would be able to do anything the PR can do, including reusing any tokens handed to the PR (assuming they're bearer tokens).

Yes, this is the problem with bearer tokens. Is there any spec for 'proof tokens' besides http-mac?
As a mean of mitigating the issue, I was thinking about delivering a refresh_token and asking Clients to generate (ask the AS) different access tokens for each PR (or "resource set"). That would of course solve the issue with introspection giving too much information (to my taste), but puts burden on Client implementors, with no guarantee that they'll actually do it. AFAICT, only a 'proof token' would really solve the issue; it's in our backlog.
 
This is true without doing introspection at all, since you can just steal and start broadcasting the token.

But then the AS could revoke the access token when it detects a high rate of validation/introspection requests from many different PRs, particularly many such requests in error!
Giving the compromised victim the list of scopes for the token would severely limits the number of errors and it would be much harder to detect such compromised entities.

Also, if the PR is compromised, all the data protected at that PR is also compromised, so you've got other problems too.

That's a problem between the PR and the ROs then, unrelated to the AS or even Clients.
It becomes a problem with the whole system when compromising one entity (other than the AS) gives access to personal data in others.
 
The "resource_id" parameter is meant to be a service-specific hint that the PR can hand to the AS to give context to the transaction. You could easily use this field to pass along the list of scopes that you mention below.

I had just skimmed through resource-reg and didn't remember the "resource set" concept. Now that I re-read it, I better understand what that resource_id can be.
 
You can have your AS return no information other than the "valid" field in the response and leave out the scopes, subject, client id, and everything else. All those fields are optional. However, in practice we've found it very helpful to reveal to the PR which scopes and audiences that a token was issued for so that the PR can use that information to make authorization decisions.

But aren't authorization decisions the responsibility of the AS?
If the PR sent the scopes (or resource_id, but that would closely couple the protocol with resource-reg, which I don't think is desirable) to the AS, then the PR could authorize access based only on a yes/no response (and the "no" response would give information about the "why", to be sent directly to the Client)
 
But if all you're after is answering the question "is this token valid" and you don't want any other information, your AS is fully allowed to do answer just that question.

As I said, I do need "more information", or rather, a more "contextual" information.

I think I'll just go with my custom protocol for now. Thanks for your answer.


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------FHOQIQ9EQW8SBANL6JMQZXWT4VWZW4-- From jricher@mitre.org Thu Oct 24 07:37:56 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925911E8339 for ; Thu, 24 Oct 2013 07:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7ALUAFXhY2U for ; Thu, 24 Oct 2013 07:37:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBC111E830E for ; Thu, 24 Oct 2013 07:37:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F9F51F083A; Thu, 24 Oct 2013 10:36:59 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8DE3F1F082E; Thu, 24 Oct 2013 10:36:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 10:36:59 -0400 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: Comments on draft-richer-oauth-introspection-04 Thread-Index: AQHO0CU84Zn8ICoUOUaw6JzqL1n5yZoDQm2AgADtUwA= Date: Thu, 24 Oct 2013 14:36:58 +0000 Message-ID: References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.37.166] Content-Type: multipart/alternative; boundary="_000_F2BC6DBC28F9425B8D8F6F553B1D8B3Cmitreorg_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:37:56 -0000 --_000_F2BC6DBC28F9425B8D8F6F553B1D8B3Cmitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 23, 2013, at 5:27 PM, Thomas Broyer > wrote: On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. > wrote: Hi Thomas, You're right in that the introspection process is about getting meta data a= bout a particular token by making an authenticated call. It does reveal a l= ot of information about the token -- because that's exactly the point of th= e protocol. :) If the PR is compromised, then the attacker would be able to do anything th= e PR can do, including reusing any tokens handed to the PR (assuming they'r= e bearer tokens). Yes, this is the problem with bearer tokens. Is there any spec for 'proof t= okens' besides http-mac? As a mean of mitigating the issue, I was thinking about delivering a refres= h_token and asking Clients to generate (ask the AS) different access tokens= for each PR (or "resource set"). That would of course solve the issue with= introspection giving too much information (to my taste), but puts burden o= n Client implementors, with no guarantee that they'll actually do it. AFAIC= T, only a 'proof token' would really solve the issue; it's in our backlog. There are a couple of proposed holder-of-key type tokens proposed but none = have been accepted by the working group yet. We'd be glad to have more inpu= t into it. This is true without doing introspection at all, since you can just steal a= nd start broadcasting the token. But then the AS could revoke the access token when it detects a high rate o= f validation/introspection requests from many different PRs, particularly m= any such requests in error! Giving the compromised victim the list of scopes for the token would severe= ly limits the number of errors and it would be much harder to detect such c= ompromised entities. It depends on how closely the scopes map to specific resources and how much= the attacker knows about that environment. It sounds like your usage of OA= uth places a significant amount of information into the scope which would l= eak that information. In such an environment, having the PR supply the scop= e in the request somehow instead of the AS returning the scope in the respo= nse might help. However, what would prevent a compromised PR from fishing f= or the scopes of a given token, assuming they know the overall set of scope= s the token could be good for? In our own implementation, the PR's are tied to a specific scope set and th= e AS knows which scopes a particular PR is meant to use. With this informat= ion, by local policy we can actually limit which tokens the PR is allowed t= o introspect. Also, if the PR is compromised, all the data protected at that PR is also c= ompromised, so you've got other problems too. That's a problem between the PR and the ROs then, unrelated to the AS or ev= en Clients. It becomes a problem with the whole system when compromising one entity (ot= her than the AS) gives access to personal data in others. Yes, and there are other means for mitigating these risks, as Torsten point= ed out, and you'll really want to be doing these anyway in your system. The "resource_id" parameter is meant to be a service-specific hint that the= PR can hand to the AS to give context to the transaction. You could easily= use this field to pass along the list of scopes that you mention below. I had just skimmed through resource-reg and didn't remember the "resource s= et" concept. Now that I re-read it, I better understand what that resource_= id can be. The resource_id isn't necessarily a resource set identifier, though it can = be. It was really meant as a way for the PR to say "here's the context of t= he token being used". The other piece of context is the client identifier t= hat's used as part of the client authenticating the call to the introspecti= on endpoint. These, coupled with the token itself, can give a very complete= view of the request.. You can have your AS return no information other than the "valid" field in = the response and leave out the scopes, subject, client id, and everything e= lse. All those fields are optional. However, in practice we've found it ver= y helpful to reveal to the PR which scopes and audiences that a token was i= ssued for so that the PR can use that information to make authorization dec= isions. But aren't authorization decisions the responsibility of the AS? Partially, but it's the PR that makes the ultimate decision of whether or n= ot to let the request proceed. The AS can only help provide information for= the PR to make that final decision. If the PR sent the scopes (or resource_id, but that would closely couple th= e protocol with resource-reg, which I don't think is desirable) to the AS, = then the PR could authorize access based only on a yes/no response (and the= "no" response would give information about the "why", to be sent directly = to the Client) Again, I want to point out that resource_id isn't necessarily meant to be c= oupled with the resource registration protocol (though it can nicely overla= p). An interesting idea to send back the reason why from the AS, I'm assuming t= his would be one of the error codes defined by RFC6750? You'd want to be ca= reful about exposing too much information in the error though. But if all you're after is answering the question "is this token valid" and= you don't want any other information, your AS is fully allowed to do answe= r just that question. As I said, I do need "more information", or rather, a more "contextual" inf= ormation. And you can add that contextual information, like UMA does, as part of the = JSON structure that's returned. I think I'll just go with my custom protocol for now. Thanks for your answe= r. I would encourage you to rethink that stance, especially if the introspecti= on protocol can be changed to accommodate your use case without breaking th= e existing use case that people are using it for. As it's a draft standard = I'm fine with us tweaking things. Additionally, starting with introspection= as it is would leave the door open to you interoperating with other system= s in the future and even moving to a more comprehensive protocol like UMA. -- Justin --_000_F2BC6DBC28F9425B8D8F6F553B1D8B3Cmitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 23, 2013, at 5:27 PM, Thomas Broyer <t.broyer@gmail.com>
 wrote:

On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
Hi Thomas,

You're right in that the introspection process is about getting meta d= ata about a particular token by making an authenticated call. It does revea= l a lot of information about the token -- because that's exactly the point = of the protocol. :) 

If the PR is compromised, then the attacker would be able to do anythi= ng the PR can do, including reusing any tokens handed to the PR (assuming t= hey're bearer tokens).

Yes, this is the problem with bearer tokens. Is there any spec for 'pr= oof tokens' besides http-mac?
As a mean of mitigating the issue, I was thinking about delivering a r= efresh_token and asking Clients to generate (ask the AS) different access t= okens for each PR (or "resource set"). That would of course solve= the issue with introspection giving too much information (to my taste), but puts burden on Client implementors, with no= guarantee that they'll actually do it. AFAICT, only a 'proof token' would = really solve the issue; it's in our backlog.

There are a couple of proposed holder-of-key type tokens proposed but = none have been accepted by the working group yet. We'd be glad to have more= input into it.

 
This is true without doing introspectio= n at all, since you can just steal and start broadcasting the token.

But then the AS could revoke the access token when it detects a high r= ate of validation/introspection requests from many different PRs, particula= rly many such requests in error!
Giving the compromised victim the list of scopes for the token would s= everely limits the number of errors and it would be much harder to detect s= uch compromised entities.

It depends on how closely the scopes map to specific resources and how= much the attacker knows about that environment. It sounds like your usage = of OAuth places a significant amount of information into the scope which wo= uld leak that information. In such an environment, having the PR supply the scope in the request somehow inst= ead of the AS returning the scope in the response might help. However, what= would prevent a compromised PR from fishing for the scopes of a given toke= n, assuming they know the overall set of scopes the token could be good for? 

In our own implementation, the PR's are tied to a specific scope set a= nd the AS knows which scopes a particular PR is meant to use. With this inf= ormation, by local policy we can actually limit which tokens the PR is allo= wed to introspect.


Also, if the PR is compromised, all the= data protected at that PR is also compromised, so you've got other problem= s too.

That's a problem between the PR and the ROs then, unrelated to the AS = or even Clients.
It becomes a problem with the whole system when compromising one entit= y (other than the AS) gives access to personal data in others.

Yes, and there are other means for mitigating these risks, as Torsten = pointed out, and you'll really want to be doing these anyway in your system= .

 
The "resource_id" parameter is meant to be a service-specifi= c hint that the PR can hand to the AS to give context to the transaction. Y= ou could easily use this field to pass along the list of scopes that you me= ntion below.

I had just skimmed through resource-reg and didn't remember the "= resource set" concept. Now that I re-read it, I better understand what= that resource_id can be.

The resource_id isn't necessarily a resource set identifier, though it= can be. It was really meant as a way for the PR to say "here's the co= ntext of the token being used". The other piece of context is the clie= nt identifier that's used as part of the client authenticating the call to the introspection endpoint. These, coupled with= the token itself, can give a very complete view of the request..

 
You can have your AS return no informat= ion other than the "valid" field in the response and leave out th= e scopes, subject, client id, and everything else. All those fields are opt= ional. However, in practice we've found it very helpful to reveal to the PR which scopes and audiences that a token was is= sued for so that the PR can use that information to make authorization deci= sions.

But aren't authorization decisions the responsibility of the AS?

Partially, but it's the PR that makes the ultimate decision of whether= or not to let the request proceed. The AS can only help provide informatio= n for the PR to make that final decision. 

If the PR sent the scopes (or resource_id, but that would closely coup= le the protocol with resource-reg, which I don't think is desirable) to the= AS, then the PR could authorize access based only on a yes/no response (an= d the "no" response would give information about the "why", to be sent directly to the Client)

Again, I want to point out that resource_id isn't necessarily meant to= be coupled with the resource registration protocol (though it can nicely o= verlap). 

An interesting idea to send back the reason why from the AS, I'm assum= ing this would be one of the error codes defined by RFC6750? You'd want to = be careful about exposing too much information in the error though.

 
But if all you're after is answering th= e question "is this token valid" and you don't want any other inf= ormation, your AS is fully allowed to do answer just that question.

As I said, I do need "more information", or rather, a more &= quot;contextual" information.

And you can add that contextual information, like UMA does, as part of= the JSON structure that's returned.


I think I'll just go with my custom protocol for now. Thanks for your = answer.

I would encourage you to rethink that stance, especially if the intros= pection protocol can be changed to accommodate your use case without breaki= ng the existing use case that people are using it for. As it's a draft stan= dard I'm fine with us tweaking things. Additionally, starting with introspection as it is would leave the door op= en to you interoperating with other systems in the future and even moving t= o a more comprehensive protocol like UMA.

 -- Justin
--_000_F2BC6DBC28F9425B8D8F6F553B1D8B3Cmitreorg_-- From phil.hunt@oracle.com Thu Oct 24 15:29:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B1511E81FA for ; Thu, 24 Oct 2013 15:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6F1pC9lfew5 for ; Thu, 24 Oct 2013 15:29:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id E751A11E8222 for ; Thu, 24 Oct 2013 15:29:04 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9OMT2fa016755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Oct 2013 22:29:03 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 r9OMT1ox029182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 22:29:02 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9OMT1Cw001636; Thu, 24 Oct 2013 22:29:01 GMT Received: from [10.151.103.210] (/148.87.13.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Oct 2013 15:29:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_357D4213-F1EC-47C6-9865-29538A534930" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: Date: Thu, 24 Oct 2013 15:29:01 -0700 Message-Id: <533D7882-E26C-469B-9F50-22694D70456A@oracle.com> References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-tcse-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 22:29:13 -0000 --Apple-Mail=_357D4213-F1EC-47C6-9865-29538A534930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Nat/Naveen, I must confess I keep going back and forth on this issue. Clearly this draft is a fix for the issue of: 1. Real app initiates authorize request 2. 'bad' app intercepts grant because it has taken over the access = token. But while I agree this is a problem, what's to stop the 'bad' app from = doing 1 and 2? As they say all bets are off. I can register "Facebook = Blue" and make it look like the next generation facebook app. Even if we could prove that an app is legit by some cryptographic means, = we are still limited by Mobile App store vendors, and how well they = curate apps, and what they do to make sure only legit apps can run. Naveen, you mentioned at IIW, we really have to depend more on the user = authorization of the app. Can you comment here? I think the draft is correct. It fixes the problem it describes. But = does it matter? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-10-19, at 3:15 AM, Nat Sakimura wrote: > Incorporated the discussion at Berlin meeting and after in the ML.=20 >=20 > Best,=20 >=20 > Nat >=20 > ---------- Forwarded message ---------- > From: > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura , John Bradley = , Naveen Agarwal >=20 >=20 >=20 > A new version of I-D, draft-sakimura-oauth-tcse-02.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. >=20 > Filename: draft-sakimura-oauth-tcse > Revision: 02 > Title: OAuth Symmetric Proof of Posession for Code Extension > Creation date: 2013-10-19 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt > Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-tcse-02 >=20 > Abstract: > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. This specification > describe a mechanism that acts as a control against this threat. >=20 >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_357D4213-F1EC-47C6-9865-29538A534930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Even if we could prove that an app is = legit by some cryptographic means, we are still limited by Mobile App = store vendors, and how well they curate apps, and what they do to make = sure only legit apps can run.

Naveen, you = mentioned at IIW, we really have to depend more on the user = authorization of the app.  Can you comment = here?

I think the draft is correct. It fixes = the problem it describes.  But does it = matter?


On 2013-10-19, at 3:15 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

Incorporated the discussion at Berlin = meeting and after in the = ML. 

Best, 

Nat
<= br>
---------- Forwarded message = ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/10/19
Subject: New Version Notification for = draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <sakimura@gmail.com>, John = Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        02
Title:           OAuth Symmetric Proof of = Posession for Code Extension
Creation date:   2013-10-19
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02<= /a>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-= tcse-02

Abstract:
   The OAuth 2.0 public client utilizing authorization code = grant is
   susceptible to the code interception attack.  This = specification
   describe a mechanism that acts as a control against this = threat.





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.

The IETF Secretariat




--
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_357D4213-F1EC-47C6-9865-29538A534930-- From t.broyer@gmail.com Fri Oct 25 02:20:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C696A11E8392 for ; Fri, 25 Oct 2013 02:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD+TwpM1ifFb for ; Fri, 25 Oct 2013 02:20:23 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8D11E839E for ; Fri, 25 Oct 2013 02:20:17 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so2512442vbf.38 for ; Fri, 25 Oct 2013 02:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YFePt1PMDh56pY/8WHEdC4ICbNaua3qaduG7FOZSO8U=; b=DUTYR6Lir6F1qRSn39oHUBVXZ0WfWxPmMKgd3yodXU1GAY2O/+15SRQwfbAFN9HjjQ mC4AXWJqWA0KV5jBsltl+rRD7khjSUqQ78wC7R01QvYUD+TleM/+zWpAWScOANrDJID4 EYAzuazVS2AOSOBtJeC18CBczd78fCJJxfmLVd/He8+FoA+FjsqYAdzTYX4jlDMMDHNo Z4H6JhvfL7l62m68RKvEuzycZyTJ5bxV1sD2ESlppxVEySsROnSKxpgchSxm9q45ZObP lRisivy+PeK+hjdhDwfVSm8tlse9Rq+Yh6zyHHSSHDBpVfeNuieAk4BGsI+Z4kTkANym M6Bg== X-Received: by 10.58.233.98 with SMTP id tv2mr3922893vec.11.1382692810507; Fri, 25 Oct 2013 02:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 02:19:50 -0700 (PDT) In-Reply-To: <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> From: Thomas Broyer Date: Fri, 25 Oct 2013 11:19:50 +0200 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=089e0115ef9ccdd0e704e98d411f Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:20:25 -0000 --089e0115ef9ccdd0e704e98d411f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Thomas, > > we generate access tokens per resource server in order to mitigate this > and other risks. You must issue those tokens to different audiences > (resource server id) and the resource servers must validate if the token = is > issued for its particular audience. Otherwise a compromised resource serv= er > can still abuse the tokens. > > Talking about burden: You need to compare the effort needed to obtain > different access tokens to the effort needed to implement proof of > possession. > On our backlog is also support for "service accounts" (to use Google's terminology), so clients will likely need to do some crypto-related work. Asking them to do it for each and every request to sign the access token might not be that much of a problem (if they have the right tools; google-oauth-java-client for instance does a great job making all of this easier, and google-api-java-client adds service accounts support with a just-as-easy-to-use API: https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accoun= ts; same for PHP, Python, etc.) That said, I'm rather new to crypto too, so I might be oversimplifying things=E2=80=A6 I'll check with the project manager and project owner which approach we'd use (we could also support both=E2=80=A6) I recommend you to take a look into the OAuth threat model for a discussion > of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4). > Thanks for the pointer. I had already read that RFC but somehow forgot about some details, and failed to check it back for that particular problem= . --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e0115ef9ccdd0e704e98d411f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <torste= n@lodderstedt.net> wrote:
Hi Thomas,

we generate access tokens per resource server in order to mitigate this and= other risks. You must issue those tokens to different audiences (resource = server id) and the resource servers must validate if the token is issued fo= r its particular audience. Otherwise a compromised resource server can stil= l abuse the tokens.

Talking about burden: You need to compare the effort needed to obtain diffe= rent access tokens to the effort needed to implement proof of possession.

On our backlog is also support for= "service accounts" (to use Google's terminology), so clients= will likely need to do some crypto-related work. Asking them to do it for = each and every request to sign the access token might not be that much of a= problem (if they have the right tools; google-oauth-java-client for instan= ce does a great job making all of this easier, and google-api-java-client a= dds service accounts support with a just-as-easy-to-use API:=C2=A0https://code.google.com/p/google-api-java-client/wiki/OAuth2#Servic= e_Accounts; same for PHP, Python, etc.)
That said, I'm rather new to crypto too, so I might be oversimplif= ying things=E2=80=A6
I'll check with the project manager and = project owner which approach we'd use (we could also support both=E2=80= =A6)

I recommend you to take a look into the OAuth threat model for a discussion= of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4)= .

Thanks for the pointer. I had alread= y read that RFC but somehow forgot about some details, and failed to check = it back for that particular problem.


--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--089e0115ef9ccdd0e704e98d411f-- From t.broyer@gmail.com Fri Oct 25 03:00:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92611E8135 for ; Fri, 25 Oct 2013 03:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQCe55AHUi-L for ; Fri, 25 Oct 2013 03:00:17 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7311E8144 for ; Fri, 25 Oct 2013 03:00:05 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id cz12so2430695veb.10 for ; Fri, 25 Oct 2013 03:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LEF2WK5FRuDthb5+Pv0nl0tzbQZXtRbd2nWP4EWNZRg=; b=zXx+zdNXZPgIfEt6lVFGdqg8c4MdPouogXBff+tz2p99Q3e56jox8Y12FEt8YLTtUs xNolYEjdLWcMOQnD6UvgPcBxOU6QHCC/phlvrW5S/PriTZohjM5Jn+t+KRya9d4KoJp5 YqL12Le9KXeMVmCwb/BCqyG77YeJXtnUcEomX3PfUmCUiBGP0Ary7bbj8DdIqkM1dM4k M/3Vnk70BQUIu/sp6wkwREuB24NMOaSTYtFimsHXaFOJXZfj+m6cs6xiD0CsReb5u14e W+OtznGktd9XOObzozboCqMChMvWQ3+vBAYXzaYE+VPNEe3vtzvz/qeRsWiTcfEcXReI fbkg== X-Received: by 10.58.207.15 with SMTP id ls15mr4006879vec.17.1382695204755; Fri, 25 Oct 2013 03:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 02:59:44 -0700 (PDT) In-Reply-To: References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> From: Thomas Broyer Date: Fri, 25 Oct 2013 11:59:44 +0200 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=047d7b6dc6ee8325e404e98dd020 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 10:00:18 -0000 --047d7b6dc6ee8325e404e98dd020 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. wrote= : > On Oct 23, 2013, at 5:27 PM, Thomas Broyer > wrote: > > On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wr= ote: > >> Hi Thomas, >> >> You're right in that the introspection process is about getting meta >> data about a particular token by making an authenticated call. It does >> reveal a lot of information about the token -- because that's exactly th= e >> point of the protocol. :) >> >> If the PR is compromised, then the attacker would be able to do >> anything the PR can do, including reusing any tokens handed to the PR >> (assuming they're bearer tokens). >> > > Yes, this is the problem with bearer tokens. Is there any spec for > 'proof tokens' besides http-mac? > As a mean of mitigating the issue, I was thinking about delivering a > refresh_token and asking Clients to generate (ask the AS) different acces= s > tokens for each PR (or "resource set"). That would of course solve the > issue with introspection giving too much information (to my taste), but > puts burden on Client implementors, with no guarantee that they'll actual= ly > do it. AFAICT, only a 'proof token' would really solve the issue; it's in > our backlog. > > > There are a couple of proposed holder-of-key type tokens proposed but > none have been accepted by the working group yet. We'd be glad to have mo= re > input into it. > Any pointer? I've only see http-mac, but I'm surprised to find nothing similar to jwt-bearer (i.e. a signed JWT whose claim set includes the access token; the resource server could then send the JWT to the AS which would verify the signature and validity of the JWT wrt "exp", "iat", "nbf" and "jti" fields, and embedded access token =E2=80=93could be the "sub"?=E2=80=93; th= e JWT couldn't be used with other resource servers as its "aud" field wouldn't match) http-mac looks much more complex, and probably with very good reasons, but my gut feeling is that if something like jwt-bearer, which looks simpler, is deemed secure enough as grant-type or client-assertion-type, why would it be different for accessing protected resources? (disclaimer: remember, I'm not a security guy) > This is true without doing introspection at all, since you can just >> steal and start broadcasting the token. >> > > But then the AS could revoke the access token when it detects a high > rate of validation/introspection requests from many different PRs, > particularly many such requests in error! > Giving the compromised victim the list of scopes for the token would > severely limits the number of errors and it would be much harder to detec= t > such compromised entities. > > > It depends on how closely the scopes map to specific resources and how > much the attacker knows about that environment. It sounds like your usage > of OAuth places a significant amount of information into the scope which > would leak that information. > It's not yet really clear for us, but it'll probably be the case yes. > In such an environment, having the PR supply the scope in the request > somehow instead of the AS returning the scope in the response might help. > However, what would prevent a compromised PR from fishing for the scopes = of > a given token, assuming they know the overall set of scopes the token cou= ld > be good for? > Ah yes, fair enough=E2=80=A6 A resource_id would be a good abstraction then, as it would be "private", only known to the resource server and authorization server, making it harder to fish for other possible uses of the token. > In our own implementation, the PR's are tied to a specific scope set and > the AS knows which scopes a particular PR is meant to use. With this > information, by local policy we can actually limit which tokens the PR is > allowed to introspect. > Are you also returning different values for the "scope" based on which PR makes the request? (filtering them to only include scopes the PR is tied to= ) (I'm a web guy, and "profiling" the response depending on who accesses it goes against my REST background and is not natural to me, but that would work I guess) An interesting idea to send back the reason why from the AS, I'm assuming > this would be one of the error codes defined by RFC6750? > Yes. When using Token Introspection, that wouldn't be really needed though: a 400 response from the AS maps to an invalid_request, and {"active":false} to an invalid_token, and the PR is in charge of determining whether to return an insufficient_scope error. > But if all you're after is answering the question "is this token valid" >> and you don't want any other information, your AS is fully allowed to do >> answer just that question. >> > > As I said, I do need "more information", or rather, a more "contextual" > information. > > > And you can add that contextual information, like UMA does, as part of > the JSON structure that's returned. > By "more contextual", I meant that the "yes/no" response is more "precise" than just "active/inactive": it's a yes/no for a particular request. The only difference with Token Introspection is about disclosing the scopes to the PR or not. > > I think I'll just go with my custom protocol for now. Thanks for your > answer. > > > I would encourage you to rethink that stance, especially if the > introspection protocol can be changed to accommodate your use case withou= t > breaking the existing use case that people are using it for. As it's a > draft standard I'm fine with us tweaking things. Additionally, starting > with introspection as it is would leave the door open to you interoperati= ng > with other systems in the future and even moving to a more comprehensive > protocol like UMA. > I'll try out Token Introspection and see if it can match. I actually already know it will IFF I trade "wide scoped" bearer tokens to either "one bearer token per resource server" (like Torsten said) or "proof tokens". --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --047d7b6dc6ee8325e404e98dd020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. <jricher@mitre.= org> wrote:
On Oct 23, 2013, at 5:27 PM, Thomas Broyer <t.broyer@gmail.com>
=C2=A0wrote:

On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin = P. <jricher@mitre.or= g> wrote:
Hi Thomas,

You're right in that the introspection process is about getting me= ta data about a particular token by making an authenticated call. It does r= eveal a lot of information about the token -- because that's exactly th= e point of the protocol. :)=C2=A0

If the PR is compromised, then the attacker would be able to do anythi= ng the PR can do, including reusing any tokens handed to the PR (assuming t= hey're bearer tokens).

Yes, this is the problem with bearer tokens. Is there any spec for = 9;proof tokens' besides http-mac?
As a mean of mitigating the issue, I was thinking about delivering a r= efresh_token and asking Clients to generate (ask the AS) different access t= okens for each PR (or "resource set"). That would of course solve= the issue with introspection giving too much information (to my taste), but puts burden on Client implementors, with no= guarantee that they'll actually do it. AFAICT, only a 'proof token= ' would really solve the issue; it's in our backlog.

There are a couple of proposed holder-of-key type tokens propose= d but none have been accepted by the working group yet. We'd be glad to= have more input into it.

Any pointer?
I've only see http-mac, but I'm surpris= ed to find nothing similar to jwt-bearer (i.e. a signed JWT whose claim set= includes the access token; the resource server could then send the JWT to = the AS which would verify the signature and validity of the JWT wrt "e= xp", "iat", "nbf" and "jti" fields, and = embedded access token =E2=80=93could be the "sub"?=E2=80=93; the = JWT couldn't be used with other resource servers as its "aud"= field wouldn't match)
http-mac looks much more complex, and probably with very good reasons,= but my gut feeling is that if something like jwt-bearer, which looks simpl= er, is deemed secure enough as grant-type or client-assertion-type, why wou= ld it be different for accessing protected resources?
(disclaimer: remember, I'm not a security guy)
=C2=A0
=
This is true without doing introspectio= n at all, since you can just steal and start broadcasting the token.

But then the AS could revoke the access token when it detects a high r= ate of validation/introspection requests from many different PRs, particula= rly many such requests in error!
Giving the compromised victim the list of scopes for the token would s= everely limits the number of errors and it would be much harder to detect s= uch compromised entities.

It depends on how closely the scopes map to specific resources a= nd how much the attacker knows about that environment. It sounds like your = usage of OAuth places a significant amount of information into the scope wh= ich would leak that information.

It's not yet really clear = for us, but it'll probably be the case yes.
=C2=A0
In such an environment, having the PR supply the scope in the request somehow inst= ead of the AS returning the scope in the response might help. However, what= would prevent a compromised PR from fishing for the scopes of a given toke= n, assuming they know the overall set of scopes the token could be good for?
<= div>
Ah yes, fair enough=E2=80=A6
A resource_id wou= ld be a good abstraction then, as it would be "private", only kno= wn to the resource server and authorization server, making it harder to fis= h for other possible uses of the token.
=C2=A0
In our own implementation, the PR's are tied to a specific scope s= et and the AS knows which scopes a particular PR is meant to use. With this= information, by local policy we can actually limit which tokens the PR is = allowed to introspect.

Are you also returning differe= nt values for the "scope" based on which PR makes the request? (f= iltering them to only include scopes the PR is tied to)
(I'm = a web guy, and "profiling" the response depending on who accesses= it goes against my REST background and is not natural to me, but that woul= d work I guess)

An interesting idea to send back the reason why from the AS, I'm a= ssuming this would be one of the error codes defined by RFC6750?

Yes.

When using Token Introspection, that wouldn't be really needed though: = a 400 response from the AS maps to an invalid_request, and {"active&qu= ot;:false} to an invalid_token, and the PR is in charge of determining whet= her to return an insufficient_scope error.
=C2=A0
<= blockquote type=3D"cite">
But if all you're after is answerin= g the question "is this token valid" and you don't want any o= ther information, your AS is fully allowed to do answer just that question.=

As I said, I do need "more information", or rather, a more &= quot;contextual" information.

And you can add that contextual information, like UMA does, as p= art of the JSON structure that's returned.

By "more contextual", I meant that the &quo= t;yes/no" response is more "precise" than just "active/= inactive": it's a yes/no for a particular request.
The only difference with Token Introspection is about disclosing the s= copes to the PR or not.

I think I'll just go with my custom protocol for now. Thanks for y= our answer.

I would encourage you to rethink that stance, especially if the intros= pection protocol can be changed to accommodate your use case without breaki= ng the existing use case that people are using it for. As it's a draft = standard I'm fine with us tweaking things. Additionally, starting with introspection as it is would leave the door op= en to you interoperating with other systems in the future and even moving t= o a more comprehensive protocol like UMA.
=C2=A0
I'll try = out Token Introspection and see if it can match. I actually already know it= will IFF I trade "wide scoped" bearer tokens to either "one= bearer token per resource server" (like Torsten said) or "proof = tokens".


--
Thomas B= royer
/t=C9=94.ma.b=CA=81w= a.je/
--047d7b6dc6ee8325e404e98dd020-- From torsten@lodderstedt.net Fri Oct 25 10:28:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA92211E8201 for ; Fri, 25 Oct 2013 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN-u9hSgmBUG for ; Fri, 25 Oct 2013 10:28:18 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC411E81B6 for ; Fri, 25 Oct 2013 10:28:18 -0700 (PDT) Received: from [79.253.53.26] (helo=[192.168.71.44]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VZlBI-00015E-2q; Fri, 25 Oct 2013 19:28:16 +0200 Message-ID: <526AAA2F.5020705@lodderstedt.net> Date: Fri, 25 Oct 2013 19:28:15 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Broyer References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030803060900010302010008" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:28:23 -0000 This is a multi-part message in MIME format. --------------030803060900010302010008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 25.10.2013 11:19, schrieb Thomas Broyer: > > > > On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt > > wrote: > > Hi Thomas, > > we generate access tokens per resource server in order to mitigate > this and other risks. You must issue those tokens to different > audiences (resource server id) and the resource servers must > validate if the token is issued for its particular audience. > Otherwise a compromised resource server can still abuse the tokens. > > Talking about burden: You need to compare the effort needed to > obtain different access tokens to the effort needed to implement > proof of possession. > > > On our backlog is also support for "service accounts" (to use Google's > terminology), so clients will likely need to do some crypto-related > work. Asking them to do it for each and every request to sign the > access token might not be that I assume you mean signing the request or at least some request data. Just signing the access token won't help. > much of a problem (if they have the right tools; > google-oauth-java-client for instance does a great job making all of > this easier, and google-api-java-client adds service accounts support > with a just-as-easy-to-use API: > https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accounts; > same for PHP, Python, etc.) > That said, I'm rather new to crypto too, so I might be oversimplifying > things… > I'll check with the project manager and project owner which approach > we'd use (we could also support both…) > > I recommend you to take a look into the OAuth threat model for a > discussion of this threat ( > http://tools.ietf.org/html/rfc6819#section-4.6.4). > > > Thanks for the pointer. I had already read that RFC but somehow forgot > about some details, and failed to check it back for that particular > problem. > > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ --------------030803060900010302010008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Am 25.10.2013 11:19, schrieb Thomas Broyer:



On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Thomas,

we generate access tokens per resource server in order to mitigate this and other risks. You must issue those tokens to different audiences (resource server id) and the resource servers must validate if the token is issued for its particular audience. Otherwise a compromised resource server can still abuse the tokens.

Talking about burden: You need to compare the effort needed to obtain different access tokens to the effort needed to implement proof of possession.

On our backlog is also support for "service accounts" (to use Google's terminology), so clients will likely need to do some crypto-related work. Asking them to do it for each and every request to sign the access token might not be that

I assume you mean signing the request or at least some request data. Just signing the access token won't help.

much of a problem (if they have the right tools; google-oauth-java-client for instance does a great job making all of this easier, and google-api-java-client adds service accounts support with a just-as-easy-to-use API: https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accounts; same for PHP, Python, etc.)
That said, I'm rather new to crypto too, so I might be oversimplifying things…
I'll check with the project manager and project owner which approach we'd use (we could also support both…)

I recommend you to take a look into the OAuth threat model for a discussion of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).

Thanks for the pointer. I had already read that RFC but somehow forgot about some details, and failed to check it back for that particular problem.


--
Thomas Broyer
/tɔ.ma.bʁwa.je/

--------------030803060900010302010008-- From t.broyer@gmail.com Fri Oct 25 13:01:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3911E8137 for ; Fri, 25 Oct 2013 13:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8XJRzLryXNt for ; Fri, 25 Oct 2013 13:01:21 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F239811E814F for ; Fri, 25 Oct 2013 13:01:20 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w16so2843214vbf.21 for ; Fri, 25 Oct 2013 13:01:20 -0700 (PDT) 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; bh=iGbnSLZuB2lACjZHKojvPH2PUataQxdlrm8qnMQTZoE=; b=OLNDr9nUHf86XW0s1CPkrhWuNhfRnH6ne9WOOUv5KAqgX+WZ4fPyRre7ziHrEJs79e NkKAv9/ZLWOEfDP6EJUXiWNMfgTModUCGao87jtxEFtZsin05OxJp4pj33wJp7aRZiBd m9bnAZWbc/9OFA8bkRZuZ9ogBwFrIferdD1rFWYZyE3B1R3XDs9AWqUkxparQcHBQGji OM+uFMIiV3l70IytLec8U6biqvYcrDyUnV1ug1c8xi2G7S53Mr6dXkC2oyNnIOsBQdBI +I5jivr7dd1f5wGkNEGov3kj3tpTNsMxia4aOEDnXe5ITkK8b9iZS7cPBKA+DEaIKi5/ EtMg== MIME-Version: 1.0 X-Received: by 10.58.180.227 with SMTP id dr3mr923635vec.36.1382731280370; Fri, 25 Oct 2013 13:01:20 -0700 (PDT) Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 13:01:19 -0700 (PDT) Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 13:01:19 -0700 (PDT) In-Reply-To: <526AAA2F.5020705@lodderstedt.net> References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> <526AAA2F.5020705@lodderstedt.net> Date: Fri, 25 Oct 2013 22:01:19 +0200 Message-ID: From: Thomas Broyer To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=047d7b66fbcfc9838604e99636a3 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:01:22 -0000 --047d7b66fbcfc9838604e99636a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 25 oct. 2013 19:28, "Torsten Lodderstedt" a =C3=A9crit : > > > Am 25.10.2013 11:19, schrieb Thomas Broyer: >> >> >> >> >> On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: >>> >>> Hi Thomas, >>> >>> we generate access tokens per resource server in order to mitigate this and other risks. You must issue those tokens to different audiences (resource server id) and the resource servers must validate if the token is issued for its particular audience. Otherwise a compromised resource server can still abuse the tokens. >>> >>> Talking about burden: You need to compare the effort needed to obtain different access tokens to the effort needed to implement proof of possession. >> >> >> On our backlog is also support for "service accounts" (to use Google's terminology), so clients will likely need to do some crypto-related work. Asking them to do it for each and every request to sign the access token might not be that > > > I assume you mean signing the request or at least some request data. Just signing the access token won't help. I meant signing the access token + PR identifier/URI + some timestamp, at a minimum. I explained it better in my answer to Justin; something like jwt-bearer applied to access tokens. >> much of a problem (if they have the right tools; google-oauth-java-client for instance does a great job making all of this easier, and google-api-java-client adds service accounts support with a just-as-easy-to-use API: https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accoun= ts; same for PHP, Python, etc.) >> That said, I'm rather new to crypto too, so I might be oversimplifying things=E2=80=A6 >> I'll check with the project manager and project owner which approach we'd use (we could also support both=E2=80=A6) >> >>> I recommend you to take a look into the OAuth threat model for a discussion of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.= 4 ). >> >> >> Thanks for the pointer. I had already read that RFC but somehow forgot about some details, and failed to check it back for that particular problem= . >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ > > --047d7b66fbcfc9838604e99636a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le 25 oct. 2013 19:28, "Torsten Lodderstedt" <torsten@lodderstedt.net> a =C3=A9crit : >
>
> Am 25.10.2013 11:19, schrieb Thomas Broyer:
>>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<= br> >>>
>>> Hi Thomas,
>>>
>>> we generate access tokens per resource server in order to miti= gate this and other risks. You must issue those tokens to different audienc= es (resource server id) and the resource servers must validate if the token= is issued for its particular audience. Otherwise a compromised resource se= rver can still abuse the tokens.
>>>
>>> Talking about burden: You need to compare the effort needed to= obtain different access tokens to the effort needed to implement proof of = possession.
>>
>>
>> On our backlog is also support for "service accounts" (t= o use Google's terminology), so clients will likely need to do some cry= pto-related work. Asking them to do it for each and every request to sign t= he access token might not be that
>
>
> I assume you mean signing the request or at least some request data. J= ust signing the access token won't help.

I meant signing the access token + PR identifier/URI + some = timestamp, at a minimum.
I explained it better in my answer to Justin; something like jwt-bearer app= lied to access tokens.

>> much of a problem (if they have the right tools; go= ogle-oauth-java-client for instance does a great job making all of this eas= ier, and google-api-java-client adds service accounts support with a just-a= s-easy-to-use API:=C2=A0https://code.google.com/p/google-api= -java-client/wiki/OAuth2#Service_Accounts; same for PHP, Python, etc.)<= br> >> That said, I'm rather new to crypto too, so I might be oversim= plifying things=E2=80=A6
>> I'll check with the project manager and project owner which ap= proach we'd use (we could also support both=E2=80=A6)
>>
>>> I recommend you to take a look into the OAuth threat model for= a discussion of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).
>>
>>
>> Thanks for the pointer. I had already read that RFC but somehow fo= rgot about some details, and failed to check it back for that particular pr= oblem.
>>
>>
>> --
>> Thomas Broyer
>> /t=C9=94.ma.b=CA=81w= a.je/
>
>

--047d7b66fbcfc9838604e99636a3-- From phil.hunt@oracle.com Fri Oct 25 13:41:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80E811E81ED for ; Fri, 25 Oct 2013 13:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my8QMfUyPt6O for ; Fri, 25 Oct 2013 13:41:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 498E111E8108 for ; Fri, 25 Oct 2013 13:41:14 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9PKfClV008036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Oct 2013 20:41:13 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 r9PKfCGe011563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Oct 2013 20:41:12 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9PKfCTO000905 for ; Fri, 25 Oct 2013 20:41:12 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Oct 2013 13:41:12 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_0416F88A-F6DE-4B63-9932-BDA48B745925" Message-Id: Date: Fri, 25 Oct 2013 13:41:14 -0700 To: oauth list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [OAUTH-WG] items for the Vancouver agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:41:21 -0000 --Apple-Mail=_0416F88A-F6DE-4B63-9932-BDA48B745925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chairs, I'd like to request some time to present the Software Statement and = Client Association drafts as part of the overall Client registration = discussion. The method Tony and I have proposed reflects a pattern = (token swap using the 4.5 extension) that is actually in wide use today. I would also like to hear more about John Bradley and Justin Richer's = new = http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-0= 0.txt draft. There is also yet another method of handling "association" (by using a = split client with a server side client component holding client creds) = that Dick Hardt talked about at IIW. If Dick is unable to attend, I = would be happy to try to do justice to his idea. If we have time, it may be worthwhile discussing authentication draft = that Tony and I submitted in Berlin. In particular, now that OIDC is = finalizing, we should discuss whether it is better to align the user = authen for clients draft 100% with OIDC or whether to keep it in a = different direction. As it stands now, the draft is only partially = aligned. I recognize this draft is NOT within the current charter, = however if the group wants to discuss it (because it is timely), I am = willing to put something together. Nat's TSCE draft also falls into the category of non-charter items. I = think this is potentially an important extension or an errata to the = current draft and is also a worthwhile new business item. Finally, I'm not sure who might be able to lead this (Tim?), but there = was some interesting views expressed by Google staffers at this weeks = IIW in Mountain View that seem to indicate that the need for client = credentials in mobile apps may not need to be as strong as we thought or = needed at all. This has interesting implications for the registration = drafts we are discussing. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_0416F88A-F6DE-4B63-9932-BDA48B745925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/internet-drafts/draft-bradley-stateless= -oauth-client-00.txt draft.

There is = also yet another method of handling "association" (by using a split = client with a server side client component holding client creds) that = Dick Hardt talked about at IIW.  If Dick is unable to attend, I = would be happy to try to do justice to his = idea.

If we have time, it may be worthwhile = discussing authentication draft that Tony and I submitted in Berlin. =  In particular, now that OIDC is finalizing, we should discuss = whether it is better to align the user authen for clients draft 100% = with OIDC or whether to keep it in a different direction.  As it = stands now, the draft is only partially aligned.  I recognize this = draft is NOT within the current charter, however if the group wants to = discuss it (because it is timely), I am willing to put something = together.

Nat's TSCE draft also falls into the = category of non-charter items. I think this is potentially an important = extension or an errata to the current draft and is also a worthwhile new = business item.

Finally, I'm not sure who might = be able to lead this (Tim?), but there was some interesting views = expressed by Google staffers at this weeks IIW in Mountain View that = seem to indicate that the need for client credentials in mobile apps may = not need to be as strong as we thought or needed at all. This has = interesting implications for the registration drafts we are = discussing.
= --Apple-Mail=_0416F88A-F6DE-4B63-9932-BDA48B745925-- From lainhart@us.ibm.com Fri Oct 25 13:48:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C111E81DC for ; Fri, 25 Oct 2013 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3NvZqzx8Gq0 for ; Fri, 25 Oct 2013 13:48:13 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD411E8152 for ; Fri, 25 Oct 2013 13:47:58 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Oct 2013 14:47:57 -0600 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 Oct 2013 14:47:56 -0600 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8692F38C8042 for ; Fri, 25 Oct 2013 16:47:54 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9PKltW765863856 for ; Fri, 25 Oct 2013 20:47:55 GMT Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9PKlt1E027109 for ; Fri, 25 Oct 2013 16:47:55 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9PKltAO027106 for ; Fri, 25 Oct 2013 16:47:55 -0400 To: "IETF oauth WG" MIME-Version: 1.0 X-KeepSent: 6CCBF50C:668DDA9B-85257C0F:0070D399; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP4 SHF39 May 13, 2013 Message-ID: From: Todd W Lainhart Date: Fri, 25 Oct 2013 16:47:53 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 10/25/2013 16:47:55, Serialize complete at 10/25/2013 16:47:55 Content-Type: multipart/alternative; boundary="=_alternative 007240F285257C0F_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102520-9332-0000-0000-000001EDAD8E Subject: [OAUTH-WG] A couple of questions re dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:48:24 -0000 This is a multipart message in MIME format. --=_alternative 007240F285257C0F_= Content-Type: text/plain; charset="US-ASCII" I'm working off this document for our client registration: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14 Section 4 - Client Configuration Endpoint says this: The client MUST use its registration access token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750]. I'm trying to understand if I should provide a separate administrative endpoint for client configurations (i.e. accessible via an entity with admin credentials/privileges). I think this language is telling me "yes". What are the client options for read/update/delete should this access token be lost? I read "none". Section 4.1 - Section 4.1 says this: The authorization server MUST provide the client with the fully qualified URL in the "registration_client_uri" element of the Client Information Response (Section 5.1). I'm curious as to why this isn't returned in the Location header? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com --=_alternative 007240F285257C0F_= Content-Type: text/html; charset="US-ASCII" I'm working off this document for our client registration: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14

Section 4 - Client Configuration Endpoint says this:

The client MUST use its registration access token in
  all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].

I'm trying to understand if I should provide a separate administrative endpoint for client configurations (i.e. accessible via an entity with admin credentials/privileges).  I think this language is telling me "yes".  What are the client options for read/update/delete should this access token be lost?  I read "none".

Section 4.1 - Section 4.1 says this:

The authorization server MUST provide the client with the fully
  qualified URL in the "registration_client_uri" element of the Client
  Information Response (Section 5.1).

I'm curious as to why this isn't returned in the Location header?





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

--=_alternative 007240F285257C0F_=-- From twbray@google.com Fri Oct 25 14:08:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A511111E8218 for ; Fri, 25 Oct 2013 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGrTaqGiE7Rv for ; Fri, 25 Oct 2013 14:08:23 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 18F1411E8220 for ; Fri, 25 Oct 2013 14:08:15 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id l12so1677058wiv.3 for ; Fri, 25 Oct 2013 14:08:14 -0700 (PDT) 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=yduVZ64DRD4i2ELe4vx+iKiF0tSIWDbUGxsPgaD9dW8=; b=b3yPFWt6Silm07vNE2P/4/1mKxEx3XKSGRZQJ7vaAl2GAL+Ld/j2VM+al5ahABYSfx 0EEn79Qw6MTc5j5m7vbfaHUBoKt0ZuH+UsqUiWedJenAnCz2ABItCoI7DW2OLSc/qo9W YNxDsqqp0jw1irqxhoSzGoI0NqVb9sXpTMQjiG/RuOyEtCk5tWWN2YQgdtg87dEjxu51 mxdxqeIBgiAC+Nc8p7sqgcR1VPykWk83ZhUBy8F4LubP2Bh/RGrJr2nhJKuqKJcVDSZu mezwZ1EUgCAc6iHFIwPKS3pvPlDneSB8ZTBvpmsdYBNuGYPl+9SO97Mo5XemH7CjW3VY mLUw== 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=yduVZ64DRD4i2ELe4vx+iKiF0tSIWDbUGxsPgaD9dW8=; b=liJXNu7asrWutOPGd58OWUfeokMYaVHMlRswtOWYillooQlngSLom2NxGIGFf85hs1 xAQa/2It2cZ0qzpHmdRAcZUC8S/8UBpyK3WSTnOKhmcZH2xFmdlgZizCqE/98ZKw1fVh lm1EQNmyRwsOyhDyHs5A8RjWo4jNdiMndXxP+FH3F7s5mkh9H1fwFHGVdNf6gA9nwGrO lZkaLb5b7N8dDFJH6xdyWubzcXlOsKVoOB9AGEUtCUAUXQ6BpuBSwa2coNgLrFfeihEd cuopPpcZzgySpv/rqoNcpdAV/FyySdFMjNL96O1Xb4ymGktk//077caVtmA/FwruTzuA n8Fg== X-Gm-Message-State: ALoCoQkV/EqkHTbu9XNA33LgXzem0HNM3vrsWGgPpbftCrgOnTV2Fk8cIVn1iBLh1NQ9gWhGHzPiTSDzqzKLoNweFdrk9jVbN/SpSk2HYc+Qv9/R2WPUDKWc6djVwDL81ne/Sb1OCrJ/U1kscGbxpKOtqfCbDu9iKu2iXr0f5MUiNI9AkkEIyBhJtI17dIQEbfycgVqzBPFl X-Received: by 10.181.12.75 with SMTP id eo11mr215228wid.24.1382735294266; Fri, 25 Oct 2013 14:08:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.12.7 with HTTP; Fri, 25 Oct 2013 14:07:44 -0700 (PDT) In-Reply-To: References: From: Tim Bray Date: Fri, 25 Oct 2013 14:07:44 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d043c7c56089efc04e997264f Cc: oauth list Subject: Re: [OAUTH-WG] items for the Vancouver agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:08:24 -0000 --f46d043c7c56089efc04e997264f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 25, 2013 at 1:41 PM, Phil Hunt wrote: > Finally, I'm not sure who might be able to lead this (Tim?), but there wa= s > some interesting views expressed by Google staffers at this weeks IIW in > Mountain View that seem to indicate that the need for client credentials = in > mobile apps may not need to be as strong as we thought or needed at all. > This has interesting implications for the registration drafts we are > discussing. > We hear lots of developers saying they want to know for sure the identity of the client, and that=E2=80=99s what we use the azp claim in the ID Token= for, but it=E2=80=99s very fragile in the face of a determined attacker, more so= than the other claims. Not sure how much there is to talk about... > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d043c7c56089efc04e997264f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 25, 2013 at 1:41 PM, Phil Hunt <phil.hunt@orac= le.com> wrote:
Fin= ally, I'm not sure who might be able to lead this (Tim?), but there was= some interesting views expressed by Google staffers at this weeks IIW in M= ountain View that seem to indicate that the need for client credentials in = mobile apps may not need to be as strong as we thought or needed at all. Th= is has interesting implications for the registration drafts we are discussi= ng.

We hear lots of developers saying th= ey want to know for sure the identity of the client, and that=E2=80=99s wha= t we use the azp claim in the ID Token for, but it=E2=80=99s very fragile i= n the face of a determined attacker, more so than the other claims. =C2=A0N= ot sure how much there is to talk about...

=C2=A0
=C2=A0

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


--f46d043c7c56089efc04e997264f-- From jricher@mitre.org Sat Oct 26 09:03:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADE311E81AD for ; Sat, 26 Oct 2013 09:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrmn8uk5r1ak for ; Sat, 26 Oct 2013 09:03:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAF711E81A0 for ; Sat, 26 Oct 2013 09:03:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0B331F092C; Sat, 26 Oct 2013 12:03:29 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A54CE1F0557; Sat, 26 Oct 2013 12:03:29 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Sat, 26 Oct 2013 12:03:29 -0400 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 Thread-Index: AQHO0CU84Zn8ICoUOUaw6JzqL1n5yZoFJoYmgADLaoCAACrEgIABT7mA Date: Sat, 26 Oct 2013 16:03:28 +0000 Message-ID: References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> <526AAA2F.5020705@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.3.191] Content-Type: multipart/alternative; boundary="_000_AEDCC30D5BE8464AAA44A366049015CFmitreorg_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:03:36 -0000 --_000_AEDCC30D5BE8464AAA44A366049015CFmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >> On our backlog is also support for "service accounts" (to use Google's t= erminology), so clients will likely need to do some crypto-related work. As= king them to do it for each and every request to sign the access token migh= t not be that > > > I assume you mean signing the request or at least some request data. Just= signing the access token won't help. I meant signing the access token + PR identifier/URI + some timestamp, at a= minimum. I explained it better in my answer to Justin; something like jwt-bearer app= lied to access tokens. I suggested to the group that we try something like this a while ago but it= didn't get traction at the time. I never really wrote down the whole proce= ss I had in mind, so here's a quick overview: First, the client gets a token from the auth server using any normal oauth = mechanism (or any abnormal mechanism for that matter), and the response loo= ks something like this: { token_type: signed, access_token: token_key: alg: expires_in: 3600 =85 } Next, the client figures out the request it wants to make: GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1 Accept: application/json X-Other-Header: SomeHeaderValue Treating this request as a structure, we've got a verb, a url (with scheme,= host, path, parameters), and some headers. We want the client to be able t= o sign some subset of this with the request, so let's say this client wants= to sign the verb, scheme+host+port+path, the parameters, and one of the he= aders. So the way I see it we've got a couple options. First is to repeat a= ll the items to be signed within a JSON structure and use JWS. This is mess= y and it ignores some of the best stuff about using HTTP/REST these days. S= econd, we can combine, normalize, and hash the signable items. With this ap= proach and some sufficient handwavium (because I don't really want to get i= nto specifics of serialization and normalization here), we get something li= ke this for a base string: GET http://foo.bar/baz quux=3Dbob woz=3Dwhynot X-Other-Header=3DSomeHeaderValue which we can hash using a defined algorithm of the same bit size as our sig= ning algorithm. So say we're using HMAC 256, we get a base64url encoded has= h blob like this fake one I just made up: HJ23dfjoa32fasd23lajkds So great, we've got a hash and we've got a set of data that was hashed. So = far we're in the same boat that got a lot of OAuth 1.0 implementations in t= rouble, due to oddities about normalization. So let's take this a step furt= her and tell the server what we're hashing in our signed content, but by re= peating just the *keys* to this content and not the content itself, since t= he keys will be shorter in many cases and less redundant: signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, {"header"= : ["X-Other-Header"]} ] Note that this uses arrays, which is important because arrays preserve orde= r in JSON. Now we have a pretty programmatic way of telling the server whic= h bits we care about signing and what order we put them in, with normalizin= g those aspects. This makes us robust against stuff getting reordered and n= ew headers or query parameters being inserted (which often happens with var= ious web frameworks). Of course, after verifying a signature, an app would = want to make sure that important parameters were covered by that signature,= but that's up to the app. Any decent library would make the list available= to the app easily enough for a quick check. OK, so now we've got our hash and our note on what we hashed. Let's put tho= se into a JSON object: { hash: HJ23dfjoa32fasd23lajkds, signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, {"header"= : ["X-Other-Header"]} ], token_id: } And we'll make our normal JWS header, use the above JSON object as the bode= , and sign it with JWS using the secret/key that we got up in the token res= ponse: eyheaderstufffooo.eybodystuffbaaar.signatureblob [Side note: Maybe if you really wanted to you could also sign it using the = client secret and include the client id in the signed data, like OAuth 1.0 = does.] And *now* we can send this over using any method comparable to those define= d in RFC6750, since it's all a single, self-contained value. GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1 Accept: application/json X-Other-Header: SomeHeaderValue Authorization: SignedOAuth eyheaderstufffooo.eybodystuffbaaar.signatureblob or: GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot&signed_access_token=3Deyhead= erstufffooo.eybodystuffbaaar.signatureblob HTTP/1.1 Accept: application/json X-Other-Header: SomeHeaderValue Note that in the both cases, the newly introduced header and query paramete= r are automatically excused from the signature calculation because they don= 't show up in the signed lists. OK, so the RS gets this request, and what does it do? Easy: First, check the signature on the token. This is self-contained and is a qu= ick JWS operation. [Side note: how does the RS get the private signing/chec= king key from the AS? I don't care, and neither should you, because it's or= thogonal to this part of the spec family.] Second, the RS parses the body and reads the "signed" member. This "signed"= member tells the RS which parts of the original request it needs to check.= Even with extra parameters and bits you end up pulling only the parts that= you need. And you know what order to smash them together, too, without doi= ng any kind of sorting! Third, the RS calculates the hash of this string and compares it, literally= , to the "hash" parameter that was sent. Fourth, the RS makes sure any "important" parameters and headers and other = bits are actually covered by the hash. Anyway, I think this method is worlds simpler than what we've got in http-m= ac right now and it goes back to solving a number of the use cases that hav= e been brought up, including my own of simply protecting an HTTP message ap= art from tokens. -- Justin --_000_AEDCC30D5BE8464AAA44A366049015CFmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3C74845FACD9FC40BF8EB7AD86CE4ABF@imc.mitre.org> Content-Transfer-Encoding: quoted-printable

>> On our backlog is also support for "service ac= counts" (to use Google's terminology), so clients will likely need to = do some crypto-related work. Asking them to do it for each and every reques= t to sign the access token might not be that
>
>
> I assume you mean signing the request or at least some request data. J= ust signing the access token won't help.

I meant signing the access token + PR identifier/URI = 3; some timestamp, at a minimum.
I explained it better in my answer to Justin; something like jwt-bearer app= lied to access tokens.



I suggested to the group that we try something like this a while ago b= ut it didn't get traction at the time. I never really wrote down the whole = process I had in mind, so here's a quick overview:


First, the client gets a token from the auth server using any normal o= auth mechanism (or any abnormal mechanism for that matter), and the respons= e looks something like this:

{ 
  token_type: signed,
  access_token: <public token value>
  token_key: <private token secret used for signing, maybe as = a JWK?>
  alg: <JWS algorithm to use for signing requests to the RS, I= 'll use HS256 for my example below but we could probably tweak this to use = asymmetric keys too>
  expires_in: 3600
  =85
}


Next, the client figures out the request it wants to make:

Accept: application/json
X-Other-Header: SomeHeaderValue


Treating this request as a structure, we've got a verb, a url (with sc= heme, host, path, parameters), and some headers. We want the client to be a= ble to sign some subset of this with the request, so let's say this client = wants to sign the verb, scheme+host+port+path, the parameters, and one of the headers. So the way I see it we've got a co= uple options. First is to repeat all the items to be signed within a JSON s= tructure and use JWS. This is messy and it ignores some of the best stuff a= bout using HTTP/REST these days. Second, we can combine, normalize, and hash the signable items. With this = approach and some sufficient handwavium (because I don't really want to get= into specifics of serialization and normalization here), we get something = like this for a base string:

GET
quux=3Dbob
woz=3Dwhynot
X-Other-Header=3DSomeHeaderValue

which we can hash using a defined algorithm of the same bit size as ou= r signing algorithm. So say we're using HMAC 256, we get a base64url encode= d hash blob like this fake one I just made up: HJ23dfjoa32fasd23lajkds

So great, we've got a hash and we've got a set of data that was hashed= . So far we're in the same boat that got a lot of OAuth 1.0 implementations= in trouble, due to oddities about normalization. So let's take this a step= further and tell the server what we're hashing in our signed content, but by repeating just the *keys* to t= his content and not the content itself, since the keys will be shorter in m= any cases and less redundant:

signed: [ "verb", "scheme+host+path", {&qu= ot;query": ["quux", "woz"]}, {"header": = ["X-Other-Header"]} ]

Note that this uses arrays, which is important because arrays preserve= order in JSON. Now we have a pretty programmatic way of telling the server= which bits we care about signing and what order we put them in, with norma= lizing those aspects. This makes us robust against stuff getting reordered and new headers or query paramet= ers being inserted (which often happens with various web frameworks). Of co= urse, after verifying a signature, an app would want to make sure that impo= rtant parameters were covered by that signature, but that's up to the app. Any decent library would make th= e list available to the app easily enough for a quick check. 

OK, so now we've got our hash and our note on what we hashed. Let's pu= t those into a JSON object:

{ 
hash: HJ23dfjoa32fasd23lajkds,
signed: [ "verb", "scheme+host+path", {&qu= ot;query": ["quux", "woz"]}, {"header": = ["X-Other-Header"]} ],
token_id: <public token value>
}

And we'll make our normal JWS header, use the above JSON object as the= bode, and sign it with JWS using the secret/key that we got up in the toke= n response:

eyheaderstufffooo.eybodystuffbaaar.signatureblob


[Side note: Maybe if you really wanted to you could also sign it using= the client secret and include the client id in the signed data, like OAuth= 1.0 does.]

And *now* we can send this over using any method comparable to those d= efined in RFC6750, since it's all a single, self-contained value. 

Accept: application/json
X-Other-Header: SomeHeaderValue
Authorization: SignedOAuth eyheaderstufffooo.eybodystuffbaaar.sig= natureblob


or:

GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot&sign= ed_access_token=3Deyheaderstufffooo.eybodystuffbaaar.signatureblob = ;HTTP/1.1
Accept: application/json
X-Other-Header: SomeHeaderValue


Note that in the both cases, the newly introduced header and query par= ameter are automatically excused from the signature calculation because the= y don't show up in the signed lists. 


OK, so the RS gets this request, and what does it do? Easy: 

First, check the signature on the token. This is self-contained and is= a quick JWS operation. [Side note: how does the RS get the private signing= /checking key from the AS? I don't care, and neither should you, because it= 's orthogonal to this part of the spec family.]

Second, the RS parses the body and reads the "signed" member= . This "signed" member tells the RS which parts of the original r= equest it needs to check. Even with extra parameters and bits you end up pu= lling only the parts that you need. And you know what order to smash them together, too, without doing any kind of sorting! = ;

Third, the RS calculates the hash of this string and compares it, lite= rally, to the "hash" parameter that was sent. 

Fourth, the RS makes sure any "important" parameters and hea= ders and other bits are actually covered by the hash.



Anyway, I think this method is worlds simpler than what we've got in h= ttp-mac right now and it goes back to solving a number of the use cases tha= t have been brought up, including my own of simply protecting an HTTP messa= ge apart from tokens.

 -- Justin
--_000_AEDCC30D5BE8464AAA44A366049015CFmitreorg_-- From jricher@mitre.org Sat Oct 26 09:20:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BCD11E81AD for ; Sat, 26 Oct 2013 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js+equIp770K for ; Sat, 26 Oct 2013 09:20:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4F11E81B0 for ; Sat, 26 Oct 2013 09:20:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFF351F08C6; Sat, 26 Oct 2013 12:20:33 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D192C1F0557; Sat, 26 Oct 2013 12:20:33 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Sat, 26 Oct 2013 12:20:33 -0400 From: "Richer, Justin P." To: Todd W Lainhart Thread-Topic: [OAUTH-WG] A couple of questions re dynamic client registration Thread-Index: AQHO0cOQAlOD5rtMX0qvoMmAzT0qjpoHbhwA Date: Sat, 26 Oct 2013 16:20:32 +0000 Message-ID: <1F06FCA3-A492-46BA-9D3E-81B2BA526C98@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: [172.31.3.191] Content-Type: multipart/alternative; boundary="_000_1F06FCA3A49246BA9D3E81B2BA526C98mitreorg_" MIME-Version: 1.0 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] A couple of questions re dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:20:41 -0000 --_000_1F06FCA3A49246BA9D3E81B2BA526C98mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 25, 2013, at 1:47 PM, Todd W Lainhart > wrote: I'm working off this document for our client registration: http://tools.iet= f.org/html/draft-ietf-oauth-dyn-reg-14 Section 4 - Client Configuration Endpoint says this: The client MUST use its registration access token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750]. I'm trying to understand if I should provide a separate administrative endp= oint for client configurations (i.e. accessible via an entity with admin cr= edentials/privileges). I think this language is telling me "yes". What ar= e the client options for read/update/delete should this access token be los= t? I read "none". I would suggest it, or provide alternative mechanisms to access the endpoin= t. Our own implementation (MITREid) does the former. In our case, we also w= anted a mechanism whereby our admins can edit the client id and client secr= et directly as needed, as well as support manual registration, neither of w= hich are supported by the dynamic registration protocol (and that's on purp= ose). Section 4.1 - Section 4.1 says this: The authorization server MUST provide the client with the fully qualified URL in the "registration_client_uri" element of the Client Information Response (Section 5.1). I'm curious as to why this isn't returned in the Location header? Simply because we wanted it to be self-contained in the returned JSON objec= t. We could, I suppose, also return it in the location header, which would = follow REST principles a little better. -- Justin Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_1F06FCA3A49246BA9D3E81B2BA526C98mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <3E7B8F68934ED649BB787F3FA1282EDB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
On Oct 25, 2013, at 1:47 PM, Todd W Lainhart <lainhart@us.ibm.com>
 wrote:

I'm working = off this document for our client registration: <= font size=3D"3" color=3D"blue">http://tools.ietf.org/html/draft-ietf-oau= th-dyn-reg-14

Section 4 - Client Configuration Endpo= int says this:

The client MUST use its registration access token in
  all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].

I'm trying to understand if I should p= rovide a separate administrative endpoint for client configurations (i.e. a= ccessible via an entity with admin credentials/privileges).  I think t= his language is telling me "yes".  What are the client options for read/update/delete should this access token be lost= ?  I read "none".

I would suggest it, or provide alternative mechanisms to access the en= dpoint. Our own implementation (MITREid) does the former. In our case, we a= lso wanted a mechanism whereby our admins can edit the client id and client= secret directly as needed, as well as support manual registration, neither of which are supported by the dyna= mic registration protocol (and that's on purpose).


Section 4.1 - Section 4.1 says this:

The authorization server MUST provide the client with the fully
  qualified URL in the "registration_client_uri" element of = the Client
  Information Response (<= u>Section 5.1).

I'm curious as to why this isn't returned in the Location header?

Simply because we wanted it to be self-contained in the returned JSON = object. We could, I suppose, also return it in the location header, which w= ould follow REST principles a little better.

 -- Justin





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com

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

--_000_1F06FCA3A49246BA9D3E81B2BA526C98mitreorg_-- From t.broyer@gmail.com Sat Oct 26 13:34:47 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6928211E8176 for ; Sat, 26 Oct 2013 13:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MGnOEqvOpUu for ; Sat, 26 Oct 2013 13:34:46 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C639F11E8202 for ; Sat, 26 Oct 2013 13:34:45 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so3280897vbb.8 for ; Sat, 26 Oct 2013 13:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kionpubTdjUtOr05zIGffkqQvEz+n889E1kmQTy0sVc=; b=Ztc0L1ZfVbsLH+l45LZRIOAt8mZAVIxGLUkhn2hXDWGQoBqehTEZ6Bk+aMi0CprMlt PNdcYvLX1YV16Oo3Owrdwg46tZzlN0BkvpVdfivwHsh747RMBlI4cq/Zhco6EP02AX4S m3ZpOaxthSmKtr1dHWZ4Xy3RlD+FmG/3LL60nDvHOcwHIUr0qbt8ztF/KP3uKKB+5eb4 pSEL45ODUC6a1KgeslAQdnkjO4L9QEGvh5EsOUz/sClmO70L3zB1AFDeV2YZm/unyOk/ zDSYvS9SLojMDB+xmx2GeS2PKRGtmd+eIeVzmGH9HvzSC6SFrv9p60E+D/lYQFdLfnxE IzLg== X-Received: by 10.58.250.227 with SMTP id zf3mr735813vec.37.1382819685096; Sat, 26 Oct 2013 13:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.219.132 with HTTP; Sat, 26 Oct 2013 13:34:24 -0700 (PDT) In-Reply-To: References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> <526AAA2F.5020705@lodderstedt.net> From: Thomas Broyer Date: Sat, 26 Oct 2013 22:34:24 +0200 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e0153798a1e616504e9aacc4b Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 20:34:47 -0000 --089e0153798a1e616504e9aacc4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 26, 2013 at 6:03 PM, Richer, Justin P. wrote= : > >> On our backlog is also support for "service accounts" (to use > Google's terminology), so clients will likely need to do some > crypto-related work. Asking them to do it for each and every request to > sign the access token might not be that > > > > > > I assume you mean signing the request or at least some request data. > Just signing the access token won't help. > > I meant signing the access token + PR identifier/URI + some timestamp, at > a minimum. > I explained it better in my answer to Justin; something like jwt-bearer > applied to access tokens. > > > I suggested to the group that we try something like this a while ago but > it didn't get traction at the time. I never really wrote down the whole > process I had in mind, so here's a quick overview: > > > First, the client gets a token from the auth server using any normal > oauth mechanism (or any abnormal mechanism for that matter), and the > response looks something like this: > > { > token_type: signed, > access_token: > token_key: > alg: HS256 for my example below but we could probably tweak this to use > asymmetric keys too> > expires_in: 3600 > =E2=80=A6 > } > > > Next, the client figures out the request it wants to make: > > GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > > > Treating this request as a structure, we've got a verb, a url (with > scheme, host, path, parameters), and some headers. We want the client to = be > able to sign some subset of this with the request, so let's say this clie= nt > wants to sign the verb, scheme+host+port+path, the parameters, and one of > the headers. So the way I see it we've got a couple options. First is to > repeat all the items to be signed within a JSON structure and use JWS. Th= is > is messy and it ignores some of the best stuff about using HTTP/REST thes= e > days. Second, we can combine, normalize, and hash the signable items. Wit= h > this approach and some sufficient handwavium (because I don't really want > to get into specifics of serialization and normalization here), we get > something like this for a base string: > > GET > http://foo.bar/baz > quux=3Dbob > woz=3Dwhynot > X-Other-Header=3DSomeHeaderValue > > which we can hash using a defined algorithm of the same bit size as our > signing algorithm. So say we're using HMAC 256, we get a base64url encode= d > hash blob like this fake one I just made up: HJ23dfjoa32fasd23lajkds > > So great, we've got a hash and we've got a set of data that was hashed. > So far we're in the same boat that got a lot of OAuth 1.0 implementations > in trouble, due to oddities about normalization. So let's take this a ste= p > further and tell the server what we're hashing in our signed content, but > by repeating just the *keys* to this content and not the content itself, > since the keys will be shorter in many cases and less redundant: > > signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, > {"header": ["X-Other-Header"]} ] > > Note that this uses arrays, which is important because arrays preserve > order in JSON. Now we have a pretty programmatic way of telling the serve= r > which bits we care about signing and what order we put them in, with > normalizing those aspects. This makes us robust against stuff getting > reordered and new headers or query parameters being inserted (which often > happens with various web frameworks). Of course, after verifying a > signature, an app would want to make sure that important parameters were > covered by that signature, but that's up to the app. Any decent library > would make the list available to the app easily enough for a quick check. > > OK, so now we've got our hash and our note on what we hashed. Let's put > those into a JSON object: > > { > hash: HJ23dfjoa32fasd23lajkds, > signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, > {"header": ["X-Other-Header"]} ], > token_id: > } > > And we'll make our normal JWS header, use the above JSON object as the > bode, and sign it with JWS using the secret/key that we got up in the tok= en > response: > > eyheaderstufffooo.eybodystuffbaaar.signatureblob > > > [Side note: Maybe if you really wanted to you could also sign it using > the client secret and include the client id in the signed data, like OAut= h > 1.0 does.] > > And *now* we can send this over using any method comparable to those > defined in RFC6750, since it's all a single, self-contained value. > > GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > Authorization: > SignedOAuth eyheaderstufffooo.eybodystuffbaaar.signatureblob > > > or: > > GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot&signed_access_token=3D > eyheaderstufffooo.eybodystuffbaaar.signatureblob HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > > > Note that in the both cases, the newly introduced header and query > parameter are automatically excused from the signature calculation becaus= e > they don't show up in the signed lists. > > > OK, so the RS gets this request, and what does it do? Easy: > > First, check the signature on the token. This is self-contained and is a > quick JWS operation. [Side note: how does the RS get the private > signing/checking key from the AS? I don't care, and neither should you, > because it's orthogonal to this part of the spec family.] > > Second, the RS parses the body and reads the "signed" member. This > "signed" member tells the RS which parts of the original request it needs > to check. Even with extra parameters and bits you end up pulling only the > parts that you need. And you know what order to smash them together, too, > without doing any kind of sorting! > > Third, the RS calculates the hash of this string and compares it, > literally, to the "hash" parameter that was sent. > > Fourth, the RS makes sure any "important" parameters and headers and > other bits are actually covered by the hash. > > > > Anyway, I think this method is worlds simpler than what we've got in > http-mac right now and it goes back to solving a number of the use cases > that have been brought up, including my own of simply protecting an HTTP > message apart from tokens. > > Couldn't we have something middle-ground between bearer tokens "in the clear" (RFC6750) and signing the request like http-mac or your proposal? What I'd need is *just* a way so that a "thing" passed from the Client to the PR couldn't be reused with other PRs (should contain something that identifies the PR), and ideally couldn't also be "replayed" (let's give it a validity period, maybe also a nonce). Doesn't that nicely matches with JWT's "aud", "iat", "exp", "nbf" and possibly "jti" of JWT, as already used by jwt-bearer? Let's just use the client_id as "iss" (as in jwt-bearer) and the "access token" as "sub", and sign that. It's assumed that the AS already knows the public key of the Client so it can verify the signature; the access token response from the AS would probably include the signature algorithm that the Client is expected to use, but that could also have been "negotiated" before (just as with jwt-bearer, you have to know what the AS expects you to use). A compromised PR, despite knowing the access token (unless the JWT is encrypted rather than just signed), couldn't access other resource servers as it couldn't Just as with bearer tokens, it's assumed that PRs are reached through TLS (if you need OAuth, it means you're accessing data of the End-User, so you should use TLS anyway for privacy concerns). In the event there's an eavesdropper nevertheless, the "iat", "exp" and "nbf" limit the reuse of the token, and "jti" (if used, and used correctly) totally mitigates the risk of replay attacks. The major remaining risk is a compromised client (and of course compromised AS). I don't think we can do much things about it though, apart from heavy monitoring at the AS and blacklisting the Client whenever some bad use is detected. Remember I'm not a security guy though. Would that be too insecure? (I doubt it, everybody uses bearer tokens nowadays, and the approach is the same as with jwt-bearer) Have I missed something? --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --089e0153798a1e616504e9aacc4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 26, 2013 at 6:03 PM, Richer, Justin P. &l= t;jricher@mitre.org<= /a>> wrote:

>> On our backlog is also support for "service ac= counts" (to use Google's terminology), so clients will likely need= to do some crypto-related work. Asking them to do it for each and every re= quest to sign the access token might not be that
>
>
> I assume you mean signing the request or at least some request data. J= ust signing the access token won't help.

I meant signing the access token + PR identifier/URI + some = timestamp, at a minimum.
I explained it better in my answer to Justin; something like jwt-bearer app= lied to access tokens.



I suggested to the group that we try something like this a while= ago but it didn't get traction at the time. I never really wrote down = the whole process I had in mind, so here's a quick overview:


First, the client gets a token from the auth server using any normal o= auth mechanism (or any abnormal mechanism for that matter), and the respons= e looks something like this:

{=C2=A0
=C2=A0 token_type: signed,
=C2=A0 access_token: <public token value>
=C2=A0 token_key: <private token secret used for signing, maybe as = a JWK?>
=C2=A0 alg: <JWS algorithm to use for signing requests to the RS, I= 'll use HS256 for my example below but we could probably tweak this to = use asymmetric keys too>
=C2=A0 expires_in: 3600
=C2=A0 =E2=80=A6
}


Next, the client figures out the request it wants to make:

GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1
Accept: application/json
X-Other-Header: SomeHeaderValue


Treating this request as a structure, we've got a verb, a url (wit= h scheme, host, path, parameters), and some headers. We want the client to = be able to sign some subset of this with the request, so let's say this= client wants to sign the verb, scheme+host+port+path, the parameters, and one of the headers. So the way I see it we've got = a couple options. First is to repeat all the items to be signed within a JS= ON structure and use JWS. This is messy and it ignores some of the best stu= ff about using HTTP/REST these days. Second, we can combine, normalize, and hash the signable items. With this = approach and some sufficient handwavium (because I don't really want to= get into specifics of serialization and normalization here), we get someth= ing like this for a base string:

GET
quux=3Dbob
woz=3Dwhynot
X-Other-Header=3DSomeHeaderValue

which we can hash using a defined algorithm of the same bit size as ou= r signing algorithm. So say we're using HMAC 256, we get a base64url en= coded hash blob like this fake one I just made up: HJ23dfjoa32fasd23lajkds<= /div>

So great, we've got a hash and we've got a set of data that wa= s hashed. So far we're in the same boat that got a lot of OAuth 1.0 imp= lementations in trouble, due to oddities about normalization. So let's = take this a step further and tell the server what we're hashing in our signed content, but by repeating just the *keys* = to this content and not the content itself, since the keys will be shorter = in many cases and less redundant:

signed: [ "verb", "scheme+host+path", {"query= ": ["quux", "woz"]}, {"header": ["X= -Other-Header"]} ]

Note that this uses arrays, which is important because arrays preserve= order in JSON. Now we have a pretty programmatic way of telling the server= which bits we care about signing and what order we put them in, with norma= lizing those aspects. This makes us robust against stuff getting reordered and new headers or query paramet= ers being inserted (which often happens with various web frameworks). Of co= urse, after verifying a signature, an app would want to make sure that impo= rtant parameters were covered by that signature, but that's up to the app. Any decent library would mak= e the list available to the app easily enough for a quick check.=C2=A0

OK, so now we've got our hash and our note on what we hashed. Let&= #39;s put those into a JSON object:

{=C2=A0
hash:=C2=A0HJ23dfjoa32fasd23lajkds,
signed: [ "verb", "scheme+host+path", {"query= ": ["quux", "woz"]}, {"header": ["X= -Other-Header"]} ],
token_id:=C2=A0<public token value>
}

And we'll make our normal JWS header, use the above JSON object as= the bode, and sign it with JWS using the secret/key that we got up in the = token response:

eyheaderstufffooo.eybodystuffbaaar.signatureblob


[Side note: Maybe if you really wanted to you could also sign it using= the client secret and include the client id in the signed data, like OAuth= 1.0 does.]

And *now* we can send this over using any method comparable to those d= efined in RFC6750, since it's all a single, self-contained value.=C2=A0=

GET http://foo.bar/baz?quxx=3Dbob&woz=3Dwhynot HTTP/1.1
Accept: application/json
X-Other-Header: SomeHeaderValue
Authorization: SignedOAuth=C2=A0eyheaderstufffooo.eybodystuffbaaar.sig= natureblob


or:

GET http://foo.bar/baz?quxx=3Dbob&woz= =3Dwhynot&signed_access_token=3Deyheaderstufffooo.eybodystuffbaaar.= signatureblob=C2=A0HTTP/1.1
Accept: application/json
X-Other-Header: SomeHeaderValue


Note that in the both cases, the newly introduced header and query par= ameter are automatically excused from the signature calculation because the= y don't show up in the signed lists.=C2=A0


OK, so the RS gets this request, and what does it do? Easy:=C2=A0

First, check the signature on the token. This is self-contained and is= a quick JWS operation. [Side note: how does the RS get the private signing= /checking key from the AS? I don't care, and neither should you, becaus= e it's orthogonal to this part of the spec family.]

Second, the RS parses the body and reads the "signed" member= . This "signed" member tells the RS which parts of the original r= equest it needs to check. Even with extra parameters and bits you end up pu= lling only the parts that you need. And you know what order to smash them together, too, without doing any kind of sorting!=C2= =A0

Third, the RS calculates the hash of this string and compares it, lite= rally, to the "hash" parameter that was sent.=C2=A0

Fourth, the RS makes sure any "important" parameters and hea= ders and other bits are actually covered by the hash.



Anyway, I think this method is worlds simpler than what we've got = in http-mac right now and it goes back to solving a number of the use cases= that have been brought up, including my own of simply protecting an HTTP m= essage apart from tokens.


Couldn't we= have something middle-ground between bearer tokens "in the clear"= ; (RFC6750) and signing the request like http-mac or your proposal?

What I'd need is *just* a wa= y so that a "thing" passed from the Client to the PR couldn't= be reused with other PRs (should contain something that identifies the PR)= , and ideally couldn't also be "replayed" (let's give it = a validity period, maybe also a nonce).
Doesn't that nicely matches with JWT's &= quot;aud", "iat", "exp", "nbf" and possi= bly "jti" of JWT, as already used by jwt-bearer? Let's just u= se the client_id as "iss" (as in jwt-bearer) and the "access= token" as "sub", and sign that.
It's assumed that the AS already knows the p= ublic key of the Client so it can verify the signature; the access token re= sponse from the AS would probably include the signature algorithm that the = Client is expected to use, but that could also have been "negotiated&q= uot; before (just as with jwt-bearer, you have to know what the AS expects = you to use).
A compromised PR, despite knowing the access tok= en (unless the JWT is encrypted rather than just signed), couldn't acce= ss other resource servers as it couldn't
Just as with bearer tokens, it's assumed that PRs are reached through T= LS (if you need OAuth, it means you're accessing data of the End-User, = so you should use TLS anyway for privacy concerns). In the event there'= s an eavesdropper nevertheless, the "iat", "exp" and &q= uot;nbf" limit the reuse of the token, and "jti" (if used, a= nd used correctly) totally mitigates the risk of replay attacks.

The major r= emaining risk is a compromised client (and of course compromised AS). I don= 't think we can do much things about it though, apart from heavy monito= ring at the AS and blacklisting the Client whenever some bad use is detecte= d.

Remember I&= #39;m not a security guy though. Would that be too insecure? (I doubt it, e= verybody uses bearer tokens nowadays, and the approach is the same as with = jwt-bearer) Have I missed something?


--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--089e0153798a1e616504e9aacc4b-- From jricher@mitre.org Mon Oct 28 10:57:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5621E80B5 for ; Mon, 28 Oct 2013 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLkr8EETrYDF for ; Mon, 28 Oct 2013 10:57:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CE90E11E8294 for ; Mon, 28 Oct 2013 10:57:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2C0B21F06A6; Mon, 28 Oct 2013 13:57:03 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DE8251F0723; Mon, 28 Oct 2013 13:57:02 -0400 (EDT) Received: from [10.146.15.6] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 13:57:03 -0400 Message-ID: <526EA563.1060701@mitre.org> Date: Mon, 28 Oct 2013 13:56:51 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Thomas Broyer References: <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com> <526AAA2F.5020705@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020500060601040400040006" X-Originating-IP: [129.83.31.51] Cc: "" Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:57:36 -0000 --------------020500060601040400040006 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit What you suggest below is essentially what John Bradley proposed as a "holder of key" JWT a while ago. The main difference between the two approaches is that mine can also cover aspects of the HTTP request itself in the signature. I think you could do both of them together by simply making the "signed" and "hash" bits optionally empty, which would effectively give you the functionality you're after. -- Justin On 10/26/2013 04:34 PM, Thomas Broyer wrote: > > > On Sat, Oct 26, 2013 at 6:03 PM, Richer, Justin P. > wrote: > >> >> On our backlog is also support for "service accounts" (to use >> Google's terminology), so clients will likely need to do some >> crypto-related work. Asking them to do it for each and every >> request to sign the access token might not be that >> > >> > >> > I assume you mean signing the request or at least some request >> data. Just signing the access token won't help. >> >> I meant signing the access token + PR identifier/URI + some >> timestamp, at a minimum. >> I explained it better in my answer to Justin; something like >> jwt-bearer applied to access tokens. >> >> > > I suggested to the group that we try something like this a while > ago but it didn't get traction at the time. I never really wrote > down the whole process I had in mind, so here's a quick overview: > > > First, the client gets a token from the auth server using any > normal oauth mechanism (or any abnormal mechanism for that > matter), and the response looks something like this: > > { > token_type: signed, > access_token: > token_key: > alg: use HS256 for my example below but we could probably tweak this to > use asymmetric keys too> > expires_in: 3600 > … > } > > > Next, the client figures out the request it wants to make: > > GET http://foo.bar/baz?quxx=bob&woz=whynot HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > > > Treating this request as a structure, we've got a verb, a url > (with scheme, host, path, parameters), and some headers. We want > the client to be able to sign some subset of this with the > request, so let's say this client wants to sign the verb, > scheme+host+port+path, the parameters, and one of the headers. So > the way I see it we've got a couple options. First is to repeat > all the items to be signed within a JSON structure and use JWS. > This is messy and it ignores some of the best stuff about using > HTTP/REST these days. Second, we can combine, normalize, and hash > the signable items. With this approach and some sufficient > handwavium (because I don't really want to get into specifics of > serialization and normalization here), we get something like this > for a base string: > > GET > http://foo.bar/baz > quux=bob > woz=whynot > X-Other-Header=SomeHeaderValue > > which we can hash using a defined algorithm of the same bit size > as our signing algorithm. So say we're using HMAC 256, we get a > base64url encoded hash blob like this fake one I just made up: > HJ23dfjoa32fasd23lajkds > > So great, we've got a hash and we've got a set of data that was > hashed. So far we're in the same boat that got a lot of OAuth 1.0 > implementations in trouble, due to oddities about normalization. > So let's take this a step further and tell the server what we're > hashing in our signed content, but by repeating just the *keys* to > this content and not the content itself, since the keys will be > shorter in many cases and less redundant: > > signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, > {"header": ["X-Other-Header"]} ] > > Note that this uses arrays, which is important because arrays > preserve order in JSON. Now we have a pretty programmatic way of > telling the server which bits we care about signing and what order > we put them in, with normalizing those aspects. This makes us > robust against stuff getting reordered and new headers or query > parameters being inserted (which often happens with various web > frameworks). Of course, after verifying a signature, an app would > want to make sure that important parameters were covered by that > signature, but that's up to the app. Any decent library would make > the list available to the app easily enough for a quick check. > > OK, so now we've got our hash and our note on what we hashed. > Let's put those into a JSON object: > > { > hash: HJ23dfjoa32fasd23lajkds, > signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, > {"header": ["X-Other-Header"]} ], > token_id: > } > > And we'll make our normal JWS header, use the above JSON object as > the bode, and sign it with JWS using the secret/key that we got up > in the token response: > > eyheaderstufffooo.eybodystuffbaaar.signatureblob > > > [Side note: Maybe if you really wanted to you could also sign it > using the client secret and include the client id in the signed > data, like OAuth 1.0 does.] > > And *now* we can send this over using any method comparable to > those defined in RFC6750, since it's all a single, self-contained > value. > > GET http://foo.bar/baz?quxx=bob&woz=whynot HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > Authorization: > SignedOAuth eyheaderstufffooo.eybodystuffbaaar.signatureblob > > > or: > > GET > http://foo.bar/baz?quxx=bob&woz=whynot&signed_access_token=eyheaderstufffooo.eybodystuffbaaar.signatureblob HTTP/1.1 > Accept: application/json > X-Other-Header: SomeHeaderValue > > > Note that in the both cases, the newly introduced header and query > parameter are automatically excused from the signature calculation > because they don't show up in the signed lists. > > > OK, so the RS gets this request, and what does it do? Easy: > > First, check the signature on the token. This is self-contained > and is a quick JWS operation. [Side note: how does the RS get the > private signing/checking key from the AS? I don't care, and > neither should you, because it's orthogonal to this part of the > spec family.] > > Second, the RS parses the body and reads the "signed" member. This > "signed" member tells the RS which parts of the original request > it needs to check. Even with extra parameters and bits you end up > pulling only the parts that you need. And you know what order to > smash them together, too, without doing any kind of sorting! > > Third, the RS calculates the hash of this string and compares it, > literally, to the "hash" parameter that was sent. > > Fourth, the RS makes sure any "important" parameters and headers > and other bits are actually covered by the hash. > > > > Anyway, I think this method is worlds simpler than what we've got > in http-mac right now and it goes back to solving a number of the > use cases that have been brought up, including my own of simply > protecting an HTTP message apart from tokens. > > > Couldn't we have something middle-ground between bearer tokens "in the > clear" (RFC6750) and signing the request like http-mac or your proposal? > > What I'd need is *just* a way so that a "thing" passed from the Client > to the PR couldn't be reused with other PRs (should contain something > that identifies the PR), and ideally couldn't also be "replayed" > (let's give it a validity period, maybe also a nonce). > Doesn't that nicely matches with JWT's "aud", "iat", "exp", "nbf" and > possibly "jti" of JWT, as already used by jwt-bearer? Let's just use > the client_id as "iss" (as in jwt-bearer) and the "access token" as > "sub", and sign that. > It's assumed that the AS already knows the public key of the Client so > it can verify the signature; the access token response from the AS > would probably include the signature algorithm that the Client is > expected to use, but that could also have been "negotiated" before > (just as with jwt-bearer, you have to know what the AS expects you to > use). > A compromised PR, despite knowing the access token (unless the JWT is > encrypted rather than just signed), couldn't access other resource > servers as it couldn't > Just as with bearer tokens, it's assumed that PRs are reached through > TLS (if you need OAuth, it means you're accessing data of the > End-User, so you should use TLS anyway for privacy concerns). In the > event there's an eavesdropper nevertheless, the "iat", "exp" and "nbf" > limit the reuse of the token, and "jti" (if used, and used correctly) > totally mitigates the risk of replay attacks. > > The major remaining risk is a compromised client (and of course > compromised AS). I don't think we can do much things about it though, > apart from heavy monitoring at the AS and blacklisting the Client > whenever some bad use is detected. > > Remember I'm not a security guy though. Would that be too insecure? (I > doubt it, everybody uses bearer tokens nowadays, and the approach is > the same as with jwt-bearer) Have I missed something? > > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ --------------020500060601040400040006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit What you suggest below is essentially what John Bradley proposed as a "holder of key" JWT a while ago. The main difference between the two approaches is that mine can also cover aspects of the HTTP request itself in the signature. I think you could do both of them together by simply making the "signed" and "hash" bits optionally empty, which would effectively give you the functionality you're after.

 -- Justin

On 10/26/2013 04:34 PM, Thomas Broyer wrote:


On Sat, Oct 26, 2013 at 6:03 PM, Richer, Justin P. <jricher@mitre.org> wrote:

>> On our backlog is also support for "service accounts" (to use Google's terminology), so clients will likely need to do some crypto-related work. Asking them to do it for each and every request to sign the access token might not be that
>
>
> I assume you mean signing the request or at least some request data. Just signing the access token won't help.

I meant signing the access token + PR identifier/URI + some timestamp, at a minimum.
I explained it better in my answer to Justin; something like jwt-bearer applied to access tokens.



I suggested to the group that we try something like this a while ago but it didn't get traction at the time. I never really wrote down the whole process I had in mind, so here's a quick overview:


First, the client gets a token from the auth server using any normal oauth mechanism (or any abnormal mechanism for that matter), and the response looks something like this:

{ 
  token_type: signed,
  access_token: <public token value>
  token_key: <private token secret used for signing, maybe as a JWK?>
  alg: <JWS algorithm to use for signing requests to the RS, I'll use HS256 for my example below but we could probably tweak this to use asymmetric keys too>
  expires_in: 3600
  …
}


Next, the client figures out the request it wants to make:

Accept: application/json
X-Other-Header: SomeHeaderValue


Treating this request as a structure, we've got a verb, a url (with scheme, host, path, parameters), and some headers. We want the client to be able to sign some subset of this with the request, so let's say this client wants to sign the verb, scheme+host+port+path, the parameters, and one of the headers. So the way I see it we've got a couple options. First is to repeat all the items to be signed within a JSON structure and use JWS. This is messy and it ignores some of the best stuff about using HTTP/REST these days. Second, we can combine, normalize, and hash the signable items. With this approach and some sufficient handwavium (because I don't really want to get into specifics of serialization and normalization here), we get something like this for a base string:

GET
quux=bob
woz=whynot
X-Other-Header=SomeHeaderValue

which we can hash using a defined algorithm of the same bit size as our signing algorithm. So say we're using HMAC 256, we get a base64url encoded hash blob like this fake one I just made up: HJ23dfjoa32fasd23lajkds

So great, we've got a hash and we've got a set of data that was hashed. So far we're in the same boat that got a lot of OAuth 1.0 implementations in trouble, due to oddities about normalization. So let's take this a step further and tell the server what we're hashing in our signed content, but by repeating just the *keys* to this content and not the content itself, since the keys will be shorter in many cases and less redundant:

signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, {"header": ["X-Other-Header"]} ]

Note that this uses arrays, which is important because arrays preserve order in JSON. Now we have a pretty programmatic way of telling the server which bits we care about signing and what order we put them in, with normalizing those aspects. This makes us robust against stuff getting reordered and new headers or query parameters being inserted (which often happens with various web frameworks). Of course, after verifying a signature, an app would want to make sure that important parameters were covered by that signature, but that's up to the app. Any decent library would make the list available to the app easily enough for a quick check. 

OK, so now we've got our hash and our note on what we hashed. Let's put those into a JSON object:

{ 
hash: HJ23dfjoa32fasd23lajkds,
signed: [ "verb", "scheme+host+path", {"query": ["quux", "woz"]}, {"header": ["X-Other-Header"]} ],
token_id: <public token value>
}

And we'll make our normal JWS header, use the above JSON object as the bode, and sign it with JWS using the secret/key that we got up in the token response:

eyheaderstufffooo.eybodystuffbaaar.signatureblob


[Side note: Maybe if you really wanted to you could also sign it using the client secret and include the client id in the signed data, like OAuth 1.0 does.]

And *now* we can send this over using any method comparable to those defined in RFC6750, since it's all a single, self-contained value. 

Accept: application/json
X-Other-Header: SomeHeaderValue
Authorization: SignedOAuth eyheaderstufffooo.eybodystuffbaaar.signatureblob


or:

GET http://foo.bar/baz?quxx=bob&woz=whynot&signed_access_token=eyheaderstufffooo.eybodystuffbaaar.signatureblob HTTP/1.1
Accept: application/json
X-Other-Header: SomeHeaderValue


Note that in the both cases, the newly introduced header and query parameter are automatically excused from the signature calculation because they don't show up in the signed lists. 


OK, so the RS gets this request, and what does it do? Easy: 

First, check the signature on the token. This is self-contained and is a quick JWS operation. [Side note: how does the RS get the private signing/checking key from the AS? I don't care, and neither should you, because it's orthogonal to this part of the spec family.]

Second, the RS parses the body and reads the "signed" member. This "signed" member tells the RS which parts of the original request it needs to check. Even with extra parameters and bits you end up pulling only the parts that you need. And you know what order to smash them together, too, without doing any kind of sorting! 

Third, the RS calculates the hash of this string and compares it, literally, to the "hash" parameter that was sent. 

Fourth, the RS makes sure any "important" parameters and headers and other bits are actually covered by the hash.



Anyway, I think this method is worlds simpler than what we've got in http-mac right now and it goes back to solving a number of the use cases that have been brought up, including my own of simply protecting an HTTP message apart from tokens.


Couldn't we have something middle-ground between bearer tokens "in the clear" (RFC6750) and signing the request like http-mac or your proposal?

What I'd need is *just* a way so that a "thing" passed from the Client to the PR couldn't be reused with other PRs (should contain something that identifies the PR), and ideally couldn't also be "replayed" (let's give it a validity period, maybe also a nonce).
Doesn't that nicely matches with JWT's "aud", "iat", "exp", "nbf" and possibly "jti" of JWT, as already used by jwt-bearer? Let's just use the client_id as "iss" (as in jwt-bearer) and the "access token" as "sub", and sign that.
It's assumed that the AS already knows the public key of the Client so it can verify the signature; the access token response from the AS would probably include the signature algorithm that the Client is expected to use, but that could also have been "negotiated" before (just as with jwt-bearer, you have to know what the AS expects you to use).
A compromised PR, despite knowing the access token (unless the JWT is encrypted rather than just signed), couldn't access other resource servers as it couldn't
Just as with bearer tokens, it's assumed that PRs are reached through TLS (if you need OAuth, it means you're accessing data of the End-User, so you should use TLS anyway for privacy concerns). In the event there's an eavesdropper nevertheless, the "iat", "exp" and "nbf" limit the reuse of the token, and "jti" (if used, and used correctly) totally mitigates the risk of replay attacks.

The major remaining risk is a compromised client (and of course compromised AS). I don't think we can do much things about it though, apart from heavy monitoring at the AS and blacklisting the Client whenever some bad use is detected.

Remember I'm not a security guy though. Would that be too insecure? (I doubt it, everybody uses bearer tokens nowadays, and the approach is the same as with jwt-bearer) Have I missed something?


--
Thomas Broyer
/tɔ.ma.bʁwa.je/

--------------020500060601040400040006-- From dan@respectnetwork.net Wed Oct 30 09:24:33 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E97411E8174 for ; Wed, 30 Oct 2013 09:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjAhCbUXrEiX for ; Wed, 30 Oct 2013 09:24:27 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7751311E8253 for ; Wed, 30 Oct 2013 09:24:20 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tp5so2771997ieb.3 for ; Wed, 30 Oct 2013 09:24:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6XfTfZs4TeRK52UnU6YHUzzmldPgnb0N6PY/RGE9GZw=; b=CurjudIxe8ip5tmAbY9St++/VruLuyEblDAxiANFGjq+PmMUP4gfLQZvDgwBiQ+//h e5BBraHnxa8EpO9MdgVaI9cVSRCsXArVMEmBZ89rW/Y85+HdOt6V36FL67C3bWpl6edW bdapA56Nm8CVWSFme8+8/wMRYkCq6IB3CgQ4tFbtdsjC834FKo8m2Dga6tR7GaSxU1M+ g0snB5AEy+jXl2WfA3sbwUIh6SBEflXNEOZf50Ulpi2+RCpyFKqi8mxyIsN08JKLje58 7YIelNbOJBZRx5/1b6IyAjw670c9OxXYAoFOqs71EVx2xp3cZieMzKx3thW+v7JdNeFH 2jpQ== X-Gm-Message-State: ALoCoQlnXyUFxc34+c3RokMBZhwhgAqDwXFKSbekozfCPkOoIO/hqdoVEEpetkVkXTKb9QijcPwJ MIME-Version: 1.0 X-Received: by 10.42.211.4 with SMTP id gm4mr825902icb.80.1383150259584; Wed, 30 Oct 2013 09:24:19 -0700 (PDT) Received: by 10.64.226.131 with HTTP; Wed, 30 Oct 2013 09:24:19 -0700 (PDT) X-Originating-IP: [108.45.69.60] Date: Wed, 30 Oct 2013 12:24:19 -0400 Message-ID: From: Dan Blum To: oauth list Content-Type: multipart/alternative; boundary=20cf301cc53ee4d76504e9f7c316 Subject: [OAUTH-WG] OAuth assurance question on mobile devices and different flows X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 16:24:33 -0000 --20cf301cc53ee4d76504e9f7c316 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've enclosed some notes which were sent into the Internet Identity Workshop (IIW) on an OAuth session at IIW last week with Dick Hardt. Much of the session ended up deep-ending on OAuth/mobile assurance issue that I address in the following blog post: Managing OAuth Risks in Mobile Applications *Session Title: *OAuth - the good parts...Intro to OAuth by Dick Hardt Note: this session was combined with the session OAuth 2.0 Assurance by Dan Blum Moderated by Dick Hardt and Dan Blum *Summary:* Attendees of this session were primarily interested in sharing observations on OAuth best practices. After some discussion, a debate arose about best practices for securing the OAuth interaction with mobile clients. This debate wasn't resolved. *General Notes:* OAuth is a framework, not a protocol Many implementations still use OAuth 1, there was some discussion of this but no strong reason or justification to continue focusing on OAuth 1 was expressed at this meeting How do you build an API that lets people run apps that register people on the device, and what are the best practices? Major social networks (e.g. salesforce) are giving developers samples that are "like" what they are trying to do; are these best practices or just historical artifacts? *Secure OAuth use with mobile devices discussion / debate* (see Managing OAuth Risks in Mobile Applications ) I'd appreciate your thoughts on the issues. Comments on the blog post, or here, would be great. Best regards, Dam Blum --20cf301cc53ee4d76504e9f7c316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I've enclosed some notes which were sent into = the Internet Identity Workshop (IIW) on an OAuth session at IIW last week w= ith Dick Hardt. Much of the session ended up deep-ending on OAuth/mobile as= surance issue that I address in the following blog post:=A0


Session= Title: OAuth - the good parts...Intro to OAuth by Dick Hardt

=A0

N= ote: this session was combined with the session=A0OAuth 2.0 Assurance by Da= n Blum

=A0

Moderated by Dick Hardt and Dan Blum


Summary= :=A0Attendees of this session were primaril= y interested in sharing observations on OAuth best practices. After some di= scussion, a debate arose about best practices for securing the OAuth intera= ction with mobile clients. This debate wasn't resolved.

=A0

<= span lang=3D"EN-GB">General Notes:

=A0

OAuth is a framework, not a protocol

=A0

Many= implementations still use OAuth 1, there was some discussion of this but n= o strong reason or justification to continue focusing on OAuth 1 was expres= sed at this meeting

=A0

= How do you build an API that lets people run apps that= register people on the device, and=A0what are the best practices?= =A0

=A0

Major social networks (e.g. salesforce) are giving develop= ers samples that are "like" what they are trying to do; are these= best practices or just historical artifacts?

=A0

<= span lang=3D"EN-GB">Secure OAuth use with mobile devices discussion / debat= e


I'd appreciate your thoughts on the issue= s. Comments on the blog post, or here, would be great.


Best regards,
<= /div>
Dam Blum
--20cf301cc53ee4d76504e9f7c316-- From odonoghue@isoc.org Thu Oct 31 10:56:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DE821E8103 for ; Thu, 31 Oct 2013 10:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz+5wLASLfT6 for ; Thu, 31 Oct 2013 10:56:50 -0700 (PDT) Received: from smtp150.ord.emailsrvr.com (smtp150.ord.emailsrvr.com [173.203.6.150]) by ietfa.amsl.com (Postfix) with ESMTP id AFDAB11E823A for ; Thu, 31 Oct 2013 10:56:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 463523B040C; Thu, 31 Oct 2013 13:56:39 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp19.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id EA4DF3B071C; Thu, 31 Oct 2013 13:56:38 -0400 (EDT) Message-ID: <527299D6.8010407@isoc.org> Date: Thu, 31 Oct 2013 13:56:38 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: oauth-interop@elists.isoc.org, oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:56:55 -0000 Folks, As I announced earlier via these mailing lists, we will have a meeting to discuss strategy and plans for OAuth2.0 Interop testing in general and a possible OAuth 2.0 Interop Test Event in early 2014. This will be followed by an OpenID Connect meeting. These meetings have been scheduled in conjunction with 88 IETF as follows: Sunday, 3 November 2013 Plaza C Room, 2nd Floor 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) 1:55 - 2:05 pm PDT Beverage/snack/bio break 2:05 - 4:00 pm PST (OpenID Connect) I did establish a wiki to assist with the OAuth 2.0 Interop planning, but it was gently pointed out to me today that I never sent the link out. My sincere apologies for that oversight. The wiki is available via either of these links: https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home https://tid.isoc.org/confluence/x/JYA7 Regards, Karen From prateek.mishra@oracle.com Thu Oct 31 12:30:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261EF11E8239 for ; Thu, 31 Oct 2013 12:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bctKzu-n07LO for ; Thu, 31 Oct 2013 12:30:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BED9C11E824F for ; Thu, 31 Oct 2013 12:30:35 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9VJUV0u018710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Oct 2013 19:30:31 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9VJUUwu002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Oct 2013 19:30:30 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9VJUUUb002450; Thu, 31 Oct 2013 19:30:30 GMT Received: from [130.35.50.94] (/130.35.50.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Oct 2013 12:30:30 -0700 Message-ID: <5272AFD5.8040801@oracle.com> Date: Thu, 31 Oct 2013 12:30:29 -0700 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: odonoghue@isoc.org References: <527299D6.8010407@isoc.org> In-Reply-To: <527299D6.8010407@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth-interop@elists.isoc.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:30:52 -0000 Karen, I am planning to attend the meeting on Sunday. However, I have made my travel plans based on your previous announcement of 9/20 [quote] 2. Hold a oauth interop planning meeting in Vancouver in conjunction with IETF#88. This meeting is planned for: Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) [\quote] I am only going to arrive with certainty by 1pm, so I would suggest moving the meeting time back to reflect the previously announced time slot (or at least start at 1pm). - prateek > Folks, > > As I announced earlier via these mailing lists, we will have a meeting > to discuss strategy and plans for OAuth2.0 Interop testing in general > and a possible OAuth 2.0 Interop Test Event in early 2014. This will > be followed by an OpenID Connect meeting. These meetings have been > scheduled in conjunction with 88 IETF as follows: > > Sunday, 3 November 2013 > Plaza C Room, 2nd Floor > > 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) > 1:55 - 2:05 pm PDT Beverage/snack/bio break > 2:05 - 4:00 pm PST (OpenID Connect) > > I did establish a wiki to assist with the OAuth 2.0 Interop planning, > but it was gently pointed out to me today that I never sent the link > out. My sincere apologies for that oversight. The wiki is available > via either of these links: > https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home > > https://tid.isoc.org/confluence/x/JYA7 > > Regards, > Karen > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From derek@ihtfp.com Thu Oct 31 12:59:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE1F11E81D7 for ; Thu, 31 Oct 2013 12:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao++XcZX6rLv for ; Thu, 31 Oct 2013 12:59:06 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id C359911E8155 for ; Thu, 31 Oct 2013 12:59:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 698AC2602B5; Thu, 31 Oct 2013 15:59:05 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20165-07; Thu, 31 Oct 2013 15:59:03 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B09B22600B9; Thu, 31 Oct 2013 15:59:03 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 31 Oct 2013 15:59:03 -0400 Message-ID: In-Reply-To: <5272AFD5.8040801@oracle.com> References: <527299D6.8010407@isoc.org> <5272AFD5.8040801@oracle.com> Date: Thu, 31 Oct 2013 15:59:03 -0400 From: "Derek Atkins" To: "Prateek Mishra" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: oauth-interop@elists.isoc.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth-interop] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:59:07 -0000 I have conflicting meetings Sunday afternoon, so I may wind up jumping from meeting to meeting. At first I thought they only overlapped for a portion of the day, but now they overlap the whole day (my other meeting is from 12:15-3:25, apparently). I will figure it out. See you Sunday. -derek On Thu, October 31, 2013 3:30 pm, Prateek Mishra wrote: > Karen, > > I am planning to attend the meeting on Sunday. > > However, I have made my travel plans based on your previous announcement > of 9/20 > [quote] > 2. Hold a oauth interop planning meeting in Vancouver in conjunction > with IETF#88. > This meeting is planned for: > Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) > [\quote] > > I am only going to arrive with certainty by 1pm, so I would suggest > moving the meeting time back to reflect the previously announced time > slot (or at least start at 1pm). > > - prateek >> Folks, >> >> As I announced earlier via these mailing lists, we will have a meeting >> to discuss strategy and plans for OAuth2.0 Interop testing in general >> and a possible OAuth 2.0 Interop Test Event in early 2014. This will >> be followed by an OpenID Connect meeting. These meetings have been >> scheduled in conjunction with 88 IETF as follows: >> >> Sunday, 3 November 2013 >> Plaza C Room, 2nd Floor >> >> 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) >> 1:55 - 2:05 pm PDT Beverage/snack/bio break >> 2:05 - 4:00 pm PST (OpenID Connect) >> >> I did establish a wiki to assist with the OAuth 2.0 Interop planning, >> but it was gently pointed out to me today that I never sent the link >> out. My sincere apologies for that oversight. The wiki is available >> via either of these links: >> https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home >> >> https://tid.isoc.org/confluence/x/JYA7 >> >> Regards, >> Karen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > Oauth-interop mailing list > Oauth-interop@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/oauth-interop > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From derek@ihtfp.com Thu Oct 31 13:07:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A01411E815E for ; Thu, 31 Oct 2013 13:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWMlVcvkJg7W for ; Thu, 31 Oct 2013 13:07:05 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 944A411E81AC for ; Thu, 31 Oct 2013 13:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 057E32600B9 for ; Thu, 31 Oct 2013 16:07:03 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20385-04 for ; Thu, 31 Oct 2013 16:07:01 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 3B5DA2602B5; Thu, 31 Oct 2013 16:07:01 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 31 Oct 2013 16:07:01 -0400 Message-ID: Date: Thu, 31 Oct 2013 16:07:01 -0400 From: "Derek Atkins" To: oauth@ietf.org User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Subject: [OAUTH-WG] OAuth Agenda for IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:07:06 -0000 X-List-Received-Date: Thu, 31 Oct 2013 20:07:06 -0000 The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 hour session, and I expect we'll use most of it for discussion. For anyone who wants to make a status update on their draft please: 1) Get me slides before the meeting so I can post them online, 2) Try to keep yourself to a MAX of THREE (3) slides 3) Try to keep your comments to under 10 minutes (under 5 even better) Face to face time is best used for discussion, not presentation. :) Here is the proposed agenda. I'll post this on the website before the meeting on Monday. Please let me know if you have any additions before then. * Welcome & Agenda Bashing (10 minutes) * Draft Statuses (20 minutes) * Discussion (2 hours) - draft-bradley-stateless-oauth-client (30 min max) - Proof of Possession (30 min max) - Dynamic Client Registration (remainder, 60+min) * draft-richer-oauth-dyn-reg-core * draft-richer-oauth-dyn-reg-management * ... -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From odonoghue@isoc.org Thu Oct 31 13:23:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24FD11E81A0 for ; Thu, 31 Oct 2013 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6-kGJNAEq4v for ; Thu, 31 Oct 2013 13:22:59 -0700 (PDT) Received: from smtp117.dfw.emailsrvr.com (smtp117.dfw.emailsrvr.com [67.192.241.117]) by ietfa.amsl.com (Postfix) with ESMTP id AADFF11E8155 for ; Thu, 31 Oct 2013 13:22:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 01D8ED0903; Thu, 31 Oct 2013 16:22:58 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 9C07DD039A; Thu, 31 Oct 2013 16:22:58 -0400 (EDT) Message-ID: <5272BC21.3000508@isoc.org> Date: Thu, 31 Oct 2013 16:22:57 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: oauth-interop@elists.isoc.org, oauth@ietf.org References: <527299D6.8010407@isoc.org> In-Reply-To: <527299D6.8010407@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] CORRECTION: Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:23:03 -0000 Please note the revised schedule based on what I have previous announced. My apologies for the confusion. Sunday, 3 November 2013 Plaza C Room, 2nd Floor 12:00 - 1:55 pm PST (OpenID Connect) 1:55 - 2:05 pm PDT Beverage/snack/bio break 2:05 - 4:00 pm PST (OAuth 2.0 Interoperability) Regards, Karen On 10/31/13 1:56 PM, Karen O'Donoghue wrote: > Folks, > > As I announced earlier via these mailing lists, we will have a meeting > to discuss strategy and plans for OAuth2.0 Interop testing in general > and a possible OAuth 2.0 Interop Test Event in early 2014. This will > be followed by an OpenID Connect meeting. These meetings have been > scheduled in conjunction with 88 IETF as follows: > > Sunday, 3 November 2013 > Plaza C Room, 2nd Floor > > 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) > 1:55 - 2:05 pm PDT Beverage/snack/bio break > 2:05 - 4:00 pm PST (OpenID Connect) > > I did establish a wiki to assist with the OAuth 2.0 Interop planning, > but it was gently pointed out to me today that I never sent the link > out. My sincere apologies for that oversight. The wiki is available > via either of these links: > https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home > > https://tid.isoc.org/confluence/x/JYA7 > > Regards, > Karen > From odonoghue@isoc.org Thu Oct 31 13:26:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7411E8107 for ; Thu, 31 Oct 2013 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbVER6MbMHRp for ; Thu, 31 Oct 2013 13:26:00 -0700 (PDT) Received: from smtp117.dfw.emailsrvr.com (smtp117.dfw.emailsrvr.com [67.192.241.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB711E817E for ; Thu, 31 Oct 2013 13:26:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 7458DD0747; Thu, 31 Oct 2013 16:25:58 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 20B53D05B5; Thu, 31 Oct 2013 16:25:58 -0400 (EDT) Message-ID: <5272BCD5.3000706@isoc.org> Date: Thu, 31 Oct 2013 16:25:57 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: oauth-interop@elists.isoc.org, oauth@ietf.org References: <527299D6.8010407@isoc.org> <5272AFD5.8040801@oracle.com> In-Reply-To: <5272AFD5.8040801@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] [oauth-interop] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:26:04 -0000 Prateek, You are correct. Because I was arranging the room for both with a break in the middle, I forgot that I had previously announced the times. I will switch them back. Regards, Karen On 10/31/13 3:30 PM, Prateek Mishra wrote: > Karen, > > I am planning to attend the meeting on Sunday. > > However, I have made my travel plans based on your previous > announcement of 9/20 > [quote] > 2. Hold a oauth interop planning meeting in Vancouver in conjunction > with IETF#88. > This meeting is planned for: > Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) > [\quote] > > I am only going to arrive with certainty by 1pm, so I would suggest > moving the meeting time back to reflect the previously announced time > slot (or at least start at 1pm). > > - prateek >> Folks, >> >> As I announced earlier via these mailing lists, we will have a >> meeting to discuss strategy and plans for OAuth2.0 Interop testing in >> general and a possible OAuth 2.0 Interop Test Event in early 2014. >> This will be followed by an OpenID Connect meeting. These meetings >> have been scheduled in conjunction with 88 IETF as follows: >> >> Sunday, 3 November 2013 >> Plaza C Room, 2nd Floor >> >> 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) >> 1:55 - 2:05 pm PDT Beverage/snack/bio break >> 2:05 - 4:00 pm PST (OpenID Connect) >> >> I did establish a wiki to assist with the OAuth 2.0 Interop planning, >> but it was gently pointed out to me today that I never sent the link >> out. My sincere apologies for that oversight. The wiki is available >> via either of these links: >> https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home >> >> https://tid.isoc.org/confluence/x/JYA7 >> >> Regards, >> Karen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > Oauth-interop mailing list > Oauth-interop@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/oauth-interop From derek@ihtfp.com Thu Oct 31 13:35:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D64A11E8155 for ; Thu, 31 Oct 2013 13:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE3ZU2ywkeTQ for ; Thu, 31 Oct 2013 13:35:39 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 30EC121F9DF1 for ; Thu, 31 Oct 2013 13:35:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0FCBA26029B; Thu, 31 Oct 2013 16:35:37 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20517-04; Thu, 31 Oct 2013 16:35:35 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 07B432600B9; Thu, 31 Oct 2013 16:35:35 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 31 Oct 2013 16:35:35 -0400 Message-ID: <0f7de25b4bae9f4fd1b3df5de4d51834.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Thu, 31 Oct 2013 16:35:35 -0400 From: "Derek Atkins" To: "Derek Atkins" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Agenda for IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:35:55 -0000 Just a clarification: if you are making a status update slides are NOT required. The slide info was if you WERE planning to make slides. Sorry for any confusion. See you Monday! -derek On Thu, October 31, 2013 4:07 pm, Derek Atkins wrote: > The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 > hour session, and I expect we'll use most of it for discussion. For > anyone who wants to make a status update on their draft please: > > 1) Get me slides before the meeting so I can post them online, > 2) Try to keep yourself to a MAX of THREE (3) slides > 3) Try to keep your comments to under 10 minutes (under 5 even better) > > Face to face time is best used for discussion, not presentation. :) > > Here is the proposed agenda. I'll post this on the website before the > meeting on Monday. Please let me know if you have any additions before > then. > > > * Welcome & Agenda Bashing (10 minutes) > * Draft Statuses (20 minutes) > * Discussion (2 hours) > - draft-bradley-stateless-oauth-client (30 min max) > - Proof of Possession (30 min max) > - Dynamic Client Registration (remainder, 60+min) > * draft-richer-oauth-dyn-reg-core > * draft-richer-oauth-dyn-reg-management > * ... > > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From tonynad@microsoft.com Thu Oct 31 16:21:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D321E8130 for ; Thu, 31 Oct 2013 16:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwFur2cfyygR for ; Thu, 31 Oct 2013 16:21:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id C96CC21E8131 for ; Thu, 31 Oct 2013 16:21:05 -0700 (PDT) Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB191.namprd03.prod.outlook.com (10.242.36.143) with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 31 Oct 2013 23:21:03 +0000 Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.169]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.32]) with mapi id 15.00.0800.005; Thu, 31 Oct 2013 23:21:02 +0000 From: Anthony Nadalin To: Derek Atkins , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Agenda for IETF-88 Thread-Index: AQHO1nTZ3Rl7Fb32qUicLJ/G00VF6ZoPckPg Date: Thu, 31 Oct 2013 23:21:01 +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: [2001:4898:80e0:ed43::2] x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(377424004)(189002)(199002)(81816001)(85306002)(19580395003)(19580405001)(83322001)(80976001)(53806001)(74316001)(54356001)(83072001)(74876001)(74366001)(46102001)(56816003)(87266001)(77096001)(51856001)(74706001)(33646001)(81686001)(15975445006)(56776001)(77982001)(59766001)(79102001)(47446002)(74502001)(47736001)(31966008)(4396001)(81542001)(81342001)(15974865002)(74662001)(47976001)(49866001)(76576001)(76482001)(54316002)(50986001)(76786001)(80022001)(65816001)(76796001)(63696002)(69226001)(42262001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB191; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:; RD:InfoNoRecords; MX:3; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] OAuth Agenda for IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 23:21:10 -0000 The client registration is still open, so we need to continue our discussio= n that was started with the interim call -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= erek Atkins Sent: Thursday, October 31, 2013 1:07 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Agenda for IETF-88 The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 h= our session, and I expect we'll use most of it for discussion. For anyone = who wants to make a status update on their draft please: 1) Get me slides before the meeting so I can post them online, 2) Try to keep yourself to a MAX of THREE (3) slides 3) Try to keep your comments to under 10 minutes (under 5 even better) Face to face time is best used for discussion, not presentation. :) Here is the proposed agenda. I'll post this on the website before the meet= ing on Monday. Please let me know if you have any additions before then. * Welcome & Agenda Bashing (10 minutes) * Draft Statuses (20 minutes) * Discussion (2 hours) - draft-bradley-stateless-oauth-client (30 min max) - Proof of Possession (30 min max) - Dynamic Client Registration (remainder, 60+min) * draft-richer-oauth-dyn-reg-core * draft-richer-oauth-dyn-reg-management * ... -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From derek@ihtfp.com Thu Oct 31 16:44:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E521E813D for ; Thu, 31 Oct 2013 16:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.794 X-Spam-Level: X-Spam-Status: No, score=-101.794 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBPMXjBHexam for ; Thu, 31 Oct 2013 16:44:21 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id E406B21E813C for ; Thu, 31 Oct 2013 16:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 726C12602B5; Thu, 31 Oct 2013 19:44:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21157-10; Thu, 31 Oct 2013 19:44:05 -0400 (EDT) Received: from [192.168.248.236] (IHTFP-DHCP-236.IHTFP.ORG [192.168.248.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail2.ihtfp.org (Postfix) with ESMTPSA id 140C026029B; Thu, 31 Oct 2013 19:44:05 -0400 (EDT) To: "=?utf-8?B?QW50aG9ueSBOYWRhbGlu?=" , "=?utf-8?B?b2F1dGhAaWV0Zi5vcmc=?=" From: "=?utf-8?B?RGVyZWsgQXRraW5z?=" Date: Thu, 31 Oct 2013 19:44:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1383263040285" X-Virus-Scanned: Maia Mailguard 1.0.2a Message-Id: <20131031234406.726C12602B5@mail2.ihtfp.org> Subject: Re: [OAUTH-WG] =?utf-8?q?OAuth_Agenda_for_IETF-88?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 23:44:22 -0000 ------=_Part_0_1383263040285 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVzLCB0aGF0IGlzIHRoZSBtYWluIHRvcGljIG9mIGRpc2N1c3Npb24uCgotZGVyZWsKClNlbnQg ZnJvbSBteSBIVEMgc21hcnRwaG9uZQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAi QW50aG9ueSBOYWRhbGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPgpUbzogIkRlcmVrIEF0a2lu cyIgPGRlcmVrQGlodGZwLmNvbT4sICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPgpT dWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIEFnZW5kYSBmb3IgSUVURi04OApEYXRlOiBUaHUsIE9j dCAzMSwgMjAxMyA3OjIxIFBNCgoKVGhlIGNsaWVudCByZWdpc3RyYXRpb24gaXMgc3RpbGwgb3Bl biwgc28gd2UgbmVlZCB0byBjb250aW51ZSBvdXIgZGlzY3Vzc2lvbiB0aGF0IHdhcyBzdGFydGVk IHdpdGggdGhlIGludGVyaW0gY2FsbAoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTog b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEZXJlayBBdGtpbnMKU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMg MTowNyBQTQpUbzogb2F1dGhAaWV0Zi5vcmcKU3ViamVjdDogW09BVVRILVdHXSBPQXV0aCBBZ2Vu ZGEgZm9yIElFVEYtODgKClRoZSBJRVRGIGlzIG5leHQgd2VlaywgYW5kIE9BdXRoIG1lZXRzIE1v bmRheSBBZnRlcm5vb24uICBXZSBoYXZlIGEgMi0xLzIgaG91ciBzZXNzaW9uLCBhbmQgSSBleHBl Y3Qgd2UnbGwgdXNlIG1vc3Qgb2YgaXQgZm9yIGRpc2N1c3Npb24uICBGb3IgYW55b25lIHdobyB3 YW50cyB0byBtYWtlIGEgc3RhdHVzIHVwZGF0ZSBvbiB0aGVpciBkcmFmdCBwbGVhc2U6CgoxKSBH ZXQgbWUgc2xpZGVzIGJlZm9yZSB0aGUgbWVldGluZyBzbyBJIGNhbiBwb3N0IHRoZW0gb25saW5l LAoyKSBUcnkgdG8ga2VlcCB5b3Vyc2VsZiB0byBhIE1BWCBvZiBUSFJFRSAoMykgc2xpZGVzCjMp IFRyeSB0byBrZWVwIHlvdXIgY29tbWVudHMgdG8gdW5kZXIgMTAgbWludXRlcyAodW5kZXIgNSBl dmVuIGJldHRlcikKCkZhY2UgdG8gZmFjZSB0aW1lIGlzIGJlc3QgdXNlZCBmb3IgZGlzY3Vzc2lv biwgbm90IHByZXNlbnRhdGlvbi4gIDopCgpIZXJlIGlzIHRoZSBwcm9wb3NlZCBhZ2VuZGEuICBJ J2xsIHBvc3QgdGhpcyBvbiB0aGUgd2Vic2l0ZSBiZWZvcmUgdGhlIG1lZXRpbmcgb24gTW9uZGF5 LiAgUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBhZGRpdGlvbnMgYmVmb3JlIHRo ZW4uCgoKKiBXZWxjb21lICYgQWdlbmRhIEJhc2hpbmcgKDEwIG1pbnV0ZXMpCiogRHJhZnQgU3Rh dHVzZXMgKDIwIG1pbnV0ZXMpCiogRGlzY3Vzc2lvbiAoMiBob3VycykKICAtIGRyYWZ0LWJyYWRs ZXktc3RhdGVsZXNzLW9hdXRoLWNsaWVudCAoMzAgbWluIG1heCkKICAtIFByb29mIG9mIFBvc3Nl c3Npb24gKDMwIG1pbiBtYXgpCiAgLSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gKHJlbWFp bmRlciwgNjArbWluKQogICAgKiBkcmFmdC1yaWNoZXItb2F1dGgtZHluLXJlZy1jb3JlCiAgICAq IGRyYWZ0LXJpY2hlci1vYXV0aC1keW4tcmVnLW1hbmFnZW1lbnQKICAgICogLi4uCgoKLWRlcmVr CgotLSAKICAgICAgIERlcmVrIEF0a2lucyAgICAgICAgICAgICAgICAgNjE3LTYyMy0zNzQ1CiAg ICAgICBkZXJla0BpaHRmcC5jb20gICAgICAgICAgICAgd3d3LmlodGZwLmNvbQogICAgICAgQ29t cHV0ZXIgYW5kIEludGVybmV0IFNlY3VyaXR5IENvbnN1bHRhbnQKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9BdXRoIG1haWxpbmcgbGlzdApPQXV0aEBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCg== ------=_Part_0_1383263040285 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPlllcywgdGhhdCBpcyB0aGUgbWFpbiB0 b3BpYyBvZiBkaXNjdXNzaW9uLjxicj48YnI+LWRlcmVrPGJyPjxicj5TZW50IGZyb20gbXkgSFRD IHNtYXJ0cGhvbmU8YnI+PGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206 ICZxdW90O0FudGhvbnkgTmFkYWxpbiZxdW90OyAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0 Ozxicj5UbzogJnF1b3Q7RGVyZWsgQXRraW5zJnF1b3Q7ICZsdDtkZXJla0BpaHRmcC5jb20mZ3Q7 LCAmcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPlN1 YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggQWdlbmRhIGZvciBJRVRGLTg4PGJyPkRhdGU6IFRodSwg T2N0IDMxLCAyMDEzIDc6MjEgUE08YnI+PGJyPjwvc3Bhbj48YnI+VGhlIGNsaWVudCByZWdpc3Ry YXRpb24gaXMgc3RpbGwgb3Blbiwgc28gd2UgbmVlZCB0byBjb250aW51ZSBvdXIgZGlzY3Vzc2lv biB0aGF0IHdhcyBzdGFydGVkIHdpdGggdGhlIGludGVyaW0gY2FsbDxicj48YnI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEZXJlayBBdGtpbnM8YnI+U2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMgMTowNyBQTTxicj5Ubzogb2F1dGhAaWV0Zi5v cmc8YnI+U3ViamVjdDogW09BVVRILVdHXSBPQXV0aCBBZ2VuZGEgZm9yIElFVEYtODg8YnI+PGJy PlRoZSBJRVRGIGlzIG5leHQgd2VlaywgYW5kIE9BdXRoIG1lZXRzIE1vbmRheSBBZnRlcm5vb24u ICZuYnNwO1dlIGhhdmUgYSAyLTEvMiBob3VyIHNlc3Npb24sIGFuZCBJIGV4cGVjdCB3ZSYjMzk7 bGwgdXNlIG1vc3Qgb2YgaXQgZm9yIGRpc2N1c3Npb24uICZuYnNwO0ZvciBhbnlvbmUgd2hvIHdh bnRzIHRvIG1ha2UgYSBzdGF0dXMgdXBkYXRlIG9uIHRoZWlyIGRyYWZ0IHBsZWFzZTo8YnI+PGJy PjEpIEdldCBtZSBzbGlkZXMgYmVmb3JlIHRoZSBtZWV0aW5nIHNvIEkgY2FuIHBvc3QgdGhlbSBv bmxpbmUsPGJyPjIpIFRyeSB0byBrZWVwIHlvdXJzZWxmIHRvIGEgTUFYIG9mIFRIUkVFICgzKSBz bGlkZXM8YnI+MykgVHJ5IHRvIGtlZXAgeW91ciBjb21tZW50cyB0byB1bmRlciAxMCBtaW51dGVz ICh1bmRlciA1IGV2ZW4gYmV0dGVyKTxicj48YnI+RmFjZSB0byBmYWNlIHRpbWUgaXMgYmVzdCB1 c2VkIGZvciBkaXNjdXNzaW9uLCBub3QgcHJlc2VudGF0aW9uLiAmbmJzcDs6KTxicj48YnI+SGVy ZSBpcyB0aGUgcHJvcG9zZWQgYWdlbmRhLiAmbmJzcDtJJiMzOTtsbCBwb3N0IHRoaXMgb24gdGhl IHdlYnNpdGUgYmVmb3JlIHRoZSBtZWV0aW5nIG9uIE1vbmRheS4gJm5ic3A7UGxlYXNlIGxldCBt ZSBrbm93IGlmIHlvdSBoYXZlIGFueSBhZGRpdGlvbnMgYmVmb3JlIHRoZW4uPGJyPjxicj48YnI+ KiBXZWxjb21lICZhbXA7IEFnZW5kYSBCYXNoaW5nICgxMCBtaW51dGVzKTxicj4qIERyYWZ0IFN0 YXR1c2VzICgyMCBtaW51dGVzKTxicj4qIERpc2N1c3Npb24gKDIgaG91cnMpPGJyPiAmbmJzcDst IGRyYWZ0LWJyYWRsZXktc3RhdGVsZXNzLW9hdXRoLWNsaWVudCAoMzAgbWluIG1heCk8YnI+ICZu YnNwOy0gUHJvb2Ygb2YgUG9zc2Vzc2lvbiAoMzAgbWluIG1heCk8YnI+ICZuYnNwOy0gRHluYW1p YyBDbGllbnQgUmVnaXN0cmF0aW9uIChyZW1haW5kZXIsIDYwK21pbik8YnI+ICZuYnNwOyAmbmJz cDsqIGRyYWZ0LXJpY2hlci1vYXV0aC1keW4tcmVnLWNvcmU8YnI+ICZuYnNwOyAmbmJzcDsqIGRy YWZ0LXJpY2hlci1vYXV0aC1keW4tcmVnLW1hbmFnZW1lbnQ8YnI+ICZuYnNwOyAmbmJzcDsqIC4u Ljxicj48YnI+PGJyPi1kZXJlazxicj48YnI+LS0gPGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBE ZXJlayBBdGtpbnMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA2MTctNjIzLTM3NDU8YnI+ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlcmVrQGlo dGZwLmNvbSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3d3cuaWh0 ZnAuY29tPGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb21wdXRlciBhbmQgSW50ZXJuZXQgU2Vj dXJpdHkgQ29uc3VsdGFudDxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPk9BdXRoQGlldGYub3JnPGJy Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+ ------=_Part_0_1383263040285-- From tonynad@microsoft.com Thu Oct 31 22:48:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAD11E8246 for ; Thu, 31 Oct 2013 22:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmfA0NyAVTGn for ; Thu, 31 Oct 2013 22:48:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id BB3D811E82DD for ; Thu, 31 Oct 2013 22:48:10 -0700 (PDT) Received: from BLUPR03MB184.namprd03.prod.outlook.com (10.255.212.156) by BLUPR03MB184.namprd03.prod.outlook.com (10.255.212.156) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 1 Nov 2013 05:48:04 +0000 Received: from BLUPR03MB184.namprd03.prod.outlook.com ([169.254.1.199]) by BLUPR03MB184.namprd03.prod.outlook.com ([169.254.1.199]) with mapi id 15.00.0785.001; Fri, 1 Nov 2013 05:48:04 +0000 From: Anthony Nadalin To: Derek Atkins , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Agenda for IETF-88 Thread-Index: AQHO1nTZ3Rl7Fb32qUicLJ/G00VF6ZoP3tGA Date: Fri, 1 Nov 2013 05:48:03 +0000 Message-ID: <7837710edb6a43e0bb098435dd1c9f51@BLUPR03MB184.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(377424004)(199002)(189002)(81542001)(19580395003)(15974865002)(56776001)(76482001)(54316002)(33646001)(81342001)(85306002)(15975445006)(47446002)(47976001)(50986001)(63696002)(49866001)(47736001)(53806001)(77096001)(54356001)(77982001)(59766001)(81686001)(81816001)(74876001)(19580405001)(74366001)(74662001)(76786001)(69226001)(76796001)(66066001)(56816003)(83322001)(4396001)(74706001)(79102001)(74502001)(74316001)(85806002)(80022001)(76576001)(51856001)(83072001)(80976001)(65816001)(46102001)(31966008)(87266001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB184; H:BLUPR03MB184.namprd03.prod.outlook.com; CLIP:50.46.126.7; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [OAUTH-WG] OAuth Agenda for IETF-88 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 05:48:16 -0000 Would like 10 min to discuss ActAs draft -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= erek Atkins Sent: Thursday, October 31, 2013 1:07 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Agenda for IETF-88 The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 h= our session, and I expect we'll use most of it for discussion. For anyone = who wants to make a status update on their draft please: 1) Get me slides before the meeting so I can post them online, 2) Try to keep yourself to a MAX of THREE (3) slides 3) Try to keep your comments to under 10 minutes (under 5 even better) Face to face time is best used for discussion, not presentation. :) Here is the proposed agenda. I'll post this on the website before the meet= ing on Monday. Please let me know if you have any additions before then. * Welcome & Agenda Bashing (10 minutes) * Draft Statuses (20 minutes) * Discussion (2 hours) - draft-bradley-stateless-oauth-client (30 min max) - Proof of Possession (30 min max) - Dynamic Client Registration (remainder, 60+min) * draft-richer-oauth-dyn-reg-core * draft-richer-oauth-dyn-reg-management * ... -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth