Subject: [Id-event] Summary of working session discussion

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Mar 2018 13:43:08 +0000

We held a couple of brief sessions over the last couple days.

We talked about the issue of breaking up the delivery document, multiple delivery methods, and optionality.

Some observations:

1. Yaron indicated that the IETF will likely require one method be MTI (mandatory to implement).

While PUSH has better scale (because it does not need HTTP Long Polling), the POLL method has broader utility due to the presence of receivers with firewalls, gateways (IoT devices), or are mobile applications that cannot implement endpoints to receive HTTP POSTs.

2.  If POLL is chosen as the MTI method, many will still likely prefer PUSH and so that will likely get implemented sooner by some

3.  There was a general feeling that the delivery draft should stay as one draft.

Annabelle will present her recommendations at the formal meeting on Friday where we can get broader input.

Thanks everyone.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 21 Mar 2018 14:25:46 +0000

Small correction: I will present a summary of the draft, current status, and overview of the open questions.

I will reserve my recommendations for the discussion to follow. ☺

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Wednesday, March 21, 2018 at 1:44 PM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] Summary of working session discussion

Some observations:

Thanks everyone.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Adam Dawes <[email-masked]>
Date: Wed, 21 Mar 2018 07:26:22 -0700

On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <[email-masked]> wrote:

> While PUSH has better scale (because it does not need HTTP Long Polling),
> the POLL method has broader utility due to the presence of receivers with
> firewalls, gateways (IoT devices), or are mobile applications that cannot
> implement endpoints to receive HTTP POSTs.
>

Receivers with this issue can mitigate the problem by implementing an
intermediary routing service which will accept messages from push
transmitters and buffer them until their clients poll for them.

>
> 2.  If POLL is chosen as the MTI method, many will still likely prefer
> PUSH and so that will likely get implemented sooner by some
>

Google has no plans to implement polling due to the fact that we cannot
effectively rate limit the polling interval from potentially hundreds of
thousands of clients. This represents a DDoS risk to us. This is especially
true if our service were to go down for a non-trivial period of time and
our universe of clients would likely all hammer us once we got online again.

> 3.  There was a general feeling that the delivery draft should stay as one

Interested to hear more on the rationale for this.

> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Mar 2018 08:42:17 -0700

Thanks for the summary Phil.

Comments inline...

> (mandatory to implement).

It would be very useful to point to other working groups and specs where
this was the case.

What is the mechanism by which a specific delivery method is made MTI?
Which meta document specifies that?

What happens if a provider is not implementing the MTI delivery method?
What does that exactly mean?

Just trying to understand what the process is.

> implement endpoints to receive HTTP POSTs.

To me it is very unlikely that IoT or mobile devices will use POLL (or
PUSH). They will need some other delivery methods appropriate for their
architecture. Having the current PUSH or POLL mandatory for these cases
does not make sense to me,

> PUSH and so that will likely get implemented sooner by some

Many will simply not implement POLL if what they need is PUSH, and vice
versa. Again, I don't see how the working group can pick any delivery
method and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?

> 3.  There was a general feeling that the delivery draft should stay as one

I don't see how that is helping, but if implementors can chose either PUSH
or POLL from the current draft then that's fine. But in that case splitting
should also be acceptable.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 21 Mar 2018 16:05:00 +0000

Hi Marius,

The decision about whether we need to have an MTI protocol and which one 
it should be is up to the WG consensus, like everything else. But with 
my WG chair hat on, it is my strong conviction that we need to have one 
MTI method to encourage interoperability and reduce fragmentation. This 
is based on my IETF experience, and not on any meta-document as far as I 
can tell. Just think of implementers that are not part of the WG, and 
just read the RFCs two years from now. They need to have a clear message 
which method will allow them the best (though maybe not perfect) 
interoperability. Also, I personally do not have a preference which of 
the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", in other 
words if you choose to not implement an MTI protocol/feature, nobody is 
going to come after you and punish you. It is between you and your 
market. I fully expect some of the WG participants to only implement the 
non-MTI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up 
and simplify the process, compared to running two docs in parallel. They 
do have enough commonalities.

Thanks,
	Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     We talked about the issue of breaking up the delivery document,
