Re: web app market wordpress install

On 8/27/12 10:54 PM, Manu Sporny wrote:
> On 08/26/2012 03:33 PM, Kingsley Idehen wrote:
>> Good start!
> I don't know how much you know about PaySwarm, Kingsley, so forgive me
> if you already know this stuff.
>
>> The app provider has to make a document that describes the terms of
>> use.
> All PaySwarm transaction today use a license document, you can view the
> one that is used in the development system here:
>
> http://purl.org/payswarm/licenses/blogging
>
> This license can, of course, be replaced with one that is specific to
> the product or service being sold.
>
>> Ultimately, this will be based on terms from a product and services
>> license ontology.
> Yes, unfortunately that ontology isn't really production-ready as far as
> we see it, so it'll have to be a text document for now.

Yes, but there are license ontologies that can be sourced from 
elsewhere. That's the beauty of Linked Data.

> Keep in mind,
> though, that the license is expressed as linked data in the actual
> digital contract.

If it exists in Linked Data form then the terms used to craft the graph 
must have come from somewhere. Do you have a link to the Linked Data in 
question?

> So, there can be certain assertions made by the
> license that are machine readable (such as number of reproductions of
> the digital good that can be made, for 3D printing scenarios).
>
>> The app provider signs the document.
> This also happens in PaySwarm today.
>
>> The app provider encrypts the document using the public key of an
>> authorized user.
> The encryption happens as a part of the HTTPS transport between the
> vendor and the buyer via the PaySwarm Authority.

Yes, but in my case, like S/MIME, I want the following to be transferred:

1. encrypted license document
2. signature
3. app developers public key.

>   It doesn't have to
> happen this way, but it's the easiest for developers to implement. The
> whole process can happen P2P between the parties. We haven't spec'd that
> part out yet, but the base specs do support this sort of behavior.

I'll take a closer look to see how I can mesh these worlds.
>
>> The app developed by the provider has to be able to perform the
>> following tasks:
>>
>> 1. decrypt the license doc using the public key of the authorized
>> user -- so app issuance UX has to capture public key of licensee
>> typically by de-referencing a WebID that's used to watermark an
>> X.509 cert. to a graph that holds said public key
> It's a bit simpler than that with PaySwarm. The digital contract
> contains a "lite" WebID URL for the buyer, the vendor, and the PaySwarm
> Authority. You can follow-your-nose from there. For example, if a
> contract was signed with the key:
>
> https://dev.payswarm.com/i/manu/keys/1
>
> You can go that that URL to find out the owner of the key... then go to
> the owner URL (eventually) and get JSON-LD or RDFa out of the page.

Interesting.

>
>> 2. verify license document via its signature using the public
>> associated with the signature -- this is like normal software code
>> signing pattern
> Yep, not only for the license document, but the entire transaction. The
> entire digital contract is signed, including the item you purchased, the
> license under which it was sold, who got paid how much, and any other
> Linked Data that the vendor placed into the description of the product
> and license.

Great!

>
>> 3. operate under terms of the license document -- so enforce the
>> usage constraints in the license.
> This is outside of the scope of PaySwarm... but there is nothing keeping
> an app from reading the license and limiting functionality based on what
> is described in the digital contract / license.

This might be the little addition introduced by this particular usage 
scenario.

>
> So, I think PaySwarm handles everything you've outlined above. We don't
> go as far as requiring X.509 certificates with embedded WebIDs... but
> that's a tiny implementation detail. What we do have are URLs that identify:
>
> 1. Assets for Sale
> 2. Licenses
> 3. Public Keys
> 4. Identities
> 5. Digital Contracts
>
> All of the information above is digitally signed, so there is
> verifiability throughout the entire stack.

This is very close, we certainly don't have much work to do beyond 
little tweaks. Great!
>
> (Melvin, feel free to forward this e-mail to RWW)

I've done that :-)
>
> -- manu
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen