On 5/17/11 1:10 PM, "Jian Cai" <[email protected]> wrote: On Tue, May 17, 2011 at 10:57 AM, Chuck Mortimore <[email protected]> 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 protected] <http://[email protected]> > 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 protected] <http://[email protected]> > Date: Wed, Apr 6, 2011 at 12:43 PM Subject: Native JWT support in Google App Engine To: [email protected] <http://[email protected]> 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
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