>     multiple delivery methods, and optionality.
> 
>     Some observations:
> 
> Just trying to understand what the process is..
> 
> 
>     While PUSH has better scale (because it does not need HTTP Long
>     Polling), the POLL method has broader utility due to the presence of
>     receivers with firewalls, gateways (IoT devices), or are mobile
>     applications that cannot implement endpoints to receive HTTP POSTs.
> 
> 
>     2.  If POLL is chosen as the MTI method, many will still likely
>     prefer PUSH and so that will likely get implemented sooner by some
> 
> 
> I don't see how that is helping, but if implementors can chose either 
> PUSH or POLL from the current draft then that's fine. But in that case 
> splitting should also be acceptable.
> 
> 
> 
>     www.independentid.com <http://www.independentid.com>
>     [email-masked] <mailto:[email-masked]>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Mar 2018 03:04:10 -0700

Hi Yaron,

I don't think anyone can argue with the desire for strong interop and less
complexity.

Wearing our implementor hats, what delivery method would optimally cover
all use cases? Do we want a delivery method that in theory can cover most
use cases, but it is suboptimal for many of them? How would a mobile or IoT
device use the current PUSH or POLL methods?

We are not talking about alternative delivery methods for the same use
case, but different methods for each separate use case. I totally agree
that as a workinggroup we should support one method per use case, for
example one method for HTTP receivers sitting behind firewalls. I am using
"use case" in a generic way, more like "profile".

Why declare one method as MTI when it is clear that it will not work for
many use cases and that implementors for those use cases will be forced to
ignore the MTI?

Regarding the current delivery draft, why do you think that keeping the two
methods together is beneficial? The overlap between the two is minimal.
Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. The PUSH method is
already implemented and more implementation will come online soon. The POLL
method has no implementation yet, as far as I know. By keeping them
together we hold back one and put pressure to rush the other. That's
lose-lose.

2. With two methods in one drafts it is very ambiguous what is MTI. With
two separate drafts each implemetor can chose what works for their use
cases. Interop will work out based on use cases, I don't think we have to
force it.

The clear message for implementors two years from now would be a clear
description for each method as to what use cases it is applicable to. No
confusion at all, if you are behind a firewall then POLL is your only
option. If you are delivering to IoT then whatever method works for that
use case (we don't have one yet).

I asked about a meta-document from a practical point of view. How/where
will the MTI delivery method be defined? Same with IETF police, maybe you
misunderstood. I am not worried about implementors disregarding
recommendations. Since the unit for specifications are RFCs, how can some
RFC be declared as MTI? In what context? Again, from a practical editorial
point of view.

Guidance would be very useful IMO.

Thanks,
Marius

Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer <[email-masked]>
wrote:

> it should be is up to the WG consensus, like everything else. But with my
> WG chair hat on, it is my strong conviction that we need to have one MTI
> method to encourage interoperability and reduce fragmentation. This is
> based on my IETF experience, and not on any meta-document as far as I can
> tell. Just think of implementers that are not part of the WG, and just read
> the RFCs two years from now. They need to have a clear message which method
> will allow them the best (though maybe not perfect) interoperability. Also,
> I personally do not have a preference which of the methods becomes MTI.
>
> going to come after you and punish you. It is between you and your market.
> I fully expect some of the WG participants to only implement the non-MTI
> method.
>
> I think keeping the two methods within the same document will speed up and
> simplify the process, compared to running two docs in parallel. They do
> have enough commonalities.
>
> Thanks,
>         Yaron
>
>> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: William Denniss <[email-masked]>
Date: Thu, 22 Mar 2018 11:29:50 +0000

On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <[email-masked]>
wrote:

> Regarding the current delivery draft, why do you think that keeping the
> two methods together is beneficial? The overlap between the two is minimal.
> I asked about a meta-document from a practical point of view.. How/where

Speaking to one draft I worked on where we faced this decision, PKCE
Section 4.2 <https://tools.ietf.org/html/rfc7636#section-4.2> defined two
methods to transform the code challenge, plain text (no transformation),
and SHA256.

"S256" is declared as MTI in the spec, and "plain" is not. In this case we
actually say "Mandatory to Implement", but gating SHA256 with a "MUST" and
the "plain" with a "MAY" would have achieved the same effect.

I advocated for making S256 MTI (when I first reviewed the draft, both were
given equal weighting) so that native app clients would not need to perform
discovery on the server to work out which method they can use (and provide
additional API methods for the developer to specify the transform for
servers that don't support discovery). Since SHA256 is MTI, all native app
clients can rely on it being implemented.  And that's what AppAuth does, it
has no support for "plain", and doesn't bother with doing discovery on the
PKCE method, which greatly simplified the implementation (and it's
completely seamless to users of AppAuth). As we required MTI on the more
secure option of the two, this also resulted in more secure implementations
by default.

YMMV – but that's what we did in that case :-)

>> and simplify the process, compared to running two docs in parallel. They do

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 22 Mar 2018 14:59:59 +0000

> I don't think anyone can argue with the desire for strong interop and less complexity.

We just finished having that exact argument over SET. The apparent consensus was that interoperability across profiles was not desired. I would like to see the working group to discuss whether or not profilers and implementers expect or want interoperable delivery methods, lest we repeat the same debate. There is little point in secevents labeling something MTI if only a small subset of people will be using it.

Similarly I am concerned about the working group trying to bless one method or the other as MTI in the name of maximizing interoperability without evidence that said method will be used in the majority of deployments, particularly when there are valid technical reasons to favor either one over the other in different scenarios.

On Mar 22, 2018, at 11:31 AM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaron,

I don't think anyone can argue with the desire for strong interop and less complexity.

Wearing our implementor hats, what delivery method would optimally cover all use cases? Do we want a delivery method that in theory can cover most use cases, but it is suboptimal for many of them? How would a mobile or IoT device use the current PUSH or POLL methods?

We are not talking about alternative delivery methods for the same use case, but different methods for each separate use case. I totally agree that as a workinggroup we should support one method per use case, for example one method for HTTP receivers sitting behind firewalls. I am using "use case" in a generic way, more like "profile".

Why declare one method as MTI when it is clear that it will not work for many use cases and that implementors for those use cases will be forced to ignore the MTI?

Regarding the current delivery draft, why do you think that keeping the two methods together is beneficial? The overlap between the two is minimal. Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. The PUSH method is already implemented and more implementation will come online soon. The POLL method has no implementation yet, as far as I know. By keeping them together we hold back one and put pressure to rush the other. That's lose-lose.

2. With two methods in one drafts it is very ambiguous what is MTI. With two separate drafts each implemetor can chose what works for their use cases. Interop will work out based on use cases, I don't think we have to force it.

The clear message for implementors two years from now would be a clear description for each method as to what use cases it is applicable to. No confusion at all, if you are behind a firewall then POLL is your only option. If you are delivering to IoT then whatever method works for that use case (we don't have one yet).

I asked about a meta-document from a practical point of view.. How/where will the MTI delivery method be defined? Same with IETF police, maybe you misunderstood. I am not worried about implementors disregarding recommendations. Since the unit for specifications are RFCs, how can some RFC be declared as MTI? In what context? Again, from a practical editorial point of view.

Speaking to one draft I worked on where we faced this decision, PKCE Section 4.2<https://tools.ietf.org/html/rfc7636#section-4.2> defined two methods to transform the code challenge, plain text (no transformation), and SHA256.

"S256" is declared as MTI in the spec, and "plain" is not. In this case we actually say "Mandatory to Implement", but gating SHA256 with a "MUST" and the "plain" with a "MAY" would have achieved the same effect.

I advocated for making S256 MTI (when I first reviewed the draft, both were given equal weighting) so that native app clients would not need to perform discovery on the server to work out which method they can use (and provide additional API methods for the developer to specify the transform for servers that don't support discovery). Since SHA256 is MTI, all native app clients can rely on it being implemented.  And that's what AppAuth does, it has no support for "plain", and doesn't bother with doing discovery on the PKCE method, which greatly simplified the implementation (and it's completely seamless to users of AppAuth). As we required MTI on the more secure option of the two, this also resulted in more secure implementations by default.

YMMV - but that's what we did in that case :-)

Thanks,
Marius

Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Marius,

The decision about whether we need to have an MTI protocol and which one it should be is up to the WG consensus, like everything else. But with my WG chair hat on, it is my strong conviction that we need to have one MTI method to encourage interoperability and reduce fragmentation. This is based on my IETF experience, and not on any meta-document as far as I can tell. Just think of implementers that are not part of the WG, and just read the RFCs two years from now. They need to have a clear message which method will allow them the best (though maybe not perfect) interoperability. Also, I personally do not have a preference which of the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", in other words if you choose to not implement an MTI protocol/feature, nobody is going to come after you and punish you. It is between you and your market. I fully expect some of the WG participants to only implement the non-MTI method.

I think keeping the two methods within the same document will speed up and simplify the process, compared to running two docs in parallel. They do have enough commonalities.

Thanks,
        Yaron

Comments inline...

On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Some observations:

    1. Yaron indicated that the IETF will likely require one method be
    MTI (mandatory to implement).

It would be very useful to point to other working groups and specs where this was the case.

What is the mechanism by which a specific delivery method is made MTI? Which meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? What does that exactly mean?

To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH). They will need some other delivery methods appropriate for their architecture. Having the current PUSH or POLL mandatory for these cases does not make sense to me,

Many will simply not implement POLL if what they need is PUSH, and vice versa. Again, I don't see how the working group can pick any delivery method and make it MTI. And MTI in what context?

    3.  There was a general feeling that the delivery draft should stay
    as one draft.

I don't see how that is helping, but if implementors can chose either PUSH or POLL from the current draft then that's fine. But in that case splitting should also be acceptable.

    Annabelle will present her recommendations at the formal meeting on
    Friday where we can get broader input.

    Thanks everyone.

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com<http://www.independentid.com> <http://www.independentid.com>
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

    _______________________________________________
    Id-event mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/id-event
    <https://www.ietf.org/mailman/listinfo/id-event>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Mar 2018 12:03:08 -0700

On Thu, Mar 22, 2018 at 4:29 AM, William Denniss <[email-masked]>
wrote:

> I advocated for making S256 MTI (when I first reviewed the draft, both
> were given equal weighting) so that native app clients would not need to
> perform discovery on the server to work out which method they can use (and
> provide additional API methods for the developer to specify the transform
> for servers that don't support discovery). Since SHA256 is MTI, all native
> app clients can rely on it being implemented.  And that's what AppAuth
> does, it has no support for "plain", and doesn't bother with doing
> discovery on the PKCE method, which greatly simplified the implementation
> (and it's completely seamless to users of AppAuth). As we required MTI on
> the more secure option of the two, this also resulted in more secure
> implementations by default.
>

Thanks William.

Yes, if both delivery methods are described in one draft then the draft
maybe declare one MTI and the other not. In this case the MTI is in the
context of the draft or RFC, in order to claim that you support the RFC you
have to respect the MTI.

But if the delivery methods are in separate drafts then I don't see how
that can be done. You are claim to support one RFC or the other.

This is all technical details on how MTI can be specified. The question if
an MTI for delivery methods is desirable or not is totally different.

---

From: William Denniss <[email-masked]>
Date: Thu, 22 Mar 2018 23:08:44 +0000

On Thu, Mar 22, 2018 at 7:03 PM Marius Scurtescu <[email-masked]>
wrote:

>> Section 4.2 <https://tools.ietf.org/html/rfc7636#section-4.2> defined
>> two methods to transform the code challenge, plain text (no
>> transformation), and SHA256.
>>
>> "S256" is declared as MTI in the spec, and "plain" is not. In this case
>> we actually say "Mandatory to Implement", but gating SHA256 with a "MUST"
>> and the "plain" with a "MAY" would have achieved the same effect.
>>

> that can be done. You are claim to support one RFC or the other.

I agree with this logic. It's only relevant when multiple alternatives are
documented in a single RFC.  If there are conflicting opinions on which
should be MTI, and they're different enough, perhaps that is an indication
that separate specifications would be better.

Another MTI example: OAuth 2.0 Section 2.3.1
<https://tools.ietf.org/html/rfc6749#section-2.3.1> mandates that servers
support HTTP Basic for client authentication, while also documenting
request-body for clients that are unable to use HTTP Basic Authentication.
AppAuth took advantage of this MTI too, by only authenticating using HTTP
Basic, since it is capable of doing so, and this simplified the API surface
substantially.

>>>> The decision about whether we need to have an MTI protocol and which
>>>> one it should be is up to the WG consensus, like everything else. But with
>>>> my WG chair hat on, it is my strong conviction that we need to have one MTI
>>>> It is common at the IETF to say that "there is no IETF police", in
>>>> other words if you choose to not implement an MTI protocol/feature, nobody
>>>> is going to come after you and punish you. It is between you and your
>>>>> Many will simply not implement POLL if what they need is PUSH, and
>>>>> vice versa. Again, I don't see how the working group can pick any delivery

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 23 Mar 2018 12:52:02 +0200

> Basic, since it is capable of doing so, and this simplified the API surface

I hope neither method will become MTI.

An MTI would work well if the MTI method could potentially cover all
delivery cases, and the other method extends or enhances the MTI with
features. But in the case of HTTP push vs pull, we have two delivery
methods intended to solve different use cases. Designating one of them
MTI is a bit like making apples MTI for oranges.

Thanks,
Vladimir

>>>>> I personally do not have a preference which of the methods becomes MTI..
>>>>>