Subject: Re: [woes] Preview of Google API support for OAuth2 assertion flow
From: Chuck Mortimore <[email-masked]>
To: Jian Cai <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 17 May 2011 18:59:53 -0700
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>

On 5/17/11 1:10 PM, "Jian Cai" <[email-masked]> wrote:

On Tue, May 17, 2011 at 10:57 AM, Chuck Mortimore <[email-masked]> wrote:
Hi Eric - we're currently implementing these flows, and I'm working on a draft to capture both these flows and I'm hoping to have some community review in person at the interim meeting on Monday - will you be there?

Also, a few questions on what you've implemented

 *   You don't seem to ever have a "prn" defined in your JWT - what was the reasoning behind this?

We haven't implemented user impersonation, for the JWT without 'prn', we default think app is asking permission on behalf of itself.

For consistency, we were thinking that the app would make itself the principal.

How does your app identity relate your your oauth client_id's?

 *
 *   The URL for the for the keys are explicitly registered on your side, and never carried in a "jku" or "x5u" field...is that correct?    (Note that we're starting with statically configured PEM certs )

right, we need a way to associate public key URL to the requesting app('issuer' in JWT)

 *
 *   scope - my current thinking is that since this is the token endpoint, authorization has already occurred.  It seems like scope should be optional and only used to downgrade capabilities.   What is google's thinking?

Google has one single token endpoint for all APIs, so in current implementation:
audience(aud) is the token endpoint, for Google case, it's always something like https://www.google.com/account/o/oauth2/TokenEndpoint
scope specifies which API is being requested, for example https://docs.google.com/feed
what about those values in your case?

We basically have one token endpoint ( there can be multiple hosts, but we sort that out )

Scope for us will be a combination of APIs and capabilities.   My questions is - is your authorization already defined out of band?  If so, is scope can never be expanded via this parameter for you correct?

 *
 *
 *   In your client authentication flow, you never declare the assertion type - was this intentionally omitted?

Currently we only have plan to support JWT based assertion for webserver flow+assertion, but if community comes up with a spec that can support multiple assertion types, I'd also like to add it to our implementation, I don't think we have such a standard now, right?

I just meant a type attribute in your actual protocol flow.   Early drafts as well as WRAP called out the type, and I think this is important ( for instance we'll support SAML and JWT )

-cmort

 *

-cmort

On 5/16/11 6:12 PM, "Eric Sachs" <[email-masked] <http://[email-masked]> > wrote:

Last month we announced support for Google App Engine apps to create signed JWTs, such as for use in an OAuth2 assertion flows.  We are now providing a preview of the ability for developers to make API calls to Google using OAuth2 assertions in JWT format.  The documentation (including pointers to sample apps and their source code) is at:
https://sites.google.com/site/oauthgoog/Home/google-oauth2-assertion-flow
As we discussed at the InternetIdentityWorkshop, we are interested in working with vendors in interop using these techniques.

---------- Forwarded message ----------
From: Eric Sachs <[email-masked] <http://[email-masked]> >
Date: Wed, Apr 6, 2011 at 12:43 PM
Subject: Native JWT support in Google App Engine
To: [email-masked] <http://[email-masked]>

Google has just added native support for JWT to Google App Engine.  Here is the documentation:
https://sites.google.com/site/oauthgoog/authenticate-google-app-engine-app
Our hope is to work with other players in the cloud computing space to improve some elements of cloud security by using PKI, JWT & OAuth2 for interop between our systems.

Based on past industry discussion, we wroteup a description of some of the general interop use-cases:
https://sites.google.com/site/oauthgoog/robotaccounts/cloudtoonpremise
https://sites.google.com/site/oauthgoog/robotaccounts/onpremisetocloud
While this new feature in Google App Engine is a significant step for Google, we realize there is more to do on our side such as adding support for JWT assertions in our recently announced OAuth2 support for Google APIs <http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html> .  However we would prefer to get feedback from this group on a standard approach, including around key rotation/management.

Eric Sachs
Senior Product Manager, Internet Identity
Google