[Openid-specs-ab] Spec call notes 24-Jan-13

[Mike Jones]

Spec call notes 24-Jan-13

Mike Jones
Nat Sakimura
Justin Richer
Roland Hedberg
Pamela Dingle
George Fletcher
Brian Campbell

Agenda:
                Open Issues
                Implementer's Drafts Work Status

Open Issues:
                There were no new open issues

Implementer's Drafts Work Status:
                Mike released release candidate versions yesterday
                We will give people through Monday to review them
                We will decide on the Monday call whether we're ready to release the Implementer's Draft versions

Implementation Status:
                We want to get interop on WebFinger-based discovery before releasing the Implementer's Drafts
                                Roland has code
                                Edmund has code
                                Both need to make it the default
                                Justin has server side code
                Anomalies noticed by Pam while working on the native client application:
                                Edmund's implementation has an "ops" claim
                                Not everyone has a "jti" claim
                                Not everyone has "sub" yet - for instance, Ping
                Ping's implementation still has to make several updates, including "sub", JWK name changes, etc.

                The most important change is to switch discovery to WebFinger
                                We'd like to get WebFinger interop before the implementer's draft release
                Also, there were registration parameter name changes

                Implementers should please post to the interop list as changes are pushed live

Pam's Comments on Basic:
                Basic 2.2.1.  Client Prepares Authorization Request says
                                Clients MAY construct the request using the HTTP GET or the HTTP POST method as defined in RFC 2616 [RFC2616].
                Standard 2.3 says
                                Authorization Servers MUST support the use of the HTTP "GET" and "POST" methods defined in RFC 2616 [RFC2616] at the Authorization Endpoint.

                We don't need to express a preference between the methods in Basic
                We may say that they can use either because OPs must support both

                Basic 2.2.6.  Client Obtains ID Token and Access Token
                Basic 2.2.6.1 says no preference between POST or GET
                                References 4.1.3.  Access Token Request of OAuth 2.0 [RFC6749]
                                References 3.2.1.  Client Authentication
                                References 2.3.1.  Client Password
                                                Recommends using Basic in authorization header

                We should recommend putting the client credentials in the Authorization header in Basic
                                As recommended in OAuth 2.3.1
                We may also want to mention that this is the client_secret_basic method from Registration

                OAuth 3.2.  Token Endpoint says
                                The client MUST use the HTTP "POST" method when making access token requests.

                The phrase "Access Token Request" should appear in 2.2.6
                We might also want the term "Client Authentication" to appear in 2.2.6.1

                We may need to clarify what we mean by "Token Endpoint" - "OAuth Access Token Endpoint"

Native client:
                Pam has credentials for Oreo, Edmund's, Ping's, and is trying with AOL
                She is planning to also do Mitre, but it needs to be hosted
                Pam believes she is one bug from doing a release of the Native Client

Key Rollover:
                This is still an open problem, per discussions on the list
                John still needs to write up possibilities
                We may want to add "exp" (expiration time) to JWK
                Breno also made comments about how rollover is harder for encryption keys
                We agreed that this is important address for the sake of long-term usability of the protocol

Held Issues:
                We reviewed all the held issues
                Many were closed as no longer relevant - most being about the former Session Management spec
                #364 was reopened: Term "Session" not defined
                A task to register the /.well-known/openid-configuration URI with IANA was also reinstated
                                We agreed that we should make all registration requests once the Implementer's Drafts are published
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130124/0de650ad/attachment.html>