[Openid-specs-ab] Spec call notes 08-Aug-11

Nat Sakimura sakimura at gmail.com
Tue Aug 9 02:16:57 UTC 2011


On 2011/08/09, at 10:03, Breno de Medeiros wrote:

> On Mon, Aug 8, 2011 at 17:15, Edmund Jay <ejay at mgi1.com> wrote:
>> 
>> Spec call notes 08-Aug-11
>> 
>> Pam Dingle
>> John Bradley
>> Nat Sakimura
>> Johnny Bufu
>> George Fletcher
>> Edmund Jay
>> 
>> 
>> 
>> John made some changes to the OpenID Lite spec
>>     * changed the Introspection endpoint from GET request to POST request
>> due to the fact the
>>        the ID Token may be intercepted by referral URLs/Logs, and other
>> methods.
> 
> Referral URLs doesn't make sense as a concern here: The requests are
> sent to API endpoints that return data. There are no redirects or 3rd
> party content inclusion. 

OK. Perhaps we should note that it should only be used in such a way that 
it will not leak from referrer etc. 

> 
> As for logs, that is a valid concern -- but it also applies to any
> OAuth2 protected endpoint. This introduces another variance from the
> OAuth2 standard, which says that query support SHOULD NOT be used

Yes, it is a variance but constraining further (i.e., profiling) is perfectly valid. 
We should not rule out the possibility. 
In general, if we constrain more, we achieve more interoperability. 

> (which I understand to mean that the client should attempt other means
> preferably, not that servers should not support it). Instead of
> eliminating query support, we should provide security recommendations
> about log scrubbing of sensitive values.
> 
> Google plans to be at variance here, and we request that the spec do
> not use language such as MUST NOT support the query parameter auth
> method.

I did not quite get the exact meaning of the sentence. 
Could you kindly explain a little more? 

> 
>>        Breno said in chat with Nat that GET and JSONP may be needed
> 
> Yes, user agent-based client components will want to be able to handle
> authentication on their own in many cases, in particular when the
> user-agent application is long-lived and synchronizes state with the
> server only when significant events take place.

I am kind of interested in how JSONP requests are sent 
in accordance with OAuth 2.0 spec. 

> 
>>        John to contact Breno offline for further discussions
>>     * made other non-controversial changes from feedback
>> 
>> John will work on first draft of OpenID 2.0 compatibility/migration spec.
>> Maybe available tomorrow.
>> 
>> Edmund will post first draft of OpendID Connect Messages spec to the mailing
>> list.
>> 
>> 
>> Discussion of JWT and long header names:
>>     * most preferred longer names
>>     * most feel that it's too late to make major changes to spec
>>     * longer or shorter names can be implemented by defining long constant
>> values by developers vice versa
>>     * perhaps better documentation in specs for short names
>> 
>> Pam has written a OpenID Connect landing page which will be posted to the
>> list for feedback
>> 
>> WG to setup new support mailing list not encumbered by IPR agreements for
>> general and support questions and feedback.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
> 
> 
> 
> -- 
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab




More information about the Openid-specs-ab mailing list