Subject: Activity Identifiers - Draft Submission

From: Scott Perham <[email-masked]>
Date: Thu, 23 May 2019 09:14:40 +0100

Hello everyone,

I’m new to this WG (and all things IETF) so please excuse my naivety!

I have submitted a draft for something that seems to have been an omission
in HTTP (at least in my experience) and something that is re-invented over
and over again with, generally, no thoughts around standardization.

I’m unsure of the processes involved in highlighting this to the
appropriate people and beginning a discussion, so any guidance is much
appreciated. It took a good couple of years to muster up the courage to
actually tell anyone that I submitted a draft (hence the second revision)
but after being part of this mailing list for a little while, everyone
seems friendly enough :D

The draft is located here:
https://datatracker.ietf.org/doc/draft-activity-identifiers/

Go easy on me :P

Thanks,

Scott

*Scott Perham, Platform Architect*
Tel: +44 (0) 7545 826507
Email: [email-masked] <[email-masked]>
Website: www.polystream.com

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 May 2019 13:01:57 +0200

On Thu, May 23, 2019 at 09:14:40AM +0100,
 Scott Perham <[email-masked]> wrote 
 a message of 125 lines which said:

> an omission in HTTP (at least in my experience) and something that
> is re-invented over and over again with,

You apparently don't mention in the draft these reinventions. Specific
and actual examples could be nice (may be in an appendix) to get a
better idea of the problem you want to solve.

More generally, I find it difficult to understand this problem. A
detailed explanation of some use cases could help.

Also, the abstract says "to maintain a record of their
interaction with the server or to track client/server requests through
a disparate system of services" but why not using RFC 6265 here? This
also is worth a discussion in the draft (may be again in an appendix).

---

From: Patrick McManus <[email-masked]>
Date: Thu, 23 May 2019 11:05:45 -0400

Hi Scott.

> I'm unsure of the processes involved in highlighting this to the
appropriate people and beginning a discussion, s

welcome. Rest assured that this mailing list is the right forum to see if
there is broad interest in your idea. (Its my co-chair job to tell you if
you're off topic - you're just fine. thanks for engaging.)

you might look at how it intersects at all with other ongoing efforts
https://github.com/httpwg/http-extensions

protips: as an IETF convention you might name future updates
draft-perham-httpbis-activity-identifiers.. as some IETF tooling will flag
an individual draft with httpbis in its name as of potential interest to
the wg - but that's just a convention and not used by everyone. and lastly,
providing some substantive discussion in email rather than just a pointer
to the draft is more likely imo to get noticed. again, ymmv.

-Patrick

---

From: Scott Morgan <[email-masked]>
Date: Thu, 23 May 2019 11:03:39 -0500

Hi Scott,

   It seems to me that an Activity Identifiers is simply another way to
track a HTTP Session like a cookie.  What are you trying to accomplish that
can't be accomplished with cookies?

On Thu, May 23, 2019 at 10:08 AM Patrick McManus <[email-masked]>
wrote:

>> I have submitted a draft for something that seems to have been an
>> omission in HTTP (at least in my experience) and something that is
>> re-invented over and over again with, generally, no thoughts around
>> standardization.
>>
>>
>>

-- 
Regards,
Scott Morgan
President & CEO
Adligo Inc
http://www.adligo.com
https://www.linkedin.com/in/scott-morgan-21739415
A+ Better Business Bureau Rating
<https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256>

By Appointment Only:
1-866-968-1893 Ex 101
[email-masked]
skype:adligo1?call
Send Me Files Securely:
*https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI
<https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>*

---

From: Scott Perham <[email-masked]>
Date: Thu, 23 May 2019 17:46:14 +0100

Hi Scott,

An “Activity Id”, “Correlation Token”, “Request Id”, etc (I’ve seen the custom header called many things over the years and I will be updating the draft to include specific examples) absolutely _could_ be implemented using cookies, in a similar way that it tends to be implemented using custom headers. However, firstly, my understanding of cookies is that they are meant as a mechanism for storing/maintaining state _across_ stateless requests whereas this use case is more about storing metadata pertaining to the specific request/response pair and secondly this would still require the cookie key to be well-known to the client and all services in the request chain.

I do realise (and it has been pointed out) that my draft lacks some detail, references and examples, which I will rectify 😊 

The primary purpose is to propose a standardised mechanism for API implementers to use as a request flows through potentially a number of services (which often include third-parties that also ask for some form of activity identifier). The value of this header is very typically used in the implementation of idempotent behaviour, request level root cause analysis and activity tracking through services. This _could_ be defined as a well-known cookie, but as this is something that I’ve seen in so many services over the years (almost always implemented as a custom header with an arbitrary name) it feels like it deserves its own, standardised header.

I am, of course, happy to be corrected on any of the above. As I said before, I’m new to this and although I’ve read, referenced and implemented many RFCs over the years, everyone in this WG has _much_ more experience defining and discussing these things than me!

Thanks,
Scott

> On 23 May 2019, at 17:03, Scott Morgan <[email-masked]> wrote:
> 
> Hi Scott,
> 
>    It seems to me that an Activity Identifiers is simply another way to track a HTTP Session like a cookie.  What are you trying to accomplish that can't be accomplished with cookies?
> 
>> On Thu, May 23, 2019 at 10:08 AM Patrick McManus <[email-masked]> wrote:
>> Hi Scott.
>> 
>> > I'm unsure of the processes involved in highlighting this to the appropriate people and beginning a discussion, s
>> 
>> welcome. Rest assured that this mailing list is the right forum to see if there is broad interest in your idea. (Its my co-chair job to tell you if you're off topic - you're just fine. thanks for engaging.)
>> 
>> you might look at how it intersects at all with other ongoing efforts https://github.com/httpwg/http-extensions 
>> 
>> protips: as an IETF convention you might name future updates draft-perham-httpbis-activity-identifiers.. as some IETF tooling will flag an individual draft with httpbis in its name as of potential interest to the wg - but that's just a convention and not used by everyone. and lastly, providing some substantive discussion in email rather than just a pointer to the draft is more likely imo to get noticed. again, ymmv.
>> 
>> -Patrick
>> 
>> 
>> 
>> 
>>> I have submitted a draft for something that seems to have been an omission in HTTP (at least in my experience) and something that is re-invented over and over again with, generally, no thoughts around standardization.
>>> 
>>>  
>>> 
>>> I’m unsure of the processes involved in highlighting this to the appropriate people and beginning a discussion, so any guidance is much appreciated. It took a good couple of years to muster up the courage to actually tell anyone that I submitted a draft (hence the second revision) but after being part of this mailing list for a little while, everyone seems friendly enough :D
>>> 
>>>  
>>> 
>>> The draft is located here: https://datatracker.ietf.org/doc/draft-activity-identifiers/
>>> 
>>>  
>>> 
>>> Go easy on me :P
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Scott
>>> 
>>> Scott Perham, Platform Architect
>>> Tel: +44 (0) 7545 826507
>>> Email: [email-masked]  
> https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI
> 
> 
>

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 23 May 2019 22:20:49 +0300 (EEST)

https://datatracker.ietf.org/doc/draft-activity-identifiers/?include_text=1

> It is very common that implementers of HTTP severs require the ability
> to associate an identifier to an HTTP request and or response, this can
> be for a number of reasons which could include checking for duplicate
> requests,

Is Activity-Id supposed to be nonce ? Different value on every request?

/ Kari Hurtta

---

From: Scott Perham <[email-masked]>
Date: Thu, 23 May 2019 20:54:06 +0100

In a sense - in that it is randomly generated and is quite often used to identify uniqueness in a request (although also often used indirectly in a common use case of finding a specific request in logs, for example). The value would also be returned to the caller (this is also very common even when the caller didn’t send the value first for practical uses like support tickets, etc) and the same value would be used in _all_ requests in that chain. 

So, Client -> Service A -> Service B (and back again) would all contain the same Activity Id.

For RESTful service implementers, this is one of the most common patterns to help with root cause analysis, idempotent behaviour and asynchronous message correlation and is reimplemented and redefined in each use case.

Just two simple examples using widely known services would be Azure requests (client-request-id) and AWS requests (x-amzn-RequestId).

The purpose is to standardise this approach for HTTP service implementers as it’s become increasingly more common for client requests to result in additional requests “behind the scenes”, sometimes asynchronously and requiring correlation.

There are obviously some privacy concerns if the value originated from a client that was programmed to encode sensitive information into the value without the users consent, but I think that the recommendation may be to enforce UUIDs to ensure this is can’t happen.

I’m slowing learning the depth the draft should have been to begin with 😊 

Thanks,
Scott

> On 23 May 2019, at 20:20, Kari Hurtta <[email-masked]> wrote:
>

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 23 May 2019 22:10:25 +0200 (CEST)

On Thu, 23 May 2019, Scott Perham wrote:

