[Openid-specs-ab] Spec development call 4-Apr-11

Breno de Medeiros breno at google.com
Thu Apr 7 15:09:56 UTC 2011


Trying again to post to the list, now with everybody copied in the
bcc: because the openid mailing list doesn't like posts with cc:
folks. Also making sure that the reply quotes the shared document.


@Nat, thanks for pointing out my error. Copying the list.

@Chuck, thanks for the corrections to '#' and '?' and the observation
of the missing expiration date, corrected.

How should we proceed from here? I'd like to move this document to a
collaborative format in a neutral platform.

On Wed, Apr 6, 2011 at 16:14, Breno de Medeiros <breno at google.com> wrote:
> On Wed, Apr 6, 2011 at 16:01, Chuck Mortimore <cmortimore at salesforce.com> wrote:
>> Question:
>> In the user agent binding why not return the id_token front channel?
>
> One consideration here is the possibility of copy-and-paste attacks
> where the access_token and id_token are for different users.
>
>>
>> Comments:
>> In the web server binding, the response should be JSON encoded rather than
>> name/value pairs.   I’m guessing you did this as short hand, but in any
>> resulting spec we’d want this consistent with a regular token response.
>>
>> We’ve been considering optionally collapsing the token response and
>> user_info endpoints for efficiency.   Anyone else interested in this
>> approach?
>
> We don't think it's worth it because user_info will be accessed much
> less often, so it's probably a net efficiency loss.
>
>>
>> -cmort
>>
>> On 4/5/11 10:20 AM, "Breno de Medeiros" <breno at google.com> wrote:
>>
>> Okay, this is the Google document format (public, no Google sign-in
>> required) that I am circulating immediately to allow for early
>> feedback:
>>
>> https://docs.google.com/document/d/1Gw0PsPwVuKpeTgE-nzg3TtdB5nqoRlM9vrxyrBr9MLw/edit?hl=en
>>
>> - This document was obtained by removing Google specific references to
>> an internal document that I am writing as a design spec for the
>> implementation we will be working on in parallel with this spec
>> effort; please forgive any Google-isms you may find
>>
>> - Some naming inconsistencies exist between the pictures and the text,
>> because I didn't have time to update the pictures.
>>
>> Next steps is to gather and incorporate all the good feedback I am
>> sure to get in this list, and start a repo somewhere so that we can
>> collaboratively work on this.
>>
>> Cheers,
>>
>> -- Breno
>>
>> On Tue, Apr 5, 2011 at 05:56, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> That time works OK for me.   Currently I am 1h ahead of EDT but will net
>>> the same as EDT next month.
>>>
>>> George is in DC EDT.
>>>
>>> John B.
>>> On 2011-04-05, at 1:29 AM, Nat Sakimura wrote:
>>>
>>>> 7am is fine for me, as long as my home gets power.
>>>> (My office always gets power because we are right next to the TV station
>>>> :-)
>>>>
>>>> Edmund is in PDT. George is in EDT, I think.
>>>>
>>>> =nat
>>>>
>>>> (2011/04/05 14:11), Axel.Nennker at telekom.de wrote:
>>>>> The time I suggest is 7am for Nat, for me and Kick midnight, for you,
>>>>> mike, chuck and paul it is 3pm.
>>>>> I don't know where George andejay at mgi1.com  are located.
>>>>>
>>>>> I find 7am and midnight both at the border of acceptable.
>>>>>
>>>>> -Axel
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (n-sakimura at nri.co.jp)
>>>> Nomura Research Institute, Ltd.
>>>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>>>
>>>>
>>>> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
>>>> PLEASE READ:
>>>> The information contained in this e-mail is confidential and intended for
>>>> the named recipient(s) only.
>>>> If you are not an intended recipient of this e-mail, you are hereby
>>>> notified that any review, dissemination, distribution or duplication of this
>>>> message is strictly prohibited. If you have received this message in error,
>>>> please notify the sender immediately and delete your copy from your system.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>>
>>
>
>
>
> --
> --Breno
>



-- 
--Breno


More information about the Openid-specs-ab mailing list