- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 19 Jul 2013 18:21:45 -0400
- To: Torsten Lodderstedt <torsten@lodderstedt.net>
- CC: George Fletcher <gffletch@aol.com>, Melvin Carvalho <melvincarvalho@gmail.com>, "board@openid.net" <board@openid.net>, public-rww <public-rww@w3.org>, OpenID Specs Mailing List <specs@openid.net>
- Message-ID: <51E9BBF9.5050508@openlinksw.com>
On 7/19/13 4:16 PM, Torsten Lodderstedt wrote: > Seems to me you want to add the URI needed to initiate the WebID > authentication protocol to HTTP requests. No. It isn't about the WebID+TLS based authentication protocol. It is about opening the door for a plethora of authentication protocols that all lead to Trust Webs. I see a world in which the following are loosely coupled: 1. URIs the denote Agents (people, organizations, software, robots etc.) 2. Structured Documents bearing (or comprised of) structured data that explicitly describe entities denoted using URIs that resolve to said document (i.e., the document and the entity it describes are *linked* via a resolvable URI) 3. Authentication protocols 4. Trust Webs that result from items 1-3 above. > Why don't you just create a WebID-specific header (e.g. "webid") or a > WebID-specific authorization scheme? Or is it imagined to initiate a > OpenID process as well? A WebID is just an HTTP URI that denotes (names) an Agent in such a way that you have a single URI delivering the following: 1. denotation (naming) 2. description location via document address. Links: 1. http://bit.ly/11xnQ36 -- using an HTTP URI without a hash to denote an entity in a manner that resolves to the description of its referent 2. http://bit.ly/15tk1Au -- ditto using a hash based HTTP URI. Kingsley > > regards, > Torsten. > > Am 19.07.2013 17:45, schrieb Kingsley Idehen: >> On 7/19/13 11:10 AM, Torsten Lodderstedt wrote: >>> Hi Kingsley, >>> >>> so your are essentially saying, the user agent (or a similar >>> application) sets a URL, which the server uses in turn to obtain >>> some values. >> >> To be precise, an end-user would (via UI/UX) have the *option* to >> provide a URI that's added to the HTTP payload via an HTTP client >> (e.g., a Browser or other User Agents). >> >>> These values are used to meet access control decisions. Did I get >>> this right? >> >> The header values would then be incorporated into a mechanism for >> protected resource access control and anything else that benefits >> from verifiable identity. >> >>> >>> How does the server ensure the caller is the user represented by >>> this URL? >> >> Through the logic of "shared secrets" and "mirrored claims" . This is >> just about the ability to make an verify claims based on logic. >> >>> So for example, how would you prevent an attacker from sending your >>> user id URL to the server (and in turn impersonating you on this >>> server)? >> >> The server would verify identity based on logic. For instance, it can >> verify that the user agent is being driven by an entity that has >> access to: >> >> 1. private key which was used to make a signature -- stored locally >> and accessed via native OS UI/UX controls (e.g., Keychain on Mac OS X) >> 2. certificate bearing claims that are mirrored in the document to >> which the URI resolves >> 3. any other relationship that the data access policy deems worthy . >> >> Note, this already works. We are just seeking to simplify >> exploitation entry points. >> >> Links: >> >> 1. http://bit.ly/UuWZSI -- various posts about this matter >> 2. http://bit.ly/UDlwc6 -- multi-identifier and multi-protocol based >> identity verification. >> >> Kingsley >>> >>> Am 19.07.2013 um 15:42 schrieb Kingsley Idehen >>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>>: >>> >>>> On 7/19/13 4:14 AM, Torsten Lodderstedt wrote: >>>>> Hi, >>>>> >>>>> could you please shed some light on the use case for the User >>>>> field? What entity sets the value, what entitity uses it for what >>>>> purpose? >>>> >>>> It holds a URI that resolves to a document bearing content that >>>> describes the URIs referent. For example, this document could be >>>> comprised of a machine-readable entity->attribute->value or >>>> subject->predicate->object based relations. >>>> >>>> An end-user application (including browser extensions or plugins) >>>> will set the value. A server will make use of these values e.g., >>>> looking up the URIs to locate the description of the entity denoted >>>> (named) by the URI. It can then use this description as the basis >>>> for ACLs and sophisticated data access policies which are all >>>> driven by logic. >>>> >>>> >>>> Kingsley >>>>> >>>>> Regards, >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> Kingsley Idehen <kidehen@openlinksw.com> schrieb: >>>>> >>>>> On 7/18/13 1:38 PM, Torsten Lodderstedt wrote: >>>>>> I fully agree with George und would like to add: why don't >>>>>> you just use the authorization header to send identity >>>>>> data/credentials/tokens to the server in order to allow for >>>>>> access control? >>>>> >>>>> This is already possible. The requirement here stems from the >>>>> fact that "From:" is bound specifically to mailto: scheme URIs >>>>> (Uniform Resource Identifiers). We are looking to "User:" to >>>>> be the superClass of "From:" which is basically URI scheme >>>>> agnostic. That's it. >>>>> >>>>> [SNIP] >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> >>>>> Kingsley Idehen >>>>> Founder & CEO >>>>> OpenLink Software >>>>> Company Web:http://www.openlinksw.com >>>>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen >>>>> Twitter/Identi.ca <http://Identi.ca> handle: @kidehen >>>>> Google+ Profile:https://plus.google.com/112399767740508618350/about >>>>> LinkedIn Profile:http://www.linkedin.com/in/kidehen >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Kingsley Idehen >>>> Founder & CEO >>>> OpenLink Software >>>> Company Web:http://www.openlinksw.com >>>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen >>>> Twitter/Identi.ca <http://Identi.ca> handle: @kidehen >>>> Google+ Profile:https://plus.google.com/112399767740508618350/about >>>> LinkedIn Profile:http://www.linkedin.com/in/kidehen >>>> >>>> >>>> >>>> >> >> >> -- >> >> 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 >> >> >> >> > -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 19 July 2013 22:22:12 UTC