[WG-UMA] UMA for payment or subscriptions

Fri Mar 16 12:20:42 EDT 2012

Could you have a token with x units (photos) so its expiry might not only be 
on time but on also uses.

From: wg-uma-bounces at kantarainitiative.org 
[mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of George Fletcher
Sent: Friday, March 16, 2012 11:49 AM
To: Thomas Hardjono
Cc: wg-uma at kantarainitiative.org
Subject: Re: [WG-UMA] UMA for payment or subscriptions

Comments inline...

On 3/16/12 10:21 AM, Thomas Hardjono wrote:

Hi David, George,

Hmmm, this is an interesting use-case.
Just so that we are all on the same page:

  host = iStockPhoto.
  AM = Twitter-AM.
  Requesting User (RU) = David.
  Authorizing User (AU) = George.
  No Requester.

I believe George is suggesting that iStockPhoto acts as both Host and 
Requester.  See below.

Yes :)

From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-
bounces at kantarainitiative.org] On Behalf Of George Fletcher
Sent: Friday, March 16, 2012 9:44 AM
To: David Fox
Cc: wg-uma at kantarainitiative.org
Subject: Re: [WG-UMA] UMA for payment or subscriptions

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.

My understanding from the current version of the flows and spec is that 
iStockPhoto (host) asks for a permission-tickets from the Twitter-AM (but not 
an RPT token). It is the Requester that should be asking for RPT (after the 
Requester itself gets an AAT from the AM). But in this case we don't have a 
Requester.

Are you suggesting that in this use-case the host (iStockPhoto) also acts as a 
Requester?  Hmmm, that would be interesting... :)

Yes, that is what I am suggesting. While iStockPhoto doesn't really need the 
RPT, it does need to know whether David has met the policy associated with the 
resource. Only the AM can make that determination.

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?

This also points to iStockPhoto being the Requester, driven by David (the 
Requesting User). So now iStockPhoto needs to keep both the AAT token and RPT 
token for David's account. If another requesting user (say Erica) comes along 
and does the exact same thing as David, then iStockPhoto (as host) can re-use 
the same AAT token it already possesses.  iStockPhoto need only get a new RPT 
token for Erica.

Actually, iStockPhoto will need an AAT for David and an AAT for Erica because 
when there is a requesting user, the AAT represents the 
Erica:TwitterAM:iStockPhoto tuple. This is important, because when iStockPhoto 
requests the RPT passing the permissions ticket and using the AAT as the OAuth 
Bearer token, it's the AAT that identifies to the AM the requesting user (i.e. 
Erica or David).

Given that in this use-case iStockPhoto is acting as both Requester AND Host, 
perhaps its best for iStockPhoto to maintain the counter/decrements.

Yes, that is always an option. I was looking at how the AM might perform that 
role. If George had uploaded the same photo to multiple stock photo sites and 
wants to restrict a total amount sold across all stock photo sites, then the 
AM is best suited to track that policy.

Thanks,
George

cheers,

/thomas/

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20120316/0fdb88d8/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6113 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20120316/0fdb88d8/attachment-0001.bin 