[OpenID board] [community] from W3C….Fwd: Proposal: "User" header field

Nat Sakimura sakimura at gmail.com
Fri Jul 19 02:14:40 UTC 2013


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 at jkemp.net>

> On Jul 18, 2013, at 5:00 PM, George Fletcher <gffletch at 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 at 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 at 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 at gmail.com>
> wrote:
> >>>
> >>> >
> >>> >
> >>> >
> >>> > On 18 July 2013 01:06, Nat Sakimura <sakimura at 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 at identitywoman.net>
> >>> > Date: 2013/7/18
> >>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field
> >>> > To: Nat Sakimura <sakimura at gmail.com>
> >>> > Cc: "community at lists.idcommons.net" <community at 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 at 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 at w3.org
> >>> >>>> Date:      Sat, 13 Jul 2013 12:08:37 -0400
> >>> >>>> From:      Joe <presbrey at gmail.com>
> >>> >>>> To:        Melvin Carvalho <melvincarvalho at gmail.com>
> >>> >>>> CC:        public-rww <public-rww at w3.org>
> >>> >>>>
> >>> >>>> Great job Melvin!
> >>> >>>>
> >>> >>>> Data.fm sends the User header already :)
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Jul 13, 2013, at 10:55 AM, Melvin Carvalho <
> melvincarvalho at 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 at lists.idcommons.net
> >>> >>> To be removed from the list, send any message to:
> >>> >>>     community-unsubscribe at 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 at lists.openid.net
> >>> > http://lists.openid.net/mailman/listinfo/openid-specs
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > specs mailing list
> >>> > specs at lists.openid.net
> >>> > http://lists.openid.net/mailman/listinfo/openid-specs
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> specs mailing list
> >>>
> >>> specs at lists.openid.net
> >>> http://lists.openid.net/mailman/listinfo/openid-specs
> >>
> >> --
> >> <Mail Attachment.png>
> >>
> >
> > --
> > <XeC.png>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20130719/f713c313/attachment-0001.html>


More information about the board mailing list