Attribute scheme/data model
Santosh Rajan
santrajan at gmail.com
Fri Dec 11 15:00:15 UTC 2009
Hi Chris,
You said this subject has been touched before. Do you have a link i can
read? I am NOT yet a great fan of semweb or foaf+ssl yet. (Sorry Peter
Williams you haven't convinced me yet, but you are a great guy and I really
miss you at the OpenID forums).
Thanks
Santosh
I still feel we can have a Data Model with synchronous signatures.
On Fri, Dec 11, 2009 at 2:17 PM, Chris Obdam <chris.obdam at holder.nl> wrote:
> This is a subject which has been touched before. First question is: should
> OpenID incorporate a datamodel.
>
> Yes, I think. RP need more clearity on this matter.
>
>
> Op 10 dec 2009, om 16:37 heeft Santosh Rajan het volgende geschreven:
>
>
> As usual I am going to digress a bit here. As far as I can see, the problem
> with OpenID is that it does NOT have a "data model".
>
> When we look at a data model, we don't really need to worry about the
> serialization format. It could be anything, POST message key values, JSON,
> RDF or Atom. The important thing is that we need a data model, and a
> consistent one at that, through out the OpenID protocol process.
>
> Once we have a proper data model in place, answering all these "discovery"
> and "AX" questions will be trivial.
>
> One more point about the trust issue. I am all for synchronous signatures
> rather than asynchronous.
>
> I am working on this. But this is not something I can do alone. Any
> collaboration will be appreciated. And all work will be done under the
> OpenID IPR.
>
> Thanks all,
> Santosh
>
>
> 2009/12/10 Nat <sakimura at gmail.com>
>
>> This is a CX use case. In CX, user consent is captured in a signed
>> document called contract together with what gets sent under what
>> circumstances. The contract gets a unique URL to identity it and one can use
>> that to point to the collection of data as well.
>>
>> The WG is up and running so there is no need to wait.
>>
>> =nat at Tokyo via iPhone
>>
>> On 2009/12/10, at 12:19, Allen Tom <atom at yahoo-inc.com> wrote:
>>
>> Automatically sharing profile/avatar pic (with user consent) definitely
>> adds a lot of value to both users and RPs, and profile pic was one of the
>> most frequently requested attributes that we heard from potential RPs.
>>
>> The Yahoo OP currently shares the URL to the user’s Yahoo Profile pic,
>> however, the pic does not automatically get updated when the user updates
>> their Yahoo Profile pic.
>>
>> One of the things that I’d like to clarify in AX 1.1 is whether or not RPs
>> should be able to deep link directly to the profile pic, or if they’re
>> expected to download and cache it themselves. Also, if RPs are able to deep
>> link to the profile pic, then we should also define whether or not the
>> content of the URL be updated when the user updates their pic.
>>
>> Allen
>>
>> On 12/9/09 5:17 AM, "Jonathan Coffman" <<http://jonathan.coffman@gmail.com/>
>> jonathan.coffman at gmail.com> wrote:
>>
>> Avatars would definitely be huge. I can't tell you how frustrating it is
>> as a user to update my avatar on all of the hundreds of sites I may
>> encounter that require login.
>>
>> Professionally, I've run into problems when bringing up Gravatar as a
>> potential option... but again, that sets the bar so high that users are
>> pretty unlikely to even go through that process.
>>
>> Jonathan
>>
>>
>> On Dec 9, 2009, at 2:09 AM, Chris Messina wrote:
>>
>> +1. I think those are the basic profile building blocks for social
>> software. The avatar is something we particularly need for openid.
>>
>> Sent from my iPhone 2G
>>
>> On Dec 8, 2009, at 22:06, John Panzer < <http://john@johnpanzer.com/>
>> john at johnpanzer.com> wrote:
>>
>> For my use cases, the important things are, unscientifically,
>>
>> 1. Display name
>> 2. Avatar / photo
>> 3. Preferred link to human-readable online presence -- profile, blog,
>> whatever strikes their fancy.
>>
>>
>>
>>
>> On Tue, Dec 8, 2009 at 8:38 PM, David Recordon < < <recordond at gmail.com>
>> mailto:recordond at gmail.com <recordond at gmail.com>>
>> <http://recordond@gmail.com/>recordond at gmail.com> wrote:
>>
>> I'm sure that the data is wildly out of date, but at the time the SREG
>> fields ( <<http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format>
>> http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format>
>>
>> <http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format>
>> http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format
>> )
>> were based on looking at what a few hundred different sites were
>> asking for.
>>
>> I unscientifically think that the extremely common stuff is:
>> - Name
>> - Avatar / photo
>> - Email address
>>
>> Scientifically, we should actually put some effort into looking at
>> sign in pages again. :)
>>
>> --David
>>
>>
>> On Tue, Dec 8, 2009 at 7:59 PM, Jonathan Coffman
>> < < <jonathan.coffman at gmail.com>mailto:jonathan.coffman at gmail.com<jonathan.coffman at gmail.com>>
>> <http://jonathan.coffman@gmail.com/>jonathan.coffman at gmail.com> wrote:
>> > Out of curiosity, beyond the email discussion below what are the
>> primary
>> > metadata needs around the other major (PoCo) fields?
>> > Speaking to the use-cases I work off of here at PBS, I'm primarily
>> concerned
>> > about emails being verified (and a signup date is also useful) and am
>> most
>> > inclined to trust the OP (especially if it were a white-listed or
>> otherwise
>> > vetted iDP).
>> > Jonathan
>> >
>> > On Dec 8, 2009, at 2:17 PM, Chris Messina wrote:
>> >
>> > Is it worth looking at how Facebook handles the passing of profile
>> data? Or
>> > is their architecture/use case different?
>> >
>> > < <http://wiki.developers.facebook.com/index.php/Users.getInfo>
>> http://wiki.developers.facebook.com/index.php/Users.getInfo>
>> <http://wiki.developers.facebook.com/index.php/Users.getInfo>
>> http://wiki.developers.facebook.com/index.php/Users.getInfo
>> > On Tue, Dec 8, 2009 at 11:08 AM, Breno de Medeiros < <<breno at google.com>
>> mailto:breno at google.com <breno at google.com>> <http://breno@google.com/>
>> breno at google.com> wrote:
>> >>
>> >> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer < < <jpanzer at google.com>
>> mailto:jpanzer at google.com <jpanzer at google.com>>
>> <http://jpanzer@google.com/>jpanzer at google.com> wrote:
>> >> > For "one-time" URLs, you'd probably want to allow for retries for a
>> >> > short
>> >> > period (or just allow it to be accessed for say 5m) which would have
>> >> > approximately the same level of protection.
>> >> > You could also imagine long-lived capabilities along the lines of
>> OAuth
>> >> > tokens that allow RPs to repeatedly refresh the data as needed.
>> (Better
>> >> > of
>> >> > course if they can subscribe to changes, but that's an
>> implementation
>> >> > detail
>> >> > and definitely a separate spec.)
>> >> > Given that AX already supports requesting URL-valued data (e.g.,
>> profile
>> >> > photos) I think this just comes down to defining a fairly
>> complicated
>> >> > data
>> >> > type for AX and passing a URL around.
>> >>
>> >> A more lightweight alternative is to adopt an 'artifact' mode where
>> >> most of the OpenID assertion (request and response) can be passed in
>> >> the backchannel. That is a bit more difficult to implement but easier
>> >> to spec (because the existing URLs can be used) and more general
>> >> (compacts all extensions, not only AX).
>> >>
>> >> > --
>> >> > John Panzer / Google
>> >> > < <jpanzer at google.com>mailto:jpanzer at google.com<jpanzer at google.com>>
>> <http://jpanzer@google.com/>jpanzer at google.com / <<http://abstractioneer.org/>
>> http://abstractioneer.org> abstractioneer.org <<http://abstractioneer.org/>
>> http://abstractioneer.org> / @jpanzer
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins < < <peterw at tux.org>
>> mailto:peterw at tux.org <peterw at tux.org>> <http://peterw@tux.org/>
>> peterw at tux.org> wrote:
>> >> >>
>> >> >> On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote:
>> >> >>
>> >> >> > provide to RPs. If you send an endpoint URL to the RP instead of
>> the
>> >> >> > information itself, the RP can then retrieve it via a backchannel
>> >> >> > (and
>> >> >> > cache
>> >> >> > it). If you have private data, use a capability URL with a token
>> >> >> > that
>> >> >> > allows read-only access.
>> >> >>
>> >> >> Exactly. OpenID requests and responses are very chatty, and
>> backchannel
>> >> >> URLs could be an easy way to get around the 2k GET limit (the cost
>> of
>> >> >> course being additional time needed to make the additional HTTP
>> >> >> requests).
>> >> >>
>> >> >> I don't see any reason for backchannel URLs to be requested
>> multiple
>> >> >> times,
>> >> >> so in addition to a request or response using strongly random
>> nonces in
>> >> >> the backchannel URLs, the backchannel URLs should be very
>> short-lived,
>> >> >> probably each side "SHOULD" allow a URL to be requested only once,
>> and
>> >> >> throw a 403/404 for subsequent requests.
>> >> >>
>> >> >> Is there any draft of AX using backchannel URLs?
>> >> >>
>> >> >> -Peter
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > specs mailing list
>> >> > < <specs at lists.openid.net>mailto:specs at lists.openid.net<specs at lists.openid.net>>
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> >> > < <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs>
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> --Breno
>> >>
>> >> +1 (650) 214-1007 desk
>> >> +1 (408) 212-0135 (Grand Central)
>> >> MTV-41-3 : 383-A
>> >> PST (GMT-8) / PDT(GMT-7)
>> >> _______________________________________________
>> >> specs mailing list
>> >> < <specs at lists.openid.net>mailto:specs at lists.openid.net<specs at lists.openid.net>>
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> >> < <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs>
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >
>> >
>> >
>> > --
>> > Chris Messina
>> > Open Web Advocate
>> >
>> > Personal: < <http://factoryjoe.com/>http://factoryjoe.com>
>> <http://factoryjoe.com/>http://factoryjoe.com
>> > Follow me on Twitter: < <http://twitter.com/chrismessina>
>> http://twitter.com/chrismessina> <http://twitter.com/chrismessina>
>> http://twitter.com/chrismessina
>> >
>> > Citizen Agency: < <http://citizenagency.com/>http://citizenagency.com>
>> <http://citizenagency.com/>http://citizenagency.com
>> > Diso Project: < <http://diso-project.org/>http://diso-project.org>
>> <http://diso-project.org/>http://diso-project.org
>> > OpenID Foundation: < <http://openid.net/>http://openid.net>
>> <http://openid.net/>http://openid.net
>> >
>> > This email is: [ ] shareable [X] ask first [ ] private
>> > _______________________________________________
>> > specs mailing list
>> > < <specs at lists.openid.net>mailto:specs at lists.openid.net<specs at lists.openid.net>>
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> > < <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs>
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >
>> >
>> > _______________________________________________
>> > specs mailing list
>> > < <specs at lists.openid.net>mailto:specs at lists.openid.net<specs at lists.openid.net>>
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> > < <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs>
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >
>> >
>> _______________________________________________
>> specs mailing list
>> < <specs at lists.openid.net>mailto:specs at lists.openid.net<specs at lists.openid.net>>
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> < <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs>
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>> ------------------------------
>> _______________________________________________
>> specs mailing list
>> <http://specs@lists.openid.net/>specs at lists.openid.net
>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
> --
> http://hi.im/santosh
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
--
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091211/93748583/attachment.htm>
More information about the specs
mailing list