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

Breno de Medeiros breno at google.com
Fri Jun 24 00:36:45 UTC 2011


On Thu, Jun 23, 2011 at 17:24, Mike Jones <Michael.Jones at microsoft.com> wrote:
> I'll think about this and look at the spec again, but I'm pretty sure that I disagree with this.  The data structures used to request and receive claims are not specific to the bindings.  While optional, they're part of the core data structure definitions of OpenID Connect.
>
> If you'd said that you wanted claims moved into a claims spec that is different than the core, but not specific to particular bindings, that would have made more sense to me.
>
> What is your goal in proposing to move claims from the core spec to another spec?

We have set out with a goal that the core would address the most
common use case. Using that and FBConnect as an example of a very
successful use case, we see that:

- Session Management should be in the core
- Claims should not.

I am not opposed to a separate claims document if that makes more
sense than comingling it with AB

>
>                                -- Mike
>
> -----Original Message-----
> From: Breno de Medeiros [mailto:breno at google.com]
> Sent: Thursday, June 23, 2011 5:17 PM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Spec call notes 23-Jun-11
>
> 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
>
>



-- 
--Breno


More information about the Openid-specs-ab mailing list