[Openid-specs-ab] Spec call notes 31-Aug-15
vladimir at connect2id.com
Tue Sep 1 07:37:02 UTC 2015
On 1.09.2015 03:02, Mike Jones wrote:
> Spec call notes 31-Aug-15
> #973 - Core 2 / 184.108.40.206 - 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.
> #979 - Discovery / Security Considerations: CSRF attack on user input identifier
> We need to work out how to prevent MITM attacks against Dynamic Registration
> The attack is getting someone to talk to a bad token endpoint
> You don't know that you've registered at the right endpoint when you register
> This issue clearly needs discussion on the mailing list.
> One possible fix is to have registration return the token endpoint URL for a cross-check
> Mike points out that in multi-tenant environment, the issuer will vary by tenant
> We may want to look at how we're using the JWT token profile
Here is an alternative solution:
The RP (client) may be required to include the discovered Issuer URL in
the client registration request. The OP can then check whether the RP
has used a legitimate discovery endpoint, and if not deny registration.
I think this approach will fare better. The client is not required to do
a cross check, which developers may forget to implement. OPs are more
likely to get this right.
More information about the Openid-specs-ab