[Openid-specs-ab] Spec call notes 23-Jun-11
Breno de Medeiros
breno at google.com
Fri Jun 24 00:17:10 UTC 2011
I will be reading Edmund's current effort to reconcile the abstract
protocol description with protocol bindings. In the meantime, may I
suggest that we remove all the claims-related definitions for the core
spec and move it to artifact binding? I think in the core spec we just
need to specify that the behavior is extensible by the definition of
additional parameters.
On Thu, Jun 23, 2011 at 16:10, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
--
--Breno
More information about the Openid-specs-ab
mailing list