[Openid-specs-ab] on a-zed-p (was Re: Spec call notes 31-Aug-15)

Vladimir Dzhuvinov vladimir at connect2id.com
Wed Sep 2 14:04:55 UTC 2015


Thanks for the info Brian. I wasn't aware Google were using "azp" in the
trivial case.

On 1.09.2015 17:27, Brian Campbell wrote:
> In the *normal* Connect flow Google issues ID tokens with the RP's client
> id as the value for both aud and azp. Right* or wrong**, it is what they
> are doing now. So the 'reject it unless you know what you're doing with it'
> is probably going too far. Ignoring is probably more appropriate guidance
> at this point and I suspect is what most clients are doing anyway.
>
>
> * current spec does say "[azp] MAY be included even when the authorized
> party is the same as the sole audience"
>
> ** there seems to be growing consensus that azp shouldn't have been in
> Connect at all and I don't see any point in issuing an id token with azp =
> aud
>
>
>
> On Tue, Sep 1, 2015 at 1:37 AM, Vladimir Dzhuvinov <vladimir at connect2id.com>
> wrote:
>
>>
>> On 1.09.2015 03:02, Mike Jones wrote:
>>> Spec call notes 31-Aug-15
>>>
>>>
>>>                 #973 - Core 2 / 3.1.3.7 - azp claim underspecified and
>> overreaching
>>>                                 We got data on what Google is actually
>> doing with "azp"
>>>                                 Notably, it is not used in an OpenID
>> Connect protocol flow
>>>                                 Brian's comment "Rather Connect should
>> strive for something that's consistent and easily comprehensible" seems
>> dead on
>>>                                 Mike will take a stab at slightly
>> revised wording following Brian's suggestions
>>>                                 John suggests that RPs reject tokens
>> with "azp" unless they understand what is going on
>>
>> I'm also for mandating rejection of ID tokens with "azp" unless the RP
>> knows how to deal with this claim. The "azp" seems to be a rather
>> special case, and if I understand its usage correctly, if cannot simply
>> be ignored if it's present.
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150902/3cedd124/attachment.p7s>


More information about the Openid-specs-ab mailing list