[Openid-specs-ab] Spec call notes 23-Jun-11

[Mike Jones]

Spec call notes 23-Jun-11

Edmund Jay
Mike Jones
Marius Scurtescu
Breno de Medeiros
John Bradley
Nat Sakimura

Goal complete specs enabling implementations by end of month

Agenda:
  - Parameter renaming
  - Feedback on dynamic registration
  - What is the issuer?
  - Discovery

  - Defer discussions on document structuring
                But Edmund has started work on combining the code, artifact, and implicit bindings
                to create an HTTP binding

Parameter "id_token" or "openid_token" was renamed to "session"
                Breno doesn't like calling things that aren't OpenID identifiers "openid"
                We agreed to use the name "id_token"
                We would also use "id_token" as one of the requested OAuth response types

Dynamic Registration and Discovery
                We are currently using SWD to discover the IdP
                Obtaining a client identifier requires client registration
                We are still missing a means of discovering capabilities

                Breno points out that if we strike out client_id, client_secret, expires_in we'd have generic discovery
                Breno wants to discover the dynamic client registration endpoint

                Logic will be:
                1.  Do discovery using SWD to get a discovery URL for the IdP
                2.  Do a HTTP get at discovery URL location
                3.  Do dynamic client registration
                Any of these steps can be optimized out if already known

                John will edit the client registration and SWD specs to accomplish this
                The "Connect SWD" spec will be renamed to something more meaningful like "Connect Discovery"

                Breno will send John a list of the information he believes is required for dynamic registration

Issuer Identifier
                Issue how to verify issuer of an identifier
                Token introspection endpoint one way of verifying IdP
                Public key another way of verifying IdP

                We can use the discovery URL location as the issuer
                Issuer must be authoritative for the URL

                Well-known locations for SWD, Key, Discovery Document

                Issuer can be scheme,domain,port of discovery document URL
                                Since the discovery document location is well-known, this and the discovery document location are equivalent

                We will eventually need to define how keys can be out of band, rather than SSL, for LOA3

Other
                Breno pointed out that dynamic registration may require authorization
                                Some IdPs may not allow dynamic registration by all parties

                John asked about refresh methods
                Key rotation also came up
                                These seem like separate use cases

Action items:
                Breno will send John a list of the information he believes is required for dynamic registration
                John will update discovery and registration documents, per this call
                Nat will send an invitation to another call a week from this one
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110623/54b0d92f/attachment.html>