Re: [OAUTH-WG] New OAuth client credentials RPK and PSK

Samuel Erdtman <> Sun, 14 May 2017 10:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD674129471 for <>; Sun, 14 May 2017 03:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4nPq7JWTpUIK for <>; Sun, 14 May 2017 03:14:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5C4F127076 for <>; Sun, 14 May 2017 03:12:23 -0700 (PDT)
Received: by with SMTP id l18so104252285oig.2 for <>; Sun, 14 May 2017 03:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Klg4BDvrvlcQmAEwnfMyJ4PGGz53h8XLRx21D+ksuXM=; b=sSq6lExH+aQlhX/o2a1wXsT+ziLLo46C0j8VmWo3PPv1JL3fEjcrHTejSaOW8EXtjE QEjfknocD55ZA4DQJdm7x5USGSifktkUc8bGttekSP8Y/6AgtQmXUGiEETlAjPv9Om/1 mHPuHxd56pI/1BRccSwyzj66XnpmV0ZS2ulYu7gJMayzZjHZZEREYoczCyEkVVZcKarc cHRYeZ3/l8FNCG3kWIHCm26FMDxqRzkHSlCpScvBsLUZW8mGz+WXcYekm1OcGozHZLhV HbQy2a0JaajGEjs85fJgUyaIZBuz5JxSKsPLKTRx7f2B8b/zRPC4QUicH3pUNpGSyj3O 2GtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Klg4BDvrvlcQmAEwnfMyJ4PGGz53h8XLRx21D+ksuXM=; b=IH0pxNlx+moMDg7ZKtVNHxI54jd+vD5DjyjA9VeOKTaJ/1o62eB5S5XjDV54Bc44Lx 4Smd1eUnI6h6yx8iFPMXDB+jundeZ+JZUNxTtsJ0HEVGWnIvXyPcnfn+hfs62K/Ruv6S Zf1BlnThRLJXvB8+dhBrk4HUrDsAhckYXCqDQ/QHc1/D4xmbh3MsZRf/64KfneCGnTz3 Kiyf679KUOfmsr/RyimlMEg1SsgowFYo3fjz+1bb0ukDAdg2mShIAE7FsaFdmeajFxNn qepuk2jURGLGnHhhHAqSjE2h1Gcc1W2DlfQsBNeTiWShDwGtkBBxd52KfNoFZnbplUtk 7HTQ==
X-Gm-Message-State: AODbwcAoM56VoUmYpUmHRSRTDoLYeKZpOPj/nMAD4vbmmwPaXXsr4qrt XUpAzKNq3jZIaz3C5rV4OSufW+MM6UFtHo8=
X-Received: by with SMTP id q23mr278733otg.52.1494756742923; Sun, 14 May 2017 03:12:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 14 May 2017 03:12:22 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Samuel Erdtman <>
Date: Sun, 14 May 2017 12:12:22 +0200
Message-ID: <>
To: Torsten Lodderstedt <>
Cc: "<>" <>, ace <>
Content-Type: multipart/alternative; boundary="f403043c4becb01b5b054f792c79"
Archived-At: <>
Subject: Re: [OAUTH-WG] New OAuth client credentials RPK and PSK
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 May 2017 10:14:19 -0000

Hi Torsten,

That is a possibility, I excluded it to keep the scope limited and because
I don´t think it is as applicable with these credential types.

I think these credential types will mostly be used in IoT deployments using
the ACE framework, in that case the token will have its own key that will
most likely be used in the (D)TLS handshake between the client and resource
server see e.g.

However if the token would not be a PoP token then it could make sense. Do
you fore see such use cases where it would be useful?

One thing that I did not mention in my earlier email that could be a
possible path forward would be to merge this draft into the mtls one.


On Sat, May 13, 2017 at 11:58 AM, Torsten Lodderstedt <> wrote:

> Hi Samuel,
> as far as I understand your draft, it utilizes results of the (D)TLS
> client authentication for authentication towards the tokens endpoint -
> similar to Do
> you intend to also utilize the binding of the access token to a certain key
> pair as described in oauth-ietf-mtls?
> best regards,
> Torsten.
> Am 12.05.2017 um 10:03 schrieb Samuel Erdtman <>:
> Hi ACE and OAuth WGs,
> I and Ludwig submitted a new draft yesterday defining how to use Raw
> Public Key and Pre Shared Key with (D)TLS as OAuth client credentials,
> We think this is valuable to the ACE work since the ACE framework is based
> on OAuth, but client credentials as defined in the OAuth framework are not
> the best match for embedded devices.
> We think Raw Public Keys and Pre Shared Keys are more suitable credentials
> for embedded devices for the following reasons:
> * Better security by binding to transport layer.
> * If PSK DTLS is to be used a key need to be distributed any way, why not
> make use of it as credential.
> * Client id and client secret accommodates for manual input by a humans.
> This does not scale well and requires some for of input device.
> * Some/many devices will have crypto-hardware that can protect key
> material, to not use that possibility would be a waste.
> * There are probably more reasons these was just the once on top of my
> head.
> This is not the first resent initiative to create new client credential
> types, the OAuth WG adopted a similar draft for certificate based client
> credentials (
> That work is also valuable to ACE but not all devices will be able to work
> with certificates or even asymmetric cryptos .
> Please review and comment.
> Cheers
> //Samuel
> _______________________________________________
> OAuth mailing list