[Openid-specs-native-apps] Fwd: Forward of moderated message

[John Bradley]

Hi George,

Thanks for the review.  

Inline

> On Jun 15, 2015, at 6:27 PM, openid-specs-native-apps-bounces at lists.openid.net <mailto:openid-specs-native-apps-bounces at lists.openid.net> wrote:
> 
> 
> From: George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>>
> Subject: AC/DC spec review
> Date: June 12, 2015 at 7:36:02 PM GMT-3
> To: "openid-specs-native-apps at lists.openid.net <mailto:openid-specs-native-apps at lists.openid.net>" <openid-specs-native-apps at lists.openid.net <mailto:openid-specs-native-apps at lists.openid.net>>
> 
> 
> I read through the spec on the plane ride home and have a few comments/questions.
> 
> 1. Section three mentions two ways to get an acdc code value. The second is via the token endpoint and involves an acdc scope. This scope value is not described and I'm wondering how this works. Do I get an acdc token via a refresh token grant with the acdc scope? If so, that flow doesn't seem to be described in the spec. Maybe it's planned to be added later?
> 
I was thinking that you would be using the refresh token grant and including a audience parameter and additional scope called acdc. This also needs to accept code_challange.

Perhaps having a token type requested parameter might be cleaner.   I am looking for ideas.

> 2. Once I have an acdc code token and I present it to the token endpoint of AS2, are there any additional parameters required? If there are no changes to the stand oauth2 code flow then I'd recommend stating that and adding a non-normative example.

Should be no changes other than including the code_verifyer from PKCE
> 
> 3. What is the expected behavior if at AS2 the "sub" field if the acdc code token is not understood. Is there any desire to do any sort of implicit user binding?

Implicit user binding?  Are you asking if the downstream AS should create the user?
> 
> 4. Is it possible (or intended) for the client to be able to do a normal browser based authorization flow including a scope of "acdc" and then later use the refresh token flow to get the acdc code value?

So if AS2 gives the client a refresh token, should the client be able to ask for a ACDC for another AS?   I don’t see a reason to exclude that if AS2 has a policy to allow it.

> 
> 5. In a normal native client invocation using the code flow, how is the server expected to get the "sid" value to put into the acdc code token? Is that intentionally left out of scope?

The sid is created by the AS.  Without some sort of TA on the device or using a cookie/local storage, it would need to prompt for a device ID.   Failing that each app would probably look like a separate session.
> 
> 6. I'm assuming the returned acdc JWT is signed though I don't see that specified in the spec.

Yes, I will add it.
> 
> 7. Is there any desire to support client 1 requesting the acdc code token and passing it to client 2? Is so, how is the "azp" value set to the client ID of client 2? Given the PCKE requirement this isn't possible unless client 1 passes the code_verifier to client 2.

I don’t think we should allow acdc without a pkce proof.  Doing this with plain bearer tokens could go quite wrong.

> 
> 8. Recommend adding non-normative examples:)

Right.
> 
> Thanks,
> George
> 
> --
> George Fletcher
> Chief Architect, Identity Services
> AOL Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20150616/7759821a/attachment-0003.html>