"Good Practices for Capability URLs W3C Editor's Draft 06 February 2014"

Looks like the capability-as-URL phenomenon is getting some attention at W3C again. Here's a draft you can comment on:

  http://w3ctag.github.io/capability-urls/2014-02-06.html

I think it could benefit from some attention from this community.

Jonathan

On Jan 26, 2014, at 10:41 PM, Jed Donnelley wrote:

> Cap-talk,
> 
> Isn't:
> 
> https://docs.google.com/document/d/10-qbHlInBNtlK3S9awzSTUbKyIkDZxEEr3sgD2VIgaY/edit?usp=sharing
> 
> effectively a capability as data?  The above is shared using the Google 
> Docs mechanism that allows anybody with access to the above string to 
> access the document.
> 
> I looked back through the cap-talk discussion to try to find relevant 
> references for such sharing.  Here's what I found
> 
> On 1/8/2012 9:41 AM, Stiegler, Marc D wrote:
>> Google Docs demonstrates that security geeks can screw up the ui just as effectively with ocaps.
> 
> What did you mean by the above Marc?
> 
> To me it seems that this capability as data sharing via Google Docs is 
> to OCAPs something like the Web is to Xanadu.  Namely, it is about as 
> much as one can do technically to effectively get the functionality of 
> capabilities on an Internet scale.
> 
> I had a delightful experience this evening with my daughter (who's at 
> Yale working on a proposal for work next year), her college roommate, my 
> wife and myself where we were all simultaneously editing a proposal that 
> was a Google Doc shared as above.  We had a Skype voice line also open 
> for high level communication and task assignment, but most of the work 
> was accomplished silently.  We were all able to see what the others were 
> doing on our shared document.
> 
> On 1/4/2012 9:53 AM, Marc Stiegler wrote:
>> Google also offers unguessable urls as an access control choice for
>> Google Docs.
> 
> Right.  It seems to me to work well.  Where are the problems?
> 
> Also from the above:
> 
>> Anyway, using unguessable urls of the type used by Google and CACM and
>> IEEE, you could rest easy knowing that you were not using modern
>> waterken-style webkeys, which have the public key fingerprint in the
>> domain name. That would be a nonstandard and radical leap toward a
>> better future. Don't do that.
> 
> Is that practical at this time?  Does it add sufficient value to be 
> worthwhile?
> 
> On 1/5/2012 11:30 AM, Stiegler, Marc D wrote:
> 
>> The Google Docs implementation of unguessable urls is comically 
>> primitive. It is a good example of how to do 80% of the work and get 
>> 10% of the value.
> 
> I'm not bothered by this.  It seems to me the user interface (sharing 
> strings of URL .data as capabilities) and the essential value don't need 
> to change.  If there are technical improvements that can happen behind 
> the scenes, go for it.  Perhaps they will happen in response to security 
> breeches?
> 
> I'd be happy to see additional features for documents that can be 
> revoked and/or otherwise attenuated, but I'm not sure that such would 
> provide sufficient value to justify the additional complexity to the 
> user interface.  After all, one can always create a copy of the object 
> and re share it to a smaller community - for objects that are 
> documents.  More general types of objects may require more serious 
> protection.
> 
> Has there been more discussion of such URLs as capabilities that I've 
> missed?  I saw Waterken mentioned at some points in this discussion, but 
> I'm not clear what it contributes at this point. Can someone enlighten me?
> 
> I'm delighted to see the progress that's been made in this space. To me 
> it looks like capabilities as data is now an effective Internet 
> reality.  To me this beats the hell out of having all sorts of separate 
> environments for logins with separate sharing via ACLs, etc.
> 
> Maybe a next step (perhaps already implemented?) would be to use 
> something like an svn back end for any such files, with a "blame" 
> mechanism for every identity, etc.?  Horton for responsibility tracking?
> 
> There is of course much work to be done and improvements to be made, but 
> to me this appears to be serious progress.
> 
> Woo hoo!
> 
> --Jed
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk