- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 18 Jul 2013 14:03:50 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: George Fletcher <gffletch@aol.com>, John Kemp <john@jkemp.net>, OpenID Specs Mailing List <specs@openid.net>, "board@openid.net" <board@openid.net>, public-rww <public-rww@w3.org>
- Message-ID: <51E82E06.4020309@openlinksw.com>
On 7/18/13 1:54 PM, Melvin Carvalho wrote: > > > > On 18 July 2013 18:59, George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> wrote: > > I'm a little confused... first the spec says > > The current text includes: "It SHOULD NOT be used as an > insecure form of access protection." -- This is the same as > the "From" header (which may contain an email address). Do > you think stronger wording is required. > > and then you follow that up with > > In particular, one thing we are working on in the Read Write > Web Community Group is fine grained access control for writing > or appending a file. It's helpful to know who is trying to > make a change before returning e.g. SUCCESS or FORBIDDEN > response codes. > > Since there is no authentication or proof associated with the > 'User' header, how can you use it for fine grained access control? > Is the expectation that the value is an untrusted identification > of the user that can be used to optimize certain use cases? If so, > I'm not sure which use cases it helps? > > > That you are able to identify yourself does not imply that verifying > that identity is impossible. Correct! > The auth part is simply not in scope, the same as with the "From" header. Correct! > > In practice what we tend to do is dereference the URL and look for a > public key, then use PKI for verification, but that's only one way to > do auth. We tend to leave Identity and Web of Trust matters to logic. The logic in question might be out-of-band or in-band (e.g, via RDF based Linked Data where the Logic or Blogic is part of the Data). > There are many ways to do so, as John pointed out, you could delegate > to your OpenID provider too, so you get the best of all worlds. Yes! Identity, Authentication Protocols, and Logic are all loosely coupled :-) Kingsley > > Thanks, > George > > On 7/18/13 12:49 PM, Melvin Carvalho wrote: >> >> >> >> On 18 July 2013 01:54, John Kemp <john@jkemp.net >> <mailto:john@jkemp.net>> wrote: >> >> The problem, in general, with putting identifiers in HTTP >> requests is that they get mistaken for being real things. >> User is no worse (or better) than User-Agent. Remember all of >> the mess about how websites would attempt to render sites to >> clients based on the contents of the User-Agent header, and >> how long it's taken for something better to appear for that task? >> >> >> Yes, I agree that User-Agent can be slightly problematic. Some >> spiders such as googlebot actually put their URL in the >> User-Agent header, as a semi-colon separated list, which is not >> ideal. The user and the user-agent are different concepts. The >> proposed header would be a simpler solution, imho. >> >> >> 'Just a hint' doesn't tell anyone what this is really going >> to be used for. Are there use-cases written down, in addition >> to a syntax? >> >> >> The current text includes: "It SHOULD NOT be used as an insecure >> form of access protection." -- This is the same as the "From" >> header (which may contain an email address). Do you think >> stronger wording is required. >> >> The use case is the same as "From" in fact, my ideal would have >> been just to loosen the scope of "From" but there was pushback >> from the IETF on this, with the suggestion to think of another >> header name. >> >> In particular, one thing we are working on in the Read Write Web >> Community Group is fine grained access control for writing or >> appending a file. It's helpful to know who is trying to make a >> change before returning e.g. SUCCESS or FORBIDDEN response codes. >> >> >> On a more specific level, this looks like "On-behalf-of" - a >> more indicative name than "user" for the seemingly potential >> usage (this request is performed on behalf of the user X)? >> >> >> I'd be very happy to reuse something existing, so long as it >> allowed URLs and email address too. If I'm correct, On-behalf-of >> is email specific? >> >> >> I'm not sure why OpenIDs couldn't appear in this header, >> FWIW. The recipient could run OpenID protocol with the >> client, regarding the identifier sent in the header. That >> would allow "verification" of the OpenID to occur, wouldn't it? >> >> >> Well I hadnt thought of that, but yes that could work quite >> well! One of the perceived issues with OpenID as a URL (dating >> back as far as Yadis) was that the UX for typing in an HTTP URL >> lead to a loss of conversions. If this could be done by the >> software and may save some typing, especially on mobile devices. >> The same technique could be used with PKI if the URL contained a >> public key and the (rich) client could store the private key. I >> think that will become a more valuable use case next year when >> crypto on the browser becomes a REC >> >> >> John >> >> On Jul 17, 2013, at 7:41 PM, Melvin Carvalho >> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> >> wrote: >> >> > >> > >> > >> > On 18 July 2013 01:06, Nat Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>> wrote: >> > Hi. >> > >> > I am forwarding the mail in the identity commons list. >> > >> > Apparently, there is an initiative at W3C proposing a new >> "identity" header, which I believe is actually harmful for >> the general public. Simple web sites are going to take it as >> authenticated identity and thus will cause identity theft of >> their users. >> > >> > Their proposal is to include >> > >> > User: http://this.is.the/user/identifier >> > >> > in the HTTP header. >> > >> > Could those of you active in W3C reach out to them? >> > >> > As I have written below, if it were to just include the IdP >> address as a hint, I am kind of fine. >> > >> > Thanks for sharing this. Since this was my proposal, I >> hope I can shed a bit of light light. >> > >> > Firstly, it's not the W3C, simply a group of people >> brainstorming in the a W3C hosted forum (aka community >> groups). The proposal has no official standing, but if there >> are no objections, the idea is to try and push the idea upstream. >> > >> > Yes, the idea is that it is just a hint. Note the text: >> > >> > "The client SHOULD NOT send the User header field without >> the user's approval, as it might conflict with the user's >> privacy interests or their site's security policy. It is >> strongly recommended that the user be able to disable, >> enable, and modify the value of this field at any time prior >> to a request." >> > >> > We asked the IETF if we could use the "From" header for >> this, but the feedback is that "From" is restricted to email, >> and this would be difficult to change. The suggestion was to >> come up with a new header. Very happy to have feedback, I've >> followed IIW work for many years. >> > >> > >> > Best, >> > >> > Nat >> > >> > ---------- Forwarded message ---------- >> > From: Kaliya "Identity Woman" >> <kaliya-lists@identitywoman.net >> <mailto:kaliya-lists@identitywoman.net>> >> > Date: 2013/7/18 >> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" >> header field >> > To: Nat Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>> >> > Cc: "community@lists.idcommons.net >> <mailto:community@lists.idcommons.net>" >> <community@lists.idcommons.net >> <mailto:community@lists.idcommons.net>> >> > >> > >> > Yes Nat, Thats sort of what I got from reading it. >> > >> > Who among us is very active in the W3C world? >> > >> > If no one should we be figuring out who should be? >> > >> > Should we write them a letter asking them to send >> "identitish" proposals to IIW? or other forums for good input? >> > >> > Maybe we should write something that is like understanding >> identity basics for technical specification folks across a >> range of standards bodies? >> > >> > - Kaliya >> > >> > On Jul 17, 2013, at 3:32 AM, Nat Sakimura wrote: >> > >> >> Whoa, what's that?! >> >> >> >> That's not only useless but actually harmful. >> >> >> >> I can kind of see some utility in sending the IdP address, >> but not the user. >> >> >> >> =nat via iPhone >> >> >> >> On Jul 16, 2013, at 7:39, "Kaliya \"Identity Woman\"" >> <kaliya-lists@identitywoman.net >> <mailto:kaliya-lists@identitywoman.net>> wrote: >> >> >> >>> Hi folks, >> >>> Apparently the W3C wants to send "user" names along in >> HTTP headers. >> >>> I thought some folks who know about identity and how it >> does/could/should work might be up for chiming in over there. >> >>> It seems like Authentication of identity might be a >> good thing rather then just assertion. >> >>> - Kaliya >> >>> >> >>> >> >>> Begin forwarded message: >> >>> >> >>>> From: Christine >> >>> >> >>>> As you know, I'm a big proponent of open standards. For >> this reason I monitor many groups. You might be interested in >> the W3C Read Write Web community group: >> http://www.w3.org/community/rww/ >> >>>> >> >>>> I sent you a message a few weeks ago about Tabulator. >> >>>> >> >>>> See below messages about User header field. If you are >> not already a member, I recommend you join and contribute! >> >>>> >> >>>> Christine >> >>>> >> >>>> >> >>>> -------- Original Message -------- >> >>>> Subject: Re: Proposal: "User" header field >> >>>> Resent-Date: Sat, 13 Jul 2013 16:19:02 +0000 >> >>>> Resent-From: public-rww@w3.org <mailto:public-rww@w3.org> >> >>>> Date: Sat, 13 Jul 2013 12:08:37 -0400 >> >>>> From: Joe <presbrey@gmail.com >> <mailto:presbrey@gmail.com>> >> >>>> To: Melvin Carvalho <melvincarvalho@gmail.com >> <mailto:melvincarvalho@gmail.com>> >> >>>> CC: public-rww <public-rww@w3.org >> <mailto:public-rww@w3.org>> >> >>>> >> >>>> Great job Melvin! >> >>>> >> >>>> Data.fm sends the User header already :) >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Jul 13, 2013, at 10:55 AM, Melvin Carvalho >> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> >> wrote: >> >>>> >> >>>>> I would be nice to be able to identify a user in HTTP, >> especially with read/write protocols and access control, it >> can be important to know who is trying to change something. >> >>>>> >> >>>>> There has been some discussion on whether the "From" >> header can be used to identify a user in HTTP, and my from >> most people is that this would be a good candidate to send a >> user, but for historical reasons it's limited to email, and >> changing this would perhaps get some pushback from the IETF. >> >>>>> >> >>>>> The suggestion has been to choose another header, so I >> thought that "User" might be a good candidate, since we have >> User Agent arleady. >> >>>>> >> >>>>> Here's the proposed text: >> >>>>> >> >>>>> [[ >> >>>>> User >> >>>>> >> >>>>> The User request-header field, if given, SHOULD contain >> an identifier for the human user who controls the requesting >> user agent. The address SHOULD be machine-usable, as defined >> by the "URI General Syntax" RFC 3986 >> >>>>> User = "User" ":" URI >> >>>>> >> >>>>> An example is: >> >>>>> >> >>>>> User: http://www.w3.org/People/Berners-Lee/card#i >> >>>>> This header field MAY be used for logging purposes and >> as a means for identifying the source of invalid or unwanted >> requests. It SHOULD NOT be used as an insecure form of access >> protection. The interpretation of this field is that the >> request is being performed on behalf of the person given, who >> accepts responsibility for the method performed. In >> particular, robot agents SHOULD include this header so that >> the person responsible for running the robot can be contacted >> if problems occur on the receiving end. >> >>>>> >> >>>>> >> >>>>> The client SHOULD NOT send the User header field >> without the user's approval, as it might conflict with the >> user's privacy interests or their site's security policy. It >> is strongly recommended that the user be able to disable, >> enable, and modify the value of this field at any time prior >> to a request. >> >>>>> >> >>>>> ]] >> >>>>> >> >>>>> Feedback welcome! >> >>>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> ____________________________________________________________ >> >>> You received this message as a subscriber on the list: >> >>> community@lists.idcommons.net >> <mailto:community@lists.idcommons.net> >> >>> To be removed from the list, send any message to: >> >>> community-unsubscribe@lists.idcommons.net >> <mailto:community-unsubscribe@lists.idcommons.net> >> >>> >> >>> For all list information and functions, see: >> >>> http://lists.idcommons.net/lists/info/community >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=nat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> > >> > _______________________________________________ >> > specs mailing list >> > specs@lists.openid.net <mailto:specs@lists.openid.net> >> > http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> > _______________________________________________ >> > specs mailing list >> > specs@lists.openid.net <mailto:specs@lists.openid.net> >> > http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> _______________________________________________ >> specs mailing list >> specs@lists.openid.net <mailto:specs@lists.openid.net> >> http://lists.openid.net/mailman/listinfo/openid-specs > > -- > George Fletcher <http://connect.me/gffletch> > > -- 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 Thursday, 18 July 2013 18:04:20 UTC