[Openid-specs-ab] Note from OpenID Connect Meeting @ IETF 87 Berlin
sakimura at gmail.com
Mon Jul 29 12:22:38 UTC 2013
Note from OpenID Connect Meeting @ IETF 87 Berlin
Date & Time: 2013-07-28 14:00-17:00
Location: Charottenburg 1, Intercontinental Hotel, Berlin
Attendee: Mike Jones, John Bradely, Nat Sakimura, Ande F. Niemann, Olef
Bergmann, Stefanie Gerdes, Lucy Lynch, Leif Johannsson, Karn O’donohue,
Joel Snyder, Tatsuya Hayashi, Dirk Balfanz, Torsten Lodderstedt, Brian
It was suggested that perhaps only requiring code flow for the server -
parallel of what Basic Client is. Lengthy discussion about the
interoperability with client libraries such as GIT KIT followed. The result
was that perhaps for non-dynamic client, just supporting code may be OK,
since the client needs to be configured by hand anyways. From editing point
of view, the requirment for supporting response_type=”token” and “token
id_token” in Messages 8.2 Dynamic OpenID Providers.
The nonce is different from state in the sense that it iis signed while the
state parameter is not signed. nonce is signed. So, state can be tampered /
replaced while nonce cannot. This has some impact on the
Re-emphasizing RFC 6749: 10.6 Authorization Code Redirection URI
Replace “replay” with “token hijack” in the explanation of the nonce. It is
really about preventing token hijack. It is a client generated identifier
for its request, which is returned in a signed ID Token so that the client
can correlate the request and the token response.
Describe in the security consideration about the protection nonce gives to
the clients for the cases where server redirect_uri matching is not an
iOS Client Custome scheme
For native app, get the tokens back to apps are done through registered
custome URI scheme. Which app is going to get it is inditerministic as
multiple apps can register the same scheme.
On Android, it is addressed by given user a choice, but on iOS, it is
rather random, so the chances for the attacker client to intercept the code
is rather large.
To mitigate it, one could send request token (left hash of the generated
secret) in the request. Hangout client adds “secret” parameter on the
request. Probably encoding the “secret” in the encrypted code.
The discussion proceeded with the possibility of using the request token as
the client secret in the Basic Authentication. The conclusion was that it
may have layering problems. So, it was decided to have a new parameter to
be sent with the code to the token endpoint.
OpenID 2.0 transition
Finally, the group discussed about the OpenID 2.0 transition to the
Connect. It could be dealt with by requiring the user to login twice with
OpenID 2.0 and OpenID Connect but the user experience is sub-optimal.
Instead, having openid.claimed_id in the ID Token and having oidc.issuer in
XRDS would streamline the process.
When the client received the ID Token, it does the resolution on the
openid.claimed_id (Note: the cleint should have that capability to start
with as it is supporting OpenID 2.0), and find the oidc.issuer and match
this against id_token.issuer.
In the case of directed identifier, the client MUST send the realm as the
sector identifier in OpenID Connect.
2nd Implementer's Draft voting
Attendee was asked by the chairs to vote for the 2nd Implementer's Draft
The meeting adjorned at 17:00.
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab