On Jul 18, 2013, at 5:00 PM, George Fletcher <[email protected]> wrote:
> So from an authentication/validation perspective, it appears that the data in > the HTTP request must be tied in some secure way to the user identified in > the hint. Otherwise, it's easy for me to impersonate someone by just sending > a different hint. Yes, either the client must be trusted, "trusted but verified", or the "hint" is just a hint ;) > > From an JOSE perspective, it could be the URL to a JWKS that contains my > individual public key data. Yes, that's the kind of thing they're talking about. Use this as an ID and then authenticate/authorize via some other protocol. JOSE, or OpenID or WebID. > > I am a little worried about global correlation with a header like this. The particular worldview here though *wants* a URI to refer to 'you'. Global correlation will indeed be possible if only a single URI is used to refer to you. > > Thanks for the explanation. > > I do agree with Torsten that using the Authorization header via OAuth2 Bearer > seems like simpler solution. This can obviate the need for the back-channel > request for authorization. For an authorization use-case, perhaps. But WebID is, I think, what is proposed here - http://www.w3.org/wiki/WebID JohnK > > Thanks, > George > > On 7/18/13 1:54 PM, Melvin Carvalho wrote: >> >> On 18 July 2013 18:59, George Fletcher <[email protected]> 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. The auth part is simply not in scope, the same as >> with the "From" header. >> >> 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. >> 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. >> >> >> Thanks, >> George >> >> On 7/18/13 12:49 PM, Melvin Carvalho wrote: >>> >>> >>> >>> On 18 July 2013 01:54, John Kemp <[email protected]> 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 <[email protected]> >>> wrote: >>> >>> > >>> > >>> > >>> > On 18 July 2013 01:06, Nat Sakimura <[email protected]> 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" <[email protected]> >>> > Date: 2013/7/18 >>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field >>> > To: Nat Sakimura <[email protected]> >>> > Cc: "[email protected]" <[email protected]> >>> > >>> > >>> > 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\"" >>> >> <[email protected]> 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: [email protected] >>> >>>> Date: Sat, 13 Jul 2013 12:08:37 -0400 >>> >>>> From: Joe <[email protected]> >>> >>>> To: Melvin Carvalho <[email protected]> >>> >>>> CC: public-rww <[email protected]> >>> >>>> >>> >>>> Great job Melvin! >>> >>>> >>> >>>> Data.fm sends the User header already :) >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Jul 13, 2013, at 10:55 AM, Melvin Carvalho >>> >>>> <[email protected]> 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: >>> >>> [email protected] >>> >>> To be removed from the list, send any message to: >>> >>> [email protected] >>> >>> >>> >>> 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 >>> > [email protected] >>> > http://lists.openid.net/mailman/listinfo/openid-specs >>> > >>> > >>> > _______________________________________________ >>> > specs mailing list >>> > [email protected] >>> > http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >>> >>> >>> _______________________________________________ >>> specs mailing list >>> >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >> >> -- >> <Mail Attachment.png> >> > > -- > <XeC.png> _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
