- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 18 Jul 2013 22:30:16 +0200
- To: Torsten Lodderstedt <torsten@lodderstedt.net>
- Cc: George Fletcher <gffletch@aol.com>, "board@openid.net" <board@openid.net>, public-rww <public-rww@w3.org>, OpenID Specs Mailing List <specs@openid.net>
- Message-ID: <CAKaEYh+gfPC6C6dDv7kO_erw73Exvha759T7BfpWwqXUrY1f7Q@mail.gmail.com>
On 18 July 2013 20:28, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > Hi Melvin, > > the straightforward way would be to create another authz scheme. BUT the > most important question is, what do you want to achieve? > > 1) You just need a hint? So you don't rely on this data for access > control. Use any header you want. > 2) You want to control access to a resource. This requires > trustworthy/authenticated identity data. Here the obvious way is an OAuth > access token (authorization header, BEARER scheme). In your specific case, > it might be required to even specify the tokens format. JSON web tokens > would be the right choice in my opinion. > > Why does you concept require the user id to be a URL? > Hi Thorsten, the concept does not require a URL, but it needs a header that does not *forbid* a URL, and this was the issue with "From". The reason is that many people host user profiles on a web URL, so we would like to be inclusive of that group of people. I'm not 100% familiar with all the latest changes to OAuth / OpenID Connect, but if there is something in those specifications that could be reused to send an identity to a server, and you could point me to what to read up on, I'd be grateful. > > Regards, > Torsten. > > > > Melvin Carvalho <melvincarvalho@gmail.com> schrieb: > >> >> >> >> On 18 July 2013 19:38, Torsten Lodderstedt <torsten@lodderstedt.net>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? >>> >> >> Hi Thorsten, thanks for the tip. If there's an existing way to identify >> to a server a user's URL via a header, I'd love to learn more about that. >> It's preferable to reuse existing tools, if possible, than to create >> something new. >> >> >>> >>> >>> >>> George Fletcher <gffletch@aol.com> schrieb: >>> >>>> 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? >>>> >>>> Thanks, >>>> George >>>> >>>> On 7/18/13 12:49 PM, Melvin Carvalho wrote: >>>> >>>> >>>> >>>> >>>> On 18 July 2013 01:54, John Kemp <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> >>>>> wrote: >>>>> >>>>> > >>>>> > >>>>> > >>>>> > On 18 July 2013 01:06, Nat Sakimura <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> >>>>> > Date: 2013/7/18 >>>>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field >>>>> > To: Nat Sakimura <sakimura@gmail.com> >>>>> > Cc: "community@lists.idcommons.net" <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> 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 >>>>> >>>> Date: Sat, 13 Jul 2013 12:08:37 -0400 >>>>> >>>> From: Joe <presbrey@gmail.com> >>>>> >>>> To: Melvin Carvalho <melvincarvalho@gmail.com> >>>>> >>>> CC: public-rww <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> 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 >>>>> >>> To be removed from the list, send any message to: >>>>> >>> 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 >>>>> > http://lists.openid.net/mailman/listinfo/openid-specs >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > specs mailing list >>>>> > specs@lists.openid.net >>>>> > http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> specs mailing listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>>> -- >>>> [image: George Fletcher] <http://connect.me/gffletch> >>>> >>>> ------------------------------ >>>> >>>> specs mailing list >>>> specs@lists.openid.net >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>
Received on Thursday, 18 July 2013 20:30:46 UTC