[Openid-specs-native-apps] Please review specs
Paul Madsen
paul.madsen at gmail.com
Fri Feb 14 15:33:19 UTC 2014
thanks, perfect
On 2/14/14, 10:29 AM, John Bradley wrote:
> The connect spec was modified to allow for it but it is not explicitly
> called out anyplace as how you do 3rd party id_tokens.
>
>
> In Core Sec 2
> <http://openid.net/specs/openid-connect-core-1_0.html#IDToken>
> We modified "aud" from a single value to an array:
> aud
> REQUIRED. Audience(s) that this ID Token is intended for. It MUST
> contain the OAuth 2.0 client_id of the Relying Party as an
> audience value. It MAY also contain identifiers for other
> audiences. In the general case, the aud value is an array of case
> sensitive strings. In the common special case when there is one
> audience, the aud value MAY be a single case sensitive string.
>
> We added "azp" to identify the party to whom the token was issued:
>
> azp
> OPTIONAL. Authorized party - the party to which the ID Token was
> issued. If present, it MUST contain the OAuth 2.0 Client ID of
> this party. This Claim is only needed when the ID Token has a
> single audience value and that audience is different than the
> authorized party. It MAY be included even when the authorized
> party is the same as the sole audience. The azp value is a case
> sensitive string containing a StringOrURI value.
>
> That way an id_token can identify who issued it "iss", to what client
> was it issued "azp" and who are the valid audiences.
>
>
> In Core Sec 3.1.3.7
> <http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>
> for id_token validation by a client the rules state:
>
> 1. The Client MUST validate that the aud (audience) Claim contains
> its client_id value registered at the Issuer identified by the
> iss (issuer) Claim as an audience. The aud (audience) Claim MAY
> contain an array with more than one element. The ID Token MUST be
> rejected if the ID Token does not list the Client as a valid
> audience, or if it contains additional audiences not trusted by
> the Client.
> 2. If the ID Token contains multiple audiences, the Client SHOULD
> verify that an azp Claim is present.
> 3. If an azp (authorized party) Claim is present, the Client SHOULD
> verify that its client_id is the Claim Value.
>
>
> We also took out a prohibition on returning a id_token from the token
> endpoint in response to a "refresh_token" grant_type.
>
> Google presented the use case for third party id_tokens relatively
> late in the process, so we allowed for them to be fully defined in an
> extension like napps.
> The important thing we did was include the processing rule about
> multiple audiences and "azp" in the core spec so that clients who
> don't know about third party id_tokens won't blindly accept them if
> they have someone else as the "azp" even if they are one of the
> audiences.
>
> That's why the Connect spec is silent on how to request them and all
> of the possible additional semantics.
>
> I think it is up to us to define the missing parts.
>
> John B.
>
> On Feb 14, 2014, at 11:26 AM, Paul Madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> John, can you point me to the relevant piece of Connect that enables
>> these 3rd party id_tokens?
>>
>> thanks
>>
>> paul
>> On 2/12/14, 3:39 PM, John Bradley 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/20140214/cb87ba3e/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list