[Openid-specs-native-apps] Please review specs
Paul Madsen
paul.madsen at gmail.com
Thu Feb 13 19:16:04 UTC 2014
returning to NAPPS, why would the TA need a structured scope on its
request? Could it not simply designate the relevant app in the scope and
the AS interpret that to mean 'return id_token'?
Or are you trying to avoid the AS having that information?
paul
On 2/13/14, 1:24 PM, John Bradley wrote:
> In case of Google they are passing parameters as part of scopes by
> using ":" as a delimiter.
>
> So audience:server:client_id:paul123 takes paul123 as the value of the
> client_id for the server audience in the id_token as I understand it.
>
> Scope is a bit of a blunt tool so I have seen people base64url encode
> json as scope values.
>
> Clearly that messes with any AS that treats scopes as simple strings
> to do an exact string match on.
>
> In Connect we wanted to pass finer grained information to the AS so
> that individual claims could be requested and parameters could be sent
> in the claim request.
> We looked at overloading scope but that was going to mess too much
> with existing deployments.
> We settled on adding some additional paramaters to the authorization
> request such as the claims parameter that is UTF-8 encoded JSON.
>
> If we were making a request to the authorization endpoint we could
> include claims with a value of
> {
> "id_token":
> {
> "aud": {"values": ["paul123"] }
> }
> }
>
> [Note aud is an array but typically only contains a single value.]
>
> However the claims parameter is not currently defined for the token
> endpoint. That is not to say that we couldn't do that as an
> extension to downscope to specific claims in the id_token and
> user_info endpoint.
>
> John B.
>
> On Feb 13, 2014, at 2:17 PM, Paul Madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> can you give an example of what this sort of structured scope would
>> look like?
>>
>> On 2/13/14, 12:09 PM, John Bradley wrote:
>>> The example that's been deployed is Google. They are using
>>> structured scopes to request id_tokens for registered audiences.
>>>
>>> So each native app can have some number of other client_id that it
>>> can request id_tokens for via the scope value.
>>>
>>> Connect is silent about how you make that request. Connect defines
>>> that the returned id_token must have the client that requested the
>>> token as the "azp" in the token with the target as the "aud".
>>>
>>> the refresh token call is unchanged, , however the format of the
>>> scope to request a id_token with a different audience needs to be
>>> defined.
>>>
>>> The format of the id_token itself is defined, though some 3rd
>>> parties may want additional claims (like role or consent) in the
>>> id_token beyond just the subject. That would need to preconfigured
>>> as a start.
>>>
>>> The assertion exchange is specified in OAuth:
>>> http://tools.ietf.org/html/draft-ietf-oauth-assertions and
>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
>>>
>>>
>>> Using AppInfo the aud for the third party would be configured along
>>> with the token endpoint etc so there would not be a requirement to
>>> define a structured scope.
>>>
>>> John B.
>>>
>>>
>>> On Feb 13, 2014, at 1:32 PM, Paul Madsen <paul.madsen at gmail.com
>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>
>>>> thanks John, so the Token EP would know to return an (appropriately
>>>> targetted) id_token rather than an access token based on the scope?
>>>>
>>>> what parts remain to be spec'd out?
>>>>
>>>> 1) the refresh call from TA is unchanged correct?
>>>> 2) the returned id_token ?
>>>> 3) the JWT assertion exchange?
>>>>
>>>> paul
>>>>
>>>> On 2/13/14, 11:19 AM, John Bradley wrote:
>>>>> This shows using the token endpoint to side-scope a refresh token
>>>>> to get a id_token with a 3rd party audience using the Google Play
>>>>> example, then using the JWT assertion flow to exchange the
>>>>> id_token for a access token.
>>>>>
>>>>> This is the Google developer spec for the Play Method
>>>>> http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html
>>>>> They don't have there Token Agent do the swap for a access token,
>>>>> they are handing the id_token to the app and letting it use it as
>>>>> an access token or exchange it in some way.
>>>>>
>>>>> The other possibility may be to have the Appinfo endpoint return
>>>>> the id_token along with meta-data about what 3rd party Token
>>>>> endpoint needs to be used to exchange the id_token/JWT assertion.
>>>>> This may work better if the Token Agent is doing the exchange
>>>>> rather than the app.
>>>>>
>>>>>
>>>>> For those not part of the Connect WG we deliberately the id_token
>>>>> the same format as a JWT for use in assertions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 12, 2014, at 6:20 PM, Paul Madsen <paul.madsen at gmail.com
>>>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>>>
>>>>>> guys, care to swimlane that model out at websequencediagrams?
>>>>>>
>>>>>> paul
>>>>>> On 2/12/14, 3:52 PM, Chuck Mortimore wrote:
>>>>>>> We've been thinking of a model where the RS could validate the
>>>>>>> id_token for access to it's services and exchange it via
>>>>>>> assertion flow if it needed to act on behalf of user at the RS
>>>>>>> associated with the original AS. This sounds inline with that
>>>>>>>
>>>>>>> -cmort
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 12, 2014 at 12:39 PM, John Bradley
>>>>>>> <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>>>>
>>>>>>> Hi Chuck,
>>>>>>>
>>>>>>> I will get to this over the next couple of days.
>>>>>>>
>>>>>>> We do have the 3rd party id_tokens that can be used as JWT
>>>>>>> assertions that were added to connect for Google. In
>>>>>>> principal those should be exchanged in the assertion flow
>>>>>>> for access tokens when crossing security domains.
>>>>>>>
>>>>>>> So I suppose the type of token would depend on if the app
>>>>>>> directly accepted access tokens from the AS of the napps agent.
>>>>>>>
>>>>>>> Apps using Google Play services directly use the id_token as
>>>>>>> a access token in general but that places a potential burden
>>>>>>> on the RS to accept tokens of different types. I prefer to
>>>>>>> use the token endpoint to exchange the assertion so the RS
>>>>>>> only needs to worry about access tokens from it's AS
>>>>>>> whatever those happen to be.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>> On Feb 5, 2014, at 11:48 PM, Chuck Mortimore
>>>>>>> <cmortimore at salesforce.com
>>>>>>> <mailto:cmortimore at salesforce.com>> wrote:
>>>>>>>
>>>>>>>> One other thought - Perhaps instead of opaque access
>>>>>>>> tokens for the apps, we should issue id_tokens that are
>>>>>>>> audience restricted
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 5, 2014 at 3:58 PM, Chuck Mortimore
>>>>>>>> <cmortimore at salesforce.com
>>>>>>>> <mailto:cmortimore at salesforce.com>> wrote:
>>>>>>>>
>>>>>>>> *Comments on Agent Core 1.0*
>>>>>>>>
>>>>>>>> 5.0 - Do we need to make client credentials mandatory?
>>>>>>>> Can we make this a MAY?
>>>>>>>>
>>>>>>>> 7.1 - in general seems redundant to oauth/openid
>>>>>>>> connect, with the exception of the AZA scope. Do we
>>>>>>>> need to respecify all of this?
>>>>>>>>
>>>>>>>> 7.1.1 - Why is response_type=code MUST? Is this oauth
>>>>>>>> carry over? (same as my question on 5.0 I think)
>>>>>>>>
>>>>>>>> 7.4.1/2 - By issuing on the token endpoint, we are
>>>>>>>> basically saying that only administrative authorization
>>>>>>>> models will work. If end-user authorized oauth is
>>>>>>>> being used, the user doesn't have a chance to approve
>>>>>>>> access to and new app. Shouldn't we be performing a
>>>>>>>> new Authorization request, rather than a straight
>>>>>>>> refresh token exchange?
>>>>>>>>
>>>>>>>>
>>>>>>>> *Comments on Agent API bindings 1.0*
>>>>>>>>
>>>>>>>> 2.0 - "Rather than the user individually authenticating
>>>>>>>> and authorizing each native application, they do so
>>>>>>>> only for the authorization agent" - same as my last
>>>>>>>> comment; from an authorization model perspective, this
>>>>>>>> basically kills off end-user approval models with this
>>>>>>>> profile. There's no way for the user to make
>>>>>>>> effective authorization decisions for future unknown
>>>>>>>> applications.
>>>>>>>>
>>>>>>>> 4.0 - this seems to really be the meat of what we
>>>>>>>> should specify, but the entire section is basically
>>>>>>>> silent on detail. For this spec to be successful,
>>>>>>>> shouldn't we take a stand and actually specify
>>>>>>>> interaction patterns?
>>>>>>>>
>>>>>>>> 4.1 - "The TA MUST NOT deliver a secondary access token
>>>>>>>> to an application for which it was not issued." seems
>>>>>>>> at odds with the rest of this section. For example,
>>>>>>>> the custom scheme approach would potentially violate
>>>>>>>> this on iOS. I'm not certain there is a reliable way
>>>>>>>> not to violate this when supporting an TA intiated flow.
>>>>>>>>
>>>>>>>> 4.2 - We should really spec out a Native App intiated
>>>>>>>> flow. It may be the only way we can reliably handle
>>>>>>>> the security contraint in section 4.1. One option
>>>>>>>> could be to issue a public key with the authorization
>>>>>>>> request and then encrypt the use JWE to responds, so if
>>>>>>>> the Native app's custom scheme url were hijacked, the
>>>>>>>> returned token wouldn't bleed to the wrong app.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 5, 2014 at 1:18 PM, Paul Madsen
>>>>>>>> <paul.madsen at gmail.com <mailto:paul.madsen at gmail.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Both core & bindings are available at
>>>>>>>>
>>>>>>>> http://hg.openid.net/napps/wiki/Home
>>>>>>>>
>>>>>>>> John has some editorial fixes to make but is hoping
>>>>>>>> to combine with those with any more normative changes
>>>>>>>>
>>>>>>>> Our next call is Wed feb 19 @ 6 pm EST
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-native-apps mailing list
>>>>>>>> Openid-specs-native-apps at lists.openid.net
>>>>>>>> <mailto:Openid-specs-native-apps at lists.openid.net>
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-native-apps mailing list
>>>>>>>> Openid-specs-native-apps at lists.openid.net
>>>>>>>> <mailto:Openid-specs-native-apps at lists.openid.net>
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140213/53447cda/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list