Re: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client

Nat Sakimura <> Sun, 03 November 2013 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF69011E81FB for <>; Sun, 3 Nov 2013 05:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P90BkcqjIF2o for <>; Sun, 3 Nov 2013 05:05:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) by (Postfix) with ESMTP id 2DDD511E8135 for <>; Sun, 3 Nov 2013 05:05:03 -0800 (PST)
Received: by with SMTP id u14so4639436lbd.22 for <>; Sun, 03 Nov 2013 05:05:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=21Qlz9m70u/w/xJqU/rE/LZNKKrRLMxlHhKgcoYfglE=; b=W4zAfss//X6bPakzttpwPd/ARITeWnqk0MtGXFqfvjyOQKobB5Oi21Rb6JKdTPQxdb zUfF5hZ1rKotjAYI4LPCDXCdTonU80YXodsOdflggKLvaCPO2lsIptuJ9oa3pGRGhcWN VxntuW6pNC+78q8DPAVM8dJeHuSWfFGn5Hjf6Z4x/OL359ROA3KLRN2sd2FfizeSvQng LmIgHjegeY0k6DA/qctwQFlHgD5HYQ2c4NmDlM5OBMZy0KC0YXsNxYcwuScrfrTgpH4X b6jLpocVei+ZPgv0BXwuBS6r9vsVjsxFwM8hLyGyW4gx5hIVxSl1Ivfhi6YJ9rBLqUr4 sF1w==
MIME-Version: 1.0
X-Received: by with SMTP id py1mr7834195lbb.4.1383483902917; Sun, 03 Nov 2013 05:05:02 -0800 (PST)
Received: by with HTTP; Sun, 3 Nov 2013 05:05:02 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sun, 3 Nov 2013 22:05:02 +0900
Message-ID: <>
From: Nat Sakimura <>
To: Phil Hunt <>
Content-Type: multipart/alternative; boundary=089e0115f6c496034304ea4572e4
Cc: oauth list <>
Subject: Re: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Nov 2013 13:05:06 -0000

Thanks Phil.

This is largely in-line with what I have been looking for since 2011 or so.
Instead of "software id", I was using the term "client class id" but that
would be more or less equivalent, though I like "client class id" better
than "software id" as a piece of software may imply client instance as

I further was thinking that "client class id" should be a URI from which
the authorization server can pull the "software statement"/"class
properties" so that signing it would be optional and it could simply be a
plain JSON. That would make it easier to fix the "software statement" bugs
and adding more values (e.g. more language support) at a later date.

As to the "association" is concerned, it would be really nice if the
response includes the link relationship in the response JSON like in . By doing so, the
client instance can learn which authorization endpoint and so on that it
should use [1]. This would allow the server to assign different endpoints
to different client instances for scalability, security, billing and all
sorts of other reasons. It would also achieve HATEOAS.

As to the relationship with the dynreg draft is concerned, I kind of see
dynreg as an API to talk to the software publisher.

[1] I think it would be better return the discovery endpoint and have the
client figure out where is its authorization endpoint than returning
authorization endpoint directly but it can be either way.



2013/11/2 Phil Hunt <>

> I would like to encourage people to read the client association draft
> before monday.
> and
> the related
> Most of the draft just focuses on background and taxonomy. If you are not
> interested, focus in on the dynamic association section. I believe you will
> find this alternate stateless approach to be very simple to implement and
> uses a well established pattern.
> My position is that while the new approach represents a major change to
> OIDC implementors, the benefits outweigh the costs as it will make Connect
> much easier to support for service providers.
> The key difference in approaches is that the software statement serves as
> a way to lock-down registration profiles that allow servers (and their
> policy systems) to recognize different types of client software.   Note
> that nothing about using software statements prevents developers from
> self-asserting registration.  Those scenarios can continue to work.   The
> key benefit to service providers and client developers is that the number
> of variations for registration options is dramatically reduced. The
> registration becomes a simple assertion swap with any allowable per-client
> overrides as an exception rather than the norm.
> IOW -- client association places different emphasis on what happens when.
>  Client association assumes software characteristics are known at packaging
> time and does not vary widely (from the client side) other than having to
> handle different authentication policies of the various service providers.
> I've already spent more text here explaining the difference than the core
> of the draft takes to explain the registration. So please read the draft
> before our discussion on monday.
> Phil
> @independentid
> _______________________________________________
> OAuth mailing list

Nat Sakimura (=nat)
Chairman, OpenID Foundation