Subject: [Ace] Deployment Options

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2016 18:38:22 +0100

Hi all,

<draft-ietf-ace-oauth-authz-01> describes 6 deployment options in
Section 6:

  6.  Deployment Scenarios  . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Client and Resource Server are Offline  . . . . . . . . .  19
     6.2.  Resource Server Offline . . . . . . . . . . . . . . . . .  22
     6.3.  Token Introspection with an Offline Client  . . . . . . .  26
     6.4.  Always-On Connectivity  . . . . . . . . . . . . . . . . .  30
     6.5.  Token-less Authorization  . . . . . . . . . . . . . . . .  31
     6.6.  Securing Group Communication  . . . . . . . . . . . . . .  34

Describing all 6 deployment options at a level that allows interoperable
implementations in a single document, namely in
draft-ietf-ace-oauth-authz>, make the document longer (obviously),
requires a fair amount of work, and takes longer.

For this reason we are asking for your priorities. Which of these
deployment options are more important for you than others.

Please let us know which of them would you include in the WG document,
which of them would you would like to see covered in separate documents,
and which of them would you drop?

Here are the slides from the ACE virtual interim meeting providing
further background information:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-1.pdf

Deadline: 16th March 2016

Ciao
Hannes & Kepeng

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Mar 2016 09:47:34 +0000

>and which of them would you drop?

The reason for writing section 6 was to demonstrate, by means of examples,
that the OAuth profile we are working on can accommodate a wide variety of
deployment scenarios.

We got support in the meeting yesterday that all these scenarios should be
supported in the ACE framework, and the proposal to consider “profiles" of
the ACE framework to address specific scenarios was also well received,
with the remark that it must be possible for a client to support multiple
profiles and know which profile to use.

To progress on the framework and at the same time ensure that different
scenarios can be supported one proposal was to profile a few scenarios
that were sufficiently different. Other scenarios could potentially be
separate drafts with different timelines.

Also, there is a difference between "describing a deployment option" in
the sense of writing down details of an example (which is currently the
content of section 6) and defining what messages and message fields of the
framework that are used and how (which is what we need to specify).

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2016 12:40:43 +0100

-- chair hat off

I would merge scenario 6.1 and 6.2 since they are very similar. The
point is more that the resource server is offline. When the client is
offline it just means that it has to get the token upfront.

Scenario 6.3 and 6.4 can also be merged since their main message is that
there is token introspection.

I focus the description in the document on a scenario where the resource
server verifies the tokens locally (because it is offline at the time of
resource request or because of some other reasons) and uses the raw
public key as a credential.

I would describe two scenarios in separate documents, namely
 * secure group communication (for which there is already a separate
document and it is substantially different).
 * the introspection model

I don't believe in the tokenless scenario.

Ciao
Hannes

On 03/02/2016 06:38 PM, Hannes Tschofenig wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Mar 2016 13:46:07 +0000

Hi Hannes, all

>there is token introspection.

Again, making the distinction between “example” and “profile”: I don’t see
the problem to have many examples e.g. in an appendix, or in separate
drafts. I recall a previous discussion about a “cookbook”. In terms of
profiling, your grouping makes sense. My concern is that the framework is
aligned between the different deployment options.

>I don't believe in the tokenless scenario.

Interestingly, this is the only deployment scenario which got explicit
support on the mailing list so far:
http://mailarchive.ietf.org/arch/msg/ace/Nx9AkBKIIjbK8SrCnDswr7tj330

Göran

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 6 Mar 2016 21:02:05 +0100

Hi,

I have always been thinking about these sections as examples to display how
the specification can be used. Examples give a good feel for the
specification when implementing and selecting wether to implement. As
mentioned previously I think they are more suitable for the appendix. I se
them as non normative examples and not profiles.

//Samuel

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 Mar 2016 09:24:45 +0100

>       6.6.  Securing Group Communication  . . . . . . . . . . . . . .  34

I would like to have a superficial description of all of these in an 
appendix to the main document to demonstrate that we can cover a number 
of different use cases with this design.
I would prefer to describe in detail 6.2 and perhaps 6.3 in the main 
document.

If we get enough interest, I would support specifying all of the above 
in additional documents.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 20 Mar 2016 22:47:19 +0100

Hi

To make some progress here I have created a branch in the git repository (
https://github.com/LudwigSeitz/ace-oauth/tree/deployment_examples), where
the working copy of the document is located. In this branch I have merged
6.1 and 6.2 and renamed them to “Local token validation”, since the key
aspect here is that the RS must be able to validate the token without
interaction with other systems in realtime. Then I have merged 6.3 and 6.4
and renamed them to “Introspection aided token validation” to highlight the
fact that introspection is an option to get up to date keys and
authorisation information to the RS when the client cannot provide that.

6.5 and 6.6 has been excluded, not because those could not be supported,
but because they are more of corner cases. 6.6 might also need to define
some extensions to the core framework, i.e. it seemed reasonable to take it
out for now and introducing it in a more focused draft.

Finally I have moved the whole section to an appendix and renamed it to
Deployment examples.

Thoughts?

//Samuel

On Tue, Mar 8, 2016 at 9:24 AM, Ludwig Seitz <[email-masked]> wrote:

> appendix to the main document to demonstrate that we can cover a number of
> different use cases with this design.
> If we get enough interest, I would support specifying all of the above in
> additional documents.
>
> /Ludwig
>
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
>
> Phone +46(0)70 349 9251
> http://www.sics.se
>
>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 29 Mar 2016 10:30:56 +0200

> Finally I have moved the whole section to an appendix and renamed it to

Sounds reasonable. We can describe the (marginal) differences between 
6.1 and 6.2 as well as 6.3 and 6.4 in a short paragraph. I think it 
boils down to the lifetime of the token that the client is given in both 
cases.
Does that have any more implications?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se