> The primary purpose is to propose a standardised mechanism for API 
> implementers to use as a request flows through potentially a number of 
> services (which often include third-parties that also ask for some form of 
> activity identifier).

The spec is also not very clear on exactly for what server/origins the client 
should send this proposed header to. Above here you seem to imply that it 
could be to more servers than the origin that sent the first response header? 
And for how long? Forever?

I'll join the choir: this sounds like cookies - with more holes in the spec.

-- 

  / daniel.haxx.se

---

From: Scott Perham <[email-masked]>
Date: Thu, 23 May 2019 21:30:33 +0100

The draft definitely needs fleshing out, this shall be done as soon as I can.

The header would be sent by the client of a  service (not a browser natively or automatically, for example) and only for those services that require it (as usually defined in a service API documentation and as it does today, but for arbitrary headers). For any request that originates from the service as a direct result of the original request and _before the response is returned from the service_ the implementers of that service can include the same header value in the subsequent requests. This would be repeated with a new (random) value on each request sent from the client to that service.

This allows the implementers to trace the activity through subsequent service calls. As I said, this is a pattern used by a great many API implementers and is very common practice in RESTful service development, but there is no standardised mechanism for doing so, therefore each service defines their requirements for the header name and value independently.

The value of the header is not used in anyway to correlate future or past requests from the client and is typically only persisted by service implementers by way of logging. This differs from cookies in that it is not a mechanism for persisting state across requests, but a mechanism for attaching very specific, ephemeral metadata to individual requests.

Thanks,
Scott

> On 23 May 2019, at 21:10, Daniel Stenberg <[email-masked]> wrote:
> 
>> The primary purpose is to propose a standardised mechanism for API implementers to use as a request flows through potentially a number of services (which often include third-parties that also ask for some form of activity identifier).
> 
> The spec is also not very clear on exactly for what server/origins the client should send this proposed header to. Above here you seem to imply that it could be to more servers than the origin that sent the first response header? And for how long? Forever?
>

---

From: Scott Perham <[email-masked]>
Date: Thu, 23 May 2019 21:35:50 +0100

Hi Rob,

Yes, it is solving a tracing problem... and it does look like that recommendation is quite close, although arguably a fair bit more complicated.

I will muse over it for a while... 

Thanks,
Scott

> On 23 May 2019, at 21:14, Robert Collins <[email-masked]> wrote:
> 
>> On Fri, 24 May 2019 at 07:56, Scott Perham <[email-masked]> wrote:
>> 
>> I’m slowing learning the depth the draft should have been to begin with
> 
> Are you looking to solve the once-and-only-once problem, or the
> tracing problem, which I see as related but separate.
> 
> On the latter see https://www.w3.org/TR/trace-context/ for some recent
> standardisation work, as well as the now merging opencensus +
> opentracing projects which I expect this time around *will* define a
> wire format.
> 
> -Rob

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 24 May 2019 18:29:10 +1200

On 24/05/19 8:30 am, Scott Perham wrote:
> The header would be sent by the client of a  service (not a browser
> natively or automatically, for example) and only for those services
> that require it (as usually defined in a service API documentation
> and as it does today, but for arbitrary headers). For any request
> that originates from the service as a direct result of the original
> request and _before the response is returned from the service_ the
> implementers of that service can include the same header value in the
> subsequent requests. This would be repeated with a new (random) value
> on each request sent from the client to that service.
> 
> This allows the implementers to trace the activity through subsequent
> service calls.

Not just implementers. Any party observing that traffic will be able to
track individual clients (aka users and their specific devices) activity
down to the resolution of specific HTTP messages. A great way to leak
lots of privacy information which is currently well obfuscated by HTTP
stateless design.

That same view can be used by a malicious observer to determine what
backends to attack (and with what messages) to attack the application
from the "inside". For example; bypassing a front-end input validator
that uses HTTP to contact the data storage filesystem for records.

IMHO this is a feature which is best left unspecified so applications
can continue re-implementing as they are. Using a varied set of header
names, and per-service handling behaviour is a *good* thing.

What looks like a mess at first glance is an active barrier at each
level of API sub-transaction ("call") against that malicious observer
case. Each service by-default prunes the headers containing the tracker
with privacy/security revealing information - simply by not knowing
which varied headers to copy across.
  If it became a standard header, any two or more services using it
could not be used together without adding the risk of the above attack
becoming possible.

AYJ

---

From: Robert Collins <[email-masked]>
Date: Fri, 24 May 2019 08:14:17 +1200

-Rob