Re: [jose] OAUTH and implicit key identifiers

Mike Jones <Michael.Jones@microsoft.com> Fri, 19 April 2013 17:17 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6068E21F9617 for <jose@ietfa.amsl.com>; Fri, 19 Apr 2013 10:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level:
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, 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 2G+9NWX-f1EZ for <jose@ietfa.amsl.com>; Fri, 19 Apr 2013 10:17:32 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6721F9616 for <jose@ietf.org>; Fri, 19 Apr 2013 10:17:31 -0700 (PDT)
Received: from BY2FFO11FD020.protection.gbl (10.1.15.201) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 19 Apr 2013 17:12:52 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 19 Apr 2013 17:12:52 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Fri, 19 Apr 2013 17:11:51 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>
Thread-Topic: [jose] OAUTH and implicit key identifiers
Thread-Index: Ac48fneRecweZdqnT5+h9BcteEyq3AAIL/KQAAehAIAAGFtyoA==
Date: Fri, 19 Apr 2013 17:11:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367678E1D@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367670B65@TK5EX14MBXC284.redmond.corp.microsoft.com> <003601ce3cbd$bbe7cfe0$33b76fa0$@augustcellars.com>
In-Reply-To: <003601ce3cbd$bbe7cfe0$33b76fa0$@augustcellars.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_4E1F6AAD24975D4BA5B168042967394367678E1DTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(44976003)(6806003)(77982001)(51856001)(76482001)(54356001)(63696002)(56816002)(56776001)(54316002)(16406001)(59766001)(55846006)(46102001)(79102001)(16297215002)(15395725003)(53806001)(512954001)(15202345002)(16236675002)(4396001)(564824004)(49866001)(47736001)(47976001)(50986001)(47446002)(66066001)(20776003)(69226001)(33656001)(81542001)(74502001)(31966008)(81342001)(71186001)(74662001)(65816001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 08213D42D3
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] OAUTH and implicit key identifiers
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 17:17:34 -0000

Sure.  One use case that's fully specified and has been demonstrated to produce interoperable implementations is the OpenID Connect use case.  You can read the key management instructions for that use case at http://openid.net/specs/openid-connect-messages-1_0.html#sigenc.  Note that this uses discovery to determine the algorithms supported by the server using the discovery fields at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata and uses client registration http://openid.net/specs/openid-connect-registration-1_0.html (which is based on the OAuth Dynamic Client Registration spec) to exchange algorithm and key information.

I know that Dick Hardt has a different key management scheme that's used in the British Columbia Government identity system.  Maybe he would like to describe that as well.

I'm sure that the Mozilla Persona system has to have one too.  (I think it's a simple one based on domain names, but I'm not an expert here.)

                                                                Cheers,
                                                                -- Mike

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Thursday, April 18, 2013 10:21 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] OAUTH and implicit key identifiers

Ok - I have read through this document - my gut feeling is that I understood enough about OAuth to comment I would create a massive mail message of comments.

This does not make it clear to me how this would work.  After several reads of the document my best guess is that one says - If you go digging through the content of the message then you might find something that will give you a hint about what key to use when combined with your database.

Do you have any better cases that make it clear how this is supposed to work?

Jim


From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, April 18, 2013 6:56 PM
To: Jim Schaad
Cc: jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: [jose] OAUTH and implicit key identifiers


In http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09, see the definition of "jwks_uri", which enables the client's JWK Set document to be communicated to the OAuth server out of band from the JWTs (and JOSE objects underlying them) later used.  Also see "token_endpoint_auth_method" and especially the "client_secret_jwt" and "private_key_jwt" authentication methods.

                                                                -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, April 18, 2013 2:49 PM
To: Mike Jones
Cc: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] OAUTH and implicit key identifiers

Mike,

I have tried to go through the OAuth documents in order to find where and how they have implicit key identifiers set up for tokens.   I was unable to find this.  Can you please give me a concrete pointer to where this text is?

Jim