[WG-UMA] UMA for payment or subscriptions

Fri Mar 16 09:44:03 EDT 2012

Thanks for the kind comments!

Right now, in our updated flows... step 2 would amount to iStockPhoto 
asking the AM for a "Requester Permission Token" (RPT). It's possible 
that as part of the policy in the AM for returning an RPT, it would 
decrement the counter. The AM could keep track of which users have 
requested an RPT and only decrement once per user. Note that currently 
this API to request the RPT is not yet defined in the spec.

Basically, the flow would be that when David shows up at iStockPhoto, 
iStockPhoto would request an OAuth token from the Twitter AM for David 
(we are now calling this the Authorization API Token [AAT]). Note that 
iStockPhoto only needs to get this AAT "once" for David. iStockPhoto 
would then make a request to Twitter AM for the RPT passing the AAT as 
the OAuth bearer token to the call and the permission ticket (section 
3.1). If David has successfully provided all the claims for the 
requested permission, then the RPT is returned. It's as part of this RPT 
request that the AM could decrement a counter. That would be additional 
(value add) functionality added by the AM. Does that make sense?

I'm not sure this covers all the possible ways that counters should be 
decremented but it might work for this use case.

The scopes of buy, download and view can easily be represented as per 
section 2.4.1.

One thing that's interesting to me about this use case is that the 
requesting user (RU) David is interacting directly with the host (or 
OAuth resource server) which means in this flow there isn't any 
requester entity, just the requesting user. In this case, I'm not sure 
iStockPhoto needs to verify the returned RPT because by getting one 
returned from the AM, it should meet all the required policy constraints.

Thanks,
George

On 3/16/12 3:38 AM, David Fox wrote:
> Well first, I must say I love the various sunsets you've captured, 
> especially the "Sky's on Fire."
>
> As for fleshing out this use case, let me give an example:
>
> George took several photos of sunsets and waterfalls and wants to put 
> them on iStockPhoto, but restrict the quantity sold and to whom they 
> are sold to... so he points iStockPhoto to his Twitter AM. George then 
> heads over to Twitter's AM and starts mapping what types of 
> "followers" are allowed to dl, buy or view his photos. Now when David 
> heads to iStock to buy George's photo, iStock does the following:
> 1. Checks if David is an iStock member and has sufficient credits to 
> perform the requested action (buying in this case)
> 2. Ask Twitter's AM if David is allowed to buy the photo (which in 
> this case requires he is following George, or perhaps vice versa)
> 3. Everyone lives happily ever after
>
> Once question, though:
> Who keeps track of the number of uses left for the photo? Since the 
> ideal choice would be the AM, when and how would the host tell the AM: 
> "Hey i just used the photo! Decrement the number of uses left please."?
>
> -David
>
> On 3/15/2012 08:25, George Fletcher wrote:
>> Ahh... a use case "after my own heart" ... (I'm a hobbyist 
>> photographer for those who don't know:)
>>
>> It's possible for UMA to help with this use case, but for me the 
>> first question is who is going to collect the money? I'm assuming 
>> that iStockPhoto doesn't want to give up that aspect of the transaction.
>>
>> I could see UMA playing a role as a photo point of sale for sites 
>> that don't support any such mechanism and want to add it easily. For 
>> sure, if the user wants to manage subscriptions across photo sites or 
>> do things like only sell 100 copies and the photo is uploaded at 
>> multiple sites, UMA could provide the mechanism to enable that cross 
>> site.
>>
>> Do you have any more specifics in how you see this use case being 
>> flushed out?
>>
>> One thought I did have that might interesting to explore is the 
>> concept of a "one time use" coupon for someone to access an album or 
>> site. The AM could provide the "one time use code" to the authorizing 
>> user (photographer) and then the photographer could give that out to 
>> someone. They could even tie the "one time use code" to a given 
>> individual if necessary (though I'm not sure it is). Then all the 
>> receiver has to do is present the "one time use code" when presenting 
>> claims in section 3.6 and they'd get access.
>>
>> Thanks,
>> George
>>
>> Shameless plug: http://www.flickr.com/photos/gffphotos/
>>
>> On 3/15/12 3:18 AM, David Fox wrote:
>>> Hey everyone, I'm just getting started with UMA and am personally very
>>> excited at all its potential use cases.
>>>
>>> So far I have one question:
>>>
>>> Could someone explain in more detail how, if possible, UMA could be used
>>> to control access to a photo that costs $10?
>>> The reason I ask, is it would be very cool for UMA to power sites like
>>> iStockphoto and allow photographers to sell their photos but restrict
>>> the amount of uses or even sell their photos on a subscription like model.
>>>
>>> -David
>>> _______________________________________________
>>> WG-UMA mailing list
>>> WG-UMA at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>>
>
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work:george.fletcher at teamaol.com
AOL Inc.                          Home:gffletch at aol.com
Mobile: +1-703-462-3494           Blog:http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter:http://twitter.com/gffletch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20120316/89e493f3/attachment.html 