OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] XRD and JSON

I believe that's pretty accurate.  I'm not sure if the extender necessarily needs to be represented inside the JSON-XRD itself, but that certainly wouldn't hurt anything.  I'm not sure that there is any issue with Google asserting Flickr information... I have made an explicit connection to my Flickr account from my Google profile (http://www.google.com/profiles/wnorris), so why shouldn't Google assert that (with user consent, etc)?


On Fri, Apr 23, 2010 at 10:17 AM, John Bradley <jbradley@mac.com> wrote:
So it may be better to to say that your use case requires a XRD preprocessor that creates a standard JSON object from a XRD (The XRD may or may not exist)

The JSON object may need to be optimized differently from XRD.

You have:
1.  Who is the extender  ie Google
2.  What is the users LocalID for the Service/relationship eg ve7jtb
3.  What is the rel  ie Photo sharing 
4.  What is the Link  eg Flickr

This produces interesting questions about Google asserting information for Flikr and Yahoo for Picassa.

So there needs to be a transform of several XRD into JSON objects that the browser manipulates and returns another JSON object to the requestor based on the results of some query.

The resulting JSON object may be acted upon in the browser by JS from the RP or returned to the RP where it may or may not be reconstituted as a XRD.

There is an advantage to standardizing the JSON object because multiple IdP will be producing them for manipulation by Xauth and Xauth will be producing them for multiple RP libraries.

Is that a far synopsis of what you are looking for?

John B.

On 2010-04-22, at 9:03 PM, Will Norris wrote:

On Thu, Apr 22, 2010 at 4:52 PM, John Bradley <jbradley@mac.com> wrote:
I don't think that Xauth has the concept of looking for things by service yet.

correct, it doesn't support that yet... we're already looking toward future work.

You cant ask for all of the persons openID providers, you have to ask for the token of a specific extender.

Is this so that the extender can push a JSON XRD to allow the JS to search by service/rel?


I have concerns about the privacy issues as well, but that is for a different forum.

John B.
On 2010-04-22, at 6:45 PM, Will Norris wrote:

right now, we're looking at formats for storing data in an XAuth payload.  Certainly, one very simple thing could be flag that states "this user has an active session at Google", and nothing more.  But you could just as easily store links to various service providers.  

So when I login to Google, it stores a small XRD in XAuth that includes a link:
  link: { rel: "photo-service", href: "http://picasaweb.google.com/" }

And then when I sign in to Yahoo, it also adds a link:
  link: { rel: "photo-service", href: "http://flickr.com/" }

And then when I go to some printing service, it can prompt me to import my photos from Flickr or Picasa.

there are huge potential privacy implications around this, so I don't know if it will even fly.  Certainly, a lot of thought has to go into exactly what data should be stored, who should have access, how access is actually controlled, etc. But conceptually, the kind of data that could be stored in XAuth is identical to what is stored in a user's XRD.  It makes a lot of sense to try and re-use XRD (or some flavor of it) rather than invent something new.  It's a small step towards a rich identity-aware user agent, but using the tools we have today.

I'm not completely clear on how the access controls work, either for reading or writing data, but what I've heard has lead me to believe that the data does not necessarily need to be signed.


On Thu, Apr 22, 2010 at 3:20 PM, John Bradley <jbradley@mac.com> wrote:
Can you explain the initial use case a bit for us?

John B.

On 2010-04-22, at 5:45 PM, Will Norris wrote:

you either have:
  1) a no-brainer method of switching between XML and JSON like JsonML, and then have to do some work to get the JSON into the right logical object, or
  2) a no-brainer JSON format that can be used as-is, and you have to do a little work to switch between the XML and JSON formats

It's just a matter of which one you want to optimize for.

Signatures are of course an issue, and I don't really have an answer for that.  The immediate use-case we're looking at wouldn't necessarily need signatures, though.


On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <jbradley@mac.com> wrote:
I am still trying to understand the use case.

Having multiple discovery formats each requiring separate processing is not optimal.

Being able to transform from one to the other may have advantages.

I am speculating that the Google wants a discovery format that can be entirely parsed with JS inside the browser.

I am not personally religious about XML. 

If a JSON  format that can be transformed into the equivalent XML XRD can be specified that may be a useful work product for the TC.

My main concerns are around signatures if this starts being used on the server as well as in the browser.

The Google seems to have decided this week that going outside the existing standards development process is more efficient.
I would prefer that this not result in competing discovery standards.

It is worth discussing, but at the end of the day Google may need to do what it needs to do.

John B.

On 2010-04-22, at 3:04 PM, Will Norris wrote:

On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> JsonML does a far better job than some other similar utilities I've seen,
> that is certainly nice.  And for it's stated goals of providing a compact
> format for transporting XML, it works great.  But that kind of misses the
> point of using JSON, which is to provide an natural representation of the
> object, not just a document.

I think the document is the natural representation. A simple layer of code
addresses whatever limitations might exist in the language that's purporting
to be too difficult to use the document in.

But as a matter of specification, the problem you have is that, like SAML,
there's an explicit characterization of the notion of an XRD as being XML.
If it's not XML, it's not an XRD. I have not seen a simple way around that.

A separate specification can be created to establish an interchange format
in some other encoding with a different label attached to it, but if the
goal here was to allow for non-XML representations of an XRD, it would
require some fairly big changes that I'm pretty comfortable saying nobody
wants to take on.

certainly, I wasn't meaning to suggest a departure of any kind from how XRD is defined today.  I've been quite upfront from the beginning of my involvement with this TC that I view XRD (as it's specified) solely as an XML format, and if you want something else, then do it yourself.  Well, now Google is sort of doing it ourselves, and we figured that if others end up wanting to do the same, it might be good to have agreement on what that JSON format looks like.  That could just be a whitepaper, a best practice guide, or whatever.  It certainly doesn't have to be a product of this TC, I just thought I would see if it was anything folks had any interest in it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]