[OAUTH-WG] Dynamic Client Registration

[Hannes Tschofenig <[e-mail]>]

Hi Justin, Hi all,

as noted in my status update I am trying to finalize the pending items.

Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my
review of draft-ietf-oauth-dyn-reg-management raised some questions
about the terminology.

If you look at the structure of the ToC then you will notice the following:

   3.  Client Registration Endpoint  . . . . . . . . . . . . . . . .  13
     3.1.  Client Registration Request . . . . . . . . . . . . . . .  14
       3.1.1.  Client Registration Request Using a Software
               Statement . . . . . . . . . . . . . . . . . . . . . .  15
     3.2.  Client Registration Response  . . . . . . . . . . . . . .  16
   4.  Responses . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     4.1.  Client Information Response . . . . . . . . . . . . . . .  17
     4.2.  Client Registration Error Response  . . . . . . . . . . .  18

There is no 'Client Registration Response' in the protocol (only the
Client Information Response) and section 3.2 is pretty much empty and
only points to the later sections. So, I would suggest to do the following.

   3.  Client Registration Endpoint
     3.1.  Client Registration Request
       3.1.1.  Client Registration Request Using a Software Statement
     3.2.  Client Registration Response
       3.2.1.  Client Information Response
       3.2.2.  Client Registration Error Response

(A section with only a single sub-section is also a sign of a bad
structure.)

I re-read the terminology and looked at Figure 1 to see whether it makes
sense and it still does not. I know that there may be many different
deployment options but it should at least be clear to the reader where
information comes from and where does it go.

For example, when I try to follow the flow of the software statement
then I read the following:
"
Software Statement: In some cases, a software statement will be issued
directly by the organization or developer that creates the client software.
"

What does the figure tell us? It shows us that the client or developer
gets the software assertion.

        +--------(A)- Initial Access Token (OPTIONAL)
        |
        |   +----(B)- Software Statement (OPTIONAL)
        |   |
        v   v
    +-----------+                                      +---------------+
    |           |--(C)- Client Registration Request -->|    Client     |
    | Client or |                                      | Registration  |
    | Developer |<-(D)- Client Information Response ---|   Endpoint    |
    |           |                                      +---------------+
    +-----------+

Maybe we should illustrate one example that makes sense and then say
that there are others that could be used. It also does not make sense to
show the developer in the box together with the client since the
developer does not execute a protocol exchange with the client
registration endpoint.

Here is a proposal for improving this:


FROM:

        +--------(A)- Initial Access Token (OPTIONAL)
        |
        |   +----(B)- Software Statement (OPTIONAL)
        |   |
        v   v
    +-----------+                                      +---------------+
    |           |--(C)- Client Registration Request -->|    Client     |
    | Client or |                                      | Registration  |
    | Developer |<-(D)- Client Information Response ---|   Endpoint    |
    |           |                                      +---------------+
    +-----------+

    Figure 1: Abstract Dynamic Client Registration Flow

TO:

    +--------  O  -- (A)- Initial Access Token (OPTIONAL)
    |         /|\
    |   +---- / \ -- (B)- Software Statement (OPTIONAL)
    |   |   Client
    |   |   Developer
    |   |
    v   v
+--------------+                                      +---------------+
|              |--(C)- Client Registration Request -->|    Client     |
|   Client     |                                      | Registration  |
|              |<-(D)- Client Information Response ---|   Endpoint    |
+--------------+                                      +---------------+

  Figure 1: Abstract Dynamic Client Registration Flow


Alternatively, one could also separate the distribution of software
statements and the actual protocol exchange. Here is the proposal:

    +--------(A)- Initial Access Token (OPTIONAL)
    |
    |   +----(B)- Software Statement (OPTIONAL)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Client Registration Request -->|    Client     |
|   Client  |                                      | Registration  |
|           |<-(D)- Client Information Response ---|   Endpoint    |
+-----------+                                      +---------------+

 Figure 1: Abstract Dynamic Client Registration Flow


           +---------------+
           | Authorization |
           | Server        |
           +---------------+
                 |    Initial
                 |(A) Access
                 |    Token
                 v
                  O  Client
         +------ /|\ Developer
         |+----- / \
         ||
      (A)||(B) Software
         ||    Statement
         vv
  +-----------+
  |           |
  |   Client  |
  |           |
  +-----------+

Figure 2: Software Statement / Initial Access Token Distribution Example.

Then, there is also this statement in the Software Statement definition:

"
      In other cases, a
      software statement will be issued by a third party organization
      for use by the organization or developer that creates the client
      software.
"

In the terminology section we are defining all the parties that are
involved and now this mysterious "third party organization" is
introduced. Is this one of the already defined parties or is this yet
another organization?

Finally, the client developer is defined as a single individual or an
entire organization (i.e., a group of people). However, in the text you
write 'client developer or organization'. For example, look at the
software statement:

"In some cases, a software statement will be issued directly by the
organization or developer that creates the client software.
"

Wouldn't it be more consistent to use the client developer definition as
is and just turn this sentence into

"
In some cases, a software statement will be issued directly by the
client developer.
"

Ciao
Hannes