- From: Nat Sakimura <sakimura@gmail.com>
- Date: Fri, 19 Jul 2013 11:14:40 +0900
- To: John Kemp <john@jkemp.net>
- Cc: George Fletcher <gffletch@aol.com>, "board@openid.net" <board@openid.net>, OpenID Specs Mailing List <specs@openid.net>, public-rww <public-rww@w3.org>
- Message-ID: <CABzCy2C2JUicUr5Md-==5WhO3Yt4nsYQfnu2om+1yaO3qFuSAg@mail.gmail.com>
If that is the case, having IdP URI seems to meet the use case and do not get into the three problems that I have described previously, i.e., security, privacy, and fraud. Nat 2013/7/19 John Kemp <john@jkemp.net> > On Jul 18, 2013, at 5:00 PM, George Fletcher <gffletch@aol.com> 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 <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. 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 <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 list > >>> > >>> specs@lists.openid.net > >>> http://lists.openid.net/mailman/listinfo/openid-specs > >> > >> -- > >> <Mail Attachment.png> > >> > > > > -- > > <XeC.png> > > _______________________________________________ > specs mailing list > specs@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
Received on Friday, 19 July 2013 02:15:09 UTC