[WG-UMA] UMA for payment or subscriptions
George Fletcher
george.fletcher at teamaol.com
Fri Mar 16 13:45:11 EDT 2012
Yes, this might work... though it would probably work best if the
decrement happened at token (RPT) verification time. However, that might
cause some issues if re-tries occur. More thought required :)
Thanks,
George
On 3/16/12 12:20 PM, Salvatore D'Agostino wrote:
>
> 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> [mailto:wg-uma-
>
> bounces at kantarainitiative.org <mailto: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 <mailto: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 <mailto:WG-UMA at kantarainitiative.org>
>
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> WG-UMA mailing list
>
> WG-UMA at kantarainitiative.org <mailto: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/13deafab/attachment-0001.html
More information about the WG-UMA
mailing list