[WG-UMA] Protocol Issue: AM-Host communication in step 1

[Christian Scholz]

Hi!

I was just trying to come up with a more real world example for my
prototype and had the following in mind:

Bob has a profile on Host with different levels of details:

http://host/profiles/bob.basic
http://host/profiles/bob.medium
http://host/profiles/bob.details

(ideally this would be one URL but the policies might define how much
information will be transmitted)

Now he might choose to have the following policies for the requester:

- If facebook.com is asking, allow only access to basic (because he
heard FB is evil)
- If google.com is asking, give details to the medium profile (because
he only heard from Germany that Google is evil)
- For everybody else return the detailed information (because he hasn't
heard yet that everybody is evil).

Or he might choose to select it by requesting party:

- If username=mary, give all details
- If username=joe, give medium
- otherwise give basic profile (anonymous access)

So here we might differ between requesting party (an individual user)
and requester (maybe the company, e.g. newspaper.com because I just
called them and they wanted access to some profile information)

Now the problem is how the AM actually knows which resources are
available and furthermore how the user configures them.

The resources cannot simply be URLs because the user probably doesn't
know what http://host/profiles/bob.medium means.

So there needs to be some way for the Host to tell the AM which
resources are available and how they are named (maybe a description, too).

Now a spontaneous answer would be: Another XRD. But the problem is

a) that the URLs need to be personalized (could be done with templates
though)
b) there could potentially be a lot of them, e.g. every flickr photo or
e.g. the twitter lists defined (which might vary in number). This
wouldn't work with XRD.
c) What about actions on these objects. Should they be listed, too?

So there needs to be some way of the Host sending some document to the
AM. The AM could list those resources then (maybe they also have a
shortname for internal use and for the scope parameter later on) and ask
the user for conditions under which these are accessible to a
requester/requesting party.

This would probably mean another lookup though and thus will make the
protocol more complicated.

So I wonder how this has been solved in SMART :-)

For my prototype I will assume now that the information has somehow been
transferred to the AM and will be displayed there to be configured.

An example format might be:

{
resources : [
{ id: 'profile.basic',
title: 'Basic Profile',
description: 'only shows name'
},
{ id: 'profile.medium',
title: 'Medium Detailed Profile',
description: 'shows name and age'
},
{ id: 'profile.detail',
title: 'Detailed Profile',
description: 'show name and everything nobody really wants to know
about you'
},
]
}

For Twitter lists the ids and descriptions might match the twitter list
title and id/url, for Google Calendar this might be the list of
calendars one has.

Now of course this set of data can actually also include the title and
description of the host as well so there wouldn't be a need for XRD. But
that's not what people want I assume ;-)

Moreover there needs to be a way to transfer this to the AM and the
question is whether this is pull or push. As the user is being
redirected to the AM it looks more like the AM has to pull that
information from the host bringing up the question on how the document
for the right user is identified.

Some out of the box thought: Would it make sense to configure policies
on the Host side? (probably not as only the AM might know about the
claims it is able to understand).

(btw, I looked up the conversation on JSON in XRD at OASIS and as the
XRD spec is locked there won't be a JSON representation in there. Will
Norris and others have come up with something but this will be some
separate spec without any details yet on which process will be applied
to it).

-- Christian


--
Christian Scholz Homepage: http://comlounge.net
COM.lounge GmbH blog: http://mrtopf.de/blog
Hanbrucher Str. 33 Skype: HerrTopf
52064 Aachen Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0 E-Mail c...@comlounge.net
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T

Podcasts:
Der OpenWeb-Podcast (http://openwebpodcast.de)
Data Without Borders (http://datawithoutborders.net)
Politisches: http://politfunk.de/
Technical: http://comlounge.tv/

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

--
You received this message because you are subscribed to the Google Groups "Kantara Initiative User Managed Access WG" group.
To post to this group, send email to kantara-init...@googlegroups.com.
To unsubscribe from this group, send email to kantara-initiative...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kantara-initiative-uma-wg?hl=en.

[Eve Maler]

Since you sent this a mere couple of days ago, I happen to know that you've already prototyped a solution! :-) Just so folks know, the solution uses a close variant of the JRD form of XRD (which Eran has described here: http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/), and allows the host to make a "request" to the AM that passes it a structure informing it what sorts of resources are protected by it for this user.

We've discussed this as an ideal solution for Alice's experience, since that way she can just rearrange policies on the AM for already-named and -described resources, but our rock-bottom requirement was for Alice to have to add and manage each resource separately, as shown in some of the wireframes, and, I believe, as demonstrated in the SMART implementation. ("Add resource" flows...)

We can start getting a lot more practical about Alice's policy configuration experience on the AM if we *know* that each host will essentially be uploading all the "stuff that needs to be known" about its protected resources. For example, the following user stories makes sense:

- At the same time as Alice registers a new host at the AM, she indicates some default policy she wants to be used for all protected resources residing at the host, such as "the global default policy for this AM" or configuring a new host-specific default policy at the time of registration.

- At her leisure once a new host has been registered at the AM and it has had a chance to upload resource details, Alice customizes new policy instructions at the AM selectively for those resources, such as tagging them so that tag-specific default policies apply to them, or defining resource-specific policies just for them.

- If the uploaded resource details include information on host-specific access scope options that apply to them (a la OAuth), Alice can incorporate into her policy instructions at the AM indications of which scopes of operation are included in which policies, for example "read" vs. "write" scope.

Christian, if you have a chance, can you reply here with links to the relevant prototyping artifacts that you've been creating that illustrate how this works so far? Thanks!

Eve

Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog