Subject: [Ace] draft-ietf-ace-oauth-authz-02

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 10 Oct 2016 07:02:13 +0000

Hi,
I have been looking into this draft, which is very well written, and I would like a clarification regarding the workflow in figure 1 of the draft.

This workflow is a bit different to the typical one I imagine for constrained clients/servers. Such devices would typically be provisioned from some kind of a commissioning tool and the tool would also initiate the provisioning process. Therefore, would it not be better to have a protocol flow that is not necessarily initiated by the client device? I show two options below. In Option 1, the Resource Owner would be a commissioning tool and in Option 2, the Authorization server would be the commissioning tool. In the protocol flow in your draft, I will need a proprietary method to generate the token request message from client to AS.

OPTION 1:
     +--------+                               +---------------+
     |        |                               |   Resource    |
     |        |                               |     Owner     |
     |        |<-(A)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(B)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(C)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(D)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(E)--- Protected Resource ---|               |
     +--------+                               +---------------+

OPTION 2:

   +--------+                               +---------------+

   |        |                               |               |

   |        |                               | Authorization |

   |        |<--(A)-- Access Token ---------|    Server     |

   |        |       + Client Information    |               |

   |        |                               +---------------+

   |        |                                      ^ |

   |        |            Introspection Request  (C)| |

   | Client |                                      | |

   |        |             Response + Client Token  | |(D)

   |        |                                      | v

   |        |                               +--------------+

   |        |---(B)-- Token + Request ----->|              |

   |        |                               |   Resource   |

   |        |<--(E)-- Protected Resource ---|    Server    |

   |        |                               |              |

   +--------+                               +--------------+

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 10 Oct 2016 10:23:53 +0200

On 2016-10-10 09:02, Somaraju Abhinav wrote:
> Hi, I have been looking into this draft, which is very well written,
> and I would like a clarification regarding the workflow in figure 1
> of the draft.
>
> This workflow is a bit different to the typical one I imagine for
> constrained clients/servers. Such devices would typically be
> provisioned from some kind of a commissioning tool and the tool would
> also initiate the provisioning process. Therefore, would it not be
> better to have a protocol flow that is not necessarily initiated by
> the client device?

If I understand you correctly, you are suggesting to provision either 
the grant or the access token during the commissioning process.

Our idea was to use the client credentials grant instead (not shown in 
our figure 1) and have the AS decide what access tokens to grant purely 
based on the credentials presented by the client.

This way you don't have to provision anything, except for base 
credentials to a client.

The underlying idea is that the RO would configure access control 
policies at the AS during the commissioning procedure. The AS uses these 
to determine what kind of access tokens to grant to the client, when it 
requests one.

You could of course also provision a long term access token to the 
client during commissioning (I think we mentioned that somewhere, or at 
least thought of it), so your proposed option 2 would also be valid, and 
I think they would work just as well with the rest of the framework.
I would suggest to add a step before (A) then, were the RO requests an 
access token from the AS on behalf of the client.

As for option 1, I am not sure what the advantage would be of 
provisioning a grant to the client as opposed to using the client 
credentials grant. Could you elaborate on that?

Regards,

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

The RISE institutes SP, Swedish ICT and Innventia are merging in order
to create a unified institute sector and become a stronger innovation
partner for businesses and society. At the end of the year we will
change our name to RISE. Read more at www.ri.se/en/about-rise