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

[George Fletcher]

More comments inline :)

On 6/16/15 11:28 AM, John Bradley wrote:
>
>
> 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.
I think this makes sense though to me it begs the question as to whether 
the returned access_token also has the acdc scope or just the refresh 
token. Meaning should the AS generate the access_token with all the 
requested scopes except the acdc scope as that scope really only applies 
to the refresh_token. This isn't really default OAuth2 behavior so 
should be described.

I agree that we also need to define what additional parameters are 
required when using the refresh_token flow to get an acdc token.

Note: we do something kind of similar with a "web_session" scope that we 
use to bootstrap from an OAuth2 flow into a full web browser based 
session seamlessly (device to browser SSO). I can send that spec to this 
list if helpful.
>
>> 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
Ok, makes sense.
>>
>> 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?
Basically yes. I wrote an OAuth2 based "federation" spec for a partner a 
few years ago. The basics are that the client talks to AS1 and gets in 
response an access_token that is a JWS. This JWS is passed to a RS 
protected by AS2. The RS takes the access_token and and passes it to AS2 
for validation. AS2 validates the signature on the JWS and then looks at 
the "sub" value to see if the user is already known at AS2. If the user 
is NOT known at AS2, then AS2 makes a request to AS1 requesting user 
information and from that creates a user in AS2 and completes the flow.

This may be outside the scope of ACDC but it seems like a flow that will 
be very necessary in this context of "federation".
>>
>> 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.
Actually, I was thinking more about client goes to AS1 with a scope of 
"openid email profile imap acdc" and gets back a refresh_token and 
access_token for those scopes. The client can then use the refresh_token 
flow to get an acdc code for AS2. Basically allowing the client to 
combine the acdc scope with other scopes.

However, the downstream chaining concept is good as well :)
>
>>
>> 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.
Ok, I was assuming the sid was the value from the device. So this is a 
level of indirection such that the "sid" is defined by the AS and can be 
anything which represents how the AS "identifies" that device? Probably 
worth explaining that in the spec.
>>
>> 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.
I agree that we should require pkce... Just thinking that this use case 
of client1 being able to get an acdc code from AS1 that it will pass to 
client2 and client2 will request the access_token via the acdc code 
could be pretty common.
>>
>> 8. Recommend adding non-normative examples:)
>
> Right.
>>
>> Thanks,
>> George
>>
>> --
>> George Fletcher
>> Chief Architect, Identity Services
>> AOL Inc.
>
>
>
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps

-- 
<http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20150617/f0dd928d/attachment.html>