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

[Edmund Jay]

It was decided in the last conference call, that the current schema will remain 
unchanged until we have further feedback and information.
But as question to the WG, should we make a suggestion/recommendation in the 
spec for authorization servers to implement the profile picture retrieval URL to 
implement functionality as Allen describes?
An issue was brought up in the conference all that this will only work if the 
authorization servers hosted the pictures. If the URL points to a third party 
site, it is unknown what you will get back.
Perhaps, this field should not be a user update-able field and the URL is 
generated by the server from user's uploaded profile pictures?


-- Edmund






________________________________
From: Allen Tom <allentomdude at gmail.com>
To: Andreas Åkre Solberg <andreas.solberg at uninett.no>
Cc: openid-specs-ab at lists.openid.net
Sent: Fri, August 26, 2011 11:33:18 AM
Subject: Re: [Openid-specs-ab] Spec call notes 25-Aug-11

Hi Andres,

I think it is important that the user's profile picture be available in multiple 
sizes, so I'm glad that the WG is considering this.

I don't think that clients should specify the size using the Accept HTTP header, 
since some clients (like javascript clients) may not be able to easily set the 
header. It looks like Gravatar, Twitter, and Facebook all use the technique of 
specifying a base image URL, with an optional size parameter. This sounds like a 
reasonable approach.

Gravatar 
(default: 80x80) 
 http://www.gravatar.com/avatar/2c421806d83cb83b2981933e8efa6e8e
(arbitary size - always square format 
though) http://www.gravatar.com/avatar/2c421806d83cb83b2981933e8efa6e8e?s=250

Twitter
http://api.twitter.com/1/users/profile_image?screen_name=atom
http://api.twitter.com/1/users/profile_image?screen_name=atom&size=original

Facebook
https://graph.facebook.com/allentom/picture
https://graph.facebook.com/allentom/picture?type=large

I had proposed that the OpenID Connect profile picture be returned using a base 
URL. The default size can be left undefined, but clients are able to optionally 
specify the desired size using an optional parameter. In order to avoid having 
to specify what "small/medium/large/x-large" means, we can do something like 
gravitar and let the client specify the size in pixels.

Allen






2011/8/26 Andreas Åkre Solberg <andreas.solberg at uninett.no>


>
>On 26. aug.2011, at 03:19, Edmund Jay wrote:
>
>John offered the following options:
>>a) new scope for requesting picture sizes
>>b) RP makes explicit claim request
>>c) Expand schema to include "small", "medium", and "large"
>>
>
>BTW, here is how gravatar is doing this:
>
>
>http://en.gravatar.com/site/implement/images/#size
>
>
>(I'm not saying that I neccessary like it, I just include it as an example).
>
>
>A related topic, is content type negotiation. Would it be an idea to suggest to 
>use 'Accept' header as the reccomended way of negotiating which  image format 
>that is presented?
>
>
>      Accept: image/gif;q=0.5, 
>image/jpeg;q=0.8, image/png;q=0.9, image/svg+xml;q=1.0
>
>
>I would propose that if we say anything about accept parameters and/or size 
>parameters, it would just be reccomendations to providers that would like to 
>offer multiple formats and sizes; and not a requirement.
>
>Andreas
>
>
>_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110826/8a9d0240/attachment.html>