[Openid-specs-ab] FW: OpenID Connect Face-to-Face Meeting 21-Oct-13
Mike Jones
Michael.Jones at microsoft.com
Mon Oct 21 23:12:14 UTC 2013
From: Mike Jones
Sent: Monday, October 21, 2013 4:11 PM
To: Edmund Jay; Tom Brown; Johann Nallathamby; Brian Campbell; Pamela Dingle; John Ehrig; Jack Greenberg; Morteza Ansari; Lucy Lynch; Justin P. Richer; Breno de Medeiros; Tim Bray; John Bradley; Morten V. Christiansen; Henrik Biering; Naveen Agarwal; George Fletcher; Blake Brannon; Michael Engan; Ashish Jain; Adam Dawes
Subject: OpenID Connect Face-to-Face Meeting 21-Oct-13
OpenID Connect Face-to-Face Meeting 21-Oct-13
Attendees:
Mike Jones
Edmund Jay
Tom Brown
Johann Nallathamby
Brian Campbell
Pam Dingle
John Ehrig
Jack Greenberg
Morteza Ansari
Lucy Lynch
Justin Richer
Breno de Medeiros
Tim Bray
John Bradley
Morten V. Christiansen
Henrik Biering
Naveen Agarwal
George Fletcher
Blake Brannon
Michael Engan
Ashish Jain
Adam Dawes
Agenda:
Structure of Authentication Section
Review of http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2
Review of http://openid.net/specs/openid-connect-core-1_0.html#HybridAccessToken2
Why do we require POST support at the Authorization Endpoint?
Why are we allowing http redirect_uri values when apparently OAuth doesn't?
Why is the id_token_hint recommended for prompt=none?
"The Authorization Code Flow is suitable for Clients that can securely maintain a Client Secret..."
Where should the Client Authentication text be?
Should the "iss", "aud", "redirect_uri", etc. contain a trailing slash?
Discussion of redirect_uri matching
How should the HTTP Form Post text be structured?
Which specs do we make Final and which do we make Implementer's Drafts?
Next steps to get to the Final and Implementer's Drafts?
Prompt=login parameter language discussion
Session management discussion
Structure of Authentication Section
Do we keep current Code/Implicit/Hybrid structure?
People agreed to keep the current organization
People would like text in the overview saying what the different flows are for
Do we move the ID Token definition up?
People decided to make the ID Token 2.1
Review of http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2
Say that the OP may choose to return fewer claims about the user from the Authorization Endpoint for privacy reasons, etc.
All the claims about the authorization event should be present in both
Review of http://openid.net/specs/openid-connect-core-1_0.html#HybridAccessToken2
We will say that they may be the same or may enable different access to resources
Why do we require POST support at the Authorization Endpoint?
http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationRequest
http://tools.ietf.org/html/rfc6749#section-3.1
Size considerations, especially when using the "request" parameter
Privacy considerations for id_token_hint, etc.
Why are we allowing http redirect_uri values when apparently OAuth doesn't?
http://tools.ietf.org/html/rfc6749#section-10.5
OP may prevent registration of redirect_uris that do not use https
A confidential client needs to be required to use http
We will discuss this further on the list
Why is the id_token_hint recommended for prompt=none?
checkid_immediate in OpenID 2.0 worked very well w/o a hint?
Describe the meaning of prompt=none with and without id_token_hint
"The Authorization Code Flow is suitable for Clients that can securely maintain a Client Secret..."
Move to introduction
Add sentence saying that the code flow is sometimes also used by Native clients.
Where should the Client Authentication text be?
Currently it's Section 8
http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
Add forward reference
Move to before 5 (parameters as JWTs)
Introduction
This needs to be more finely crafted and be more complete
Should the "iss", "aud", "redirect_uri", etc. contain a trailing slash?
Do we need to say anything?
We're already matching these as exact strings
Either kinds of strings are acceptable
Discussion of redirect_uri matching
Apparently some are doing wildcard matching in some contexts
It's really easy to get this wrong if you don't do exact match
There was no appetite for changing this
How should the HTTP Form Post text be structured?
There was consensus to make this functionality a separate speclet which we take to Implementer's Draft
Which specs do we make Final and which do we make Implementer's Drafts?
Final: Core, Discovery, Registration, Multiple Response Types
Implementer's Drafts: Session, HTTP Form Post
Do nothing to further approve: Basic, Implicit
Next steps to get to the Final and Implementer's Drafts?
Mike will apply the Core reviews this week, sending e-mail as he goes for points needing discussion
We agreed that people will quickly produce reviews for the other three Final specs
People are requested to do those reviews by Monday, Oct 28
Prompt=login parameter language discussion
Naveen and Breno described the desire to allow risk-based authentication, rather than password-based authentication
In that case, a prompt=login request might not actually prompt the user
We will revise the language to talk in terms of affirmative actions to re-authenticate the user
And to allow statements about a successful reauthentication to be made in the ID Token
Session management discussion
This didn't occur, but may happen during IIW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131021/5767f839/attachment.html>
More information about the Openid-specs-ab
mailing list