[Openid-specs-native-apps] AC/DC spec review

[George Fletcher]

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?

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.

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?

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?

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?

6. I'm assuming the returned acdc JWT is signed though I don't see that specified in the spec.

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.

8. Recommend adding non-normative examples:)

Thanks,
George

--
George Fletcher
Chief Architect, Identity Services
AOL Inc.