Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A32712010D for ; Tue, 7 Jan 2020 05:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgS_-RvDpDfv for ; Tue, 7 Jan 2020 05:58:25 -0800 (PST) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7709E120120 for ; Tue, 7 Jan 2020 05:58:25 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id opNGik7E8n9FUopNHitjBq; Tue, 07 Jan 2020 06:58:24 -0700 x-spam-cmae: v=2.3 cv=SNc8q9nH c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=UM_DoP-0AAAA:8 a=LS6YZpeZAAAA:8 a=vggBfdFIAAAA:8 a=DVqm7IH0AAAA:8 a=-B3230MOAAAA:8 a=pGLkceISAAAA:8 a=BBoBmrX5DfzL3ZKhHt8A:9 a=MuVwZFWdJ64b3vTM:21 a=Ty4s1fouFGWNx9UI:21 a=QEXdDO2ut3YA:10 a=r_AD4E2wVIxbPAgEuloA:9 a=tgtXeDFGb3I7toZQ:21 a=P4tNvQTW8I36gEdL:21 a=jVb8tlh8HRYajJk3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=TEVHQOIvcflanWNqQbWu:22 a=IRr2vCDBpksuBOXhfkKu:22 a=M6wP_kGduNurgptF5PJY:22 a=Z6yIbYtmj3_f4zpjOCXI:22 a=IdGyktwZ2tr74praB_5u:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com To: Filip Skokan , "Richard Backman, Annabelle" Cc: Dave Tonge , oauth , Nat Sakimura References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com> Date: Tue, 7 Jan 2020 15:58:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030205050400070805000602" X-CMAE-Envelope: MS4wfJ0fCYBSZ1rLzyqyVkZuZ8CDGICBQQUHGaMbMB9Zg2dr/oEkCQ9VqIlaYOHm8qlWHaGUX1yO5uikg7N6hL2fZZRDtrgP1s7c6IXJazKJenMX1VClVwT+ DT3pCp+XyjTYuVM5o/kj+0RRaxwbb0ad/LjRCd3asM72oYjVRKdgpguuRnvDzY4e1cLNcBb44d1Jx5+SfxN+BXRQKSnalseiMc50zg6+gcp05rTLtHWKiU0D 3PDnEQtXU2qqQWAsdq1PbXA41EnXdlF8TUiEOYkDMuYnbaZVUOuAfZ3ON3CbjiJ1phZj+Xgvi2tHmHATL/5eqQ== Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:58:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030205050400070805000602 Content-Type: multipart/alternative; boundary="------------B13116EA8C3AFD96FEC57117" Content-Language: en-US This is a multi-part message in MIME format. --------------B13116EA8C3AFD96FEC57117 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/01/2020 00:22, Filip Skokan wrote: > We've been discussing making the following=C2=A0change to the language > > The AS SHOULD validate the request in the same way as at the > authorization endpoint. The AS MUST ensure that all parameters to > the authorization request are still valid at the time when the > request URI is used. > Could you expand a bit on the second sentence? Alternative suggestion: The AS MUST validate the request in the same way as at the authorization endpoint, or complete the request validation at the authorization endpoin= t. Vladimir > This would allow the PAR endpoint to simply stash the encrypted > request object instead of decrypting and validating it. All within the > bounds of "SHOULD -=C2=A0We=E2=80=99d like you to do this, but we can=E2= =80=99t always > require it". This supports "light weight PAR" implementation rather > than introducing the unnecessary complexity in the form of a second JWK= S. > > Best, > *Filip* > > > On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle > > wrote: > > The issue isn=E2=80=99t that the PAR endpoint needs access to one s= pecific > request object decryption key that could reasonably be shared > across AS endpoints, but that it actually needs access to the > private keys for all encryption public keys in the JWK set pointed > to by the AS=E2=80=99s jwks_uri metadata property. Since there is n= o way > to designate one particular key as the one to use for encrypting > request objects, clients may reasonably use any encryption public > key in the JWK set to encrypt a request object. As one example of > how this could expose sensitive data to the PAR endpoint, if the > PAR endpoint has all the decryption keys for the keys in the AS=E2=80= =99s > JWK set, it would be able to decrypt ID Tokens sent in > id_token_hint request parameters. As more and more use cases > develop for encrypting blobs for the AS, this issue will only get > worse. > > =C2=A0 > > The PAR endpoint can=E2=80=99t simply stash the encrypted request o= bject, > as it is required to verify the request, according to =C2=A72.1: > > =C2=A0 > > The AS MUST process the request as follows: > > =C2=A0 > > ... > > =C2=A0 > > 3.=C2=A0 The AS MUST validate the request in the same way as at the= > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorizatio= n endpoint. ... > > =C2=A0 > > This language needs to be more flexible, IMHO, to allow for > lightweight PAR endpoints that may not have the information or > authority needed to perform all the validation that happens at the > authorization endpoint. I need to think about this more before I > can say if it would adequately address my concerns, but it=E2=80=99= d be a > good start and makes sense in its own right. > > =C2=A0 > > I think it=E2=80=99s pretty risky for us to base decision on an ass= umption > that no one is going to need or want to encrypt pushed request > objects, particularly when they=E2=80=99re JWTs, and JWTs have well= > established support for encryption, and encrypted JWTs are > supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. > But if you insist, here are a few examples for why someone might > want to do this: > > 1. The request object is passed by reference, and accessible on > the public Internet. > 2. The request object contains sensitive transaction-related data > in RAR parameters that the client=E2=80=99s authN/authZ stack d= oesn=E2=80=99t > need to have access to. > 3. The AS requires request object encryption to minimize exposure > to the hosted PAR endpoint service it uses. > 4. #2, but the threat vector is gaps in end-to-end TLS. > 5. Any of the above, but the concern is message integrity, and > the AS requires requested objects to be encrypted for > confidentiality and integrity protection and does not support > signed request objects. > > =C2=A0 > > =E2=80=93=C2=A0 > > Annabelle Richard Backman > > AWS Identity > > =C2=A0 > > =C2=A0 > > *From: *Neil Madden > > *Date: *Monday, January 6, 2020 at 6:29 AM > *To: *Brian Campbell > > *Cc: *"Richard Backman, Annabelle" >, Nat Sakimura >, Dave Tonge >, Torsten Lodderstedt > >, oauth > > > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata > > =C2=A0 > > Agreed. > > =C2=A0 > > In addition, I'm not sure why the PAR endpoint would need access > to the decryption keys at all. If you're using encrypted request > objects then the PAR endpoint receives an encrypted JWT and then > later makes the same (still encrypted) JWT available to the > authorization endpoint. If the PAR endpoint is doing any kind of > decryption or validation on behalf of the authorization endpoint > then they are clearly not in separate trust boundaries. > > =C2=A0 > > -- Neil > > =C2=A0 > > > > On 6 Jan 2020, at 13:57, Brian Campbell > > wrote: > > =C2=A0 > > I really struggle to see the assumption that an entity be able > to use the same key to decrypt the same type of message > ultimately intended for the same purpose as an artificial > limit. The same general assumption =C2=A0 underlies everything = else > in OAuth/OIDC (Vladimir's post points to some but not all > examples of such). There's no reason for PAR to make a one-off > exception. And should there be some deployment specific reason > that truly requires that kind of isolation, there are > certainly implementation options that aren't > compatibility-breaking. And having said all that, I'm honestly > a little surprised anyone is thinking much about encrypted > request objects with PAR as, at least with my limited > imagination, there's not really a need for it. > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > =C2=A0 > > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle > > wrote: > > PAR introduces an added wrinkle for encrypted request > objects: the PAR endpoint and authorization endpoint may > not have access to the same cryptographic keys, even > though they're both part of the "authorization server." > Since they're different endpoints with different roles, > it's reasonable to put them in separate trust boundaries. > There is no way to support this isolation with just a > single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on > deployments that don't care (i.e., they just set > par_jwks_uri and jwks_uri to the same value) and failing > to support this trust boundary creates an artificial limit > on implementation architecture and could lead to > compatibility-breaking workarounds. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten > Lodderstedt" on behalf of > torsten=3D40lodderstedt.net@dmarc.ietf.org > > wrote: > > =C2=A0 =C2=A0 Hi Filip, > > =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan > > wrote: > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > I don't think we need a *_auth_method_* met= adata for > every endpoint the client calls directly, none of the new > specs defined these (e.g. device authorization endpoint or > CIBA), meaning they also didn't follow the scheme from RFC > 8414 where introspection and revocation got its own > metadata. In most cases the unfortunately named > `token_endpoint_auth_method` and its related metadata is > what's used by clients for all direct calls anyway. > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > The same principle could be applied to sign= ing (and > encryption) algorithms as well. > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > This I do not follow, auth methods and thei= r signing > is dealt with by using > `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - > there's no encryption for the `_jwt` client auth methods. > =C2=A0 =C2=A0 > Unless it was meant to address the Request = Object > signing and encryption metadata, which is defined and IANA > registered by OIDC. PAR only references JAR section 6.1 > and 6.2 for decryption/signature validation and these do > not mention the metadata (e.g. request_object_signing_alg) > anymore since draft 07. > > =C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confus= ed somehow. > > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > PS: I also found this comment related to th= e same > question about auth metadata but for CIBA. > > =C2=A0 =C2=A0 Thanks for sharing. > > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > Best, > =C2=A0 =C2=A0 > Filip > > =C2=A0 =C2=A0 thanks, > =C2=A0 =C2=A0 Torsten. > > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodde= rstedt > > > wrote: > =C2=A0 =C2=A0 > Hi all, > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > Ronald just sent me an email asking whether= we will > define metadata for > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_= supported and > =C2=A0 =C2=A0 > > pushed_authorization_endpoint_auth_signing_alg_values_suppo= rted. > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > The draft right now utilises the existing t= oken > endpoint authentication methods so there is basically no > need to define another parameter. The same principle could > be applied to signing (and encryption) algorithms as well. > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > What=E2=80=99s your opinion? > =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 > best regards, > =C2=A0 =C2=A0 > Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------B13116EA8C3AFD96FEC57117 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 07/01/2020 00:22, Filip Skokan wrote:
We've been discussing making the following=C2=A0change to th= e language

= The AS SHOULD validate the request in the same way as at the authorization endpoint. The AS MUST ensure that all parameters to the authorization request are still valid at the time when the request URI is used.

Could you expand a bit on the second sentence?

Alternative suggestion:

The AS MUST validate the request in the same way as at the authorization endpoint, or complete the request validation at the authorization endpoint.

Vladimir


This would allow the PAR endpoint to simply stash the encrypted request object instead of decrypting and validating it. All within the bounds of "SHOULD -=C2=A0We=E2=80=99d like y= ou to do this, but we can=E2=80=99t always require it". This supports "l= ight weight PAR" implementation rather than introducing the unnecessary complexity in the form of a second JWKS.

Best,
Filip


On Mon, 6 Jan 2020 at 23:00= , Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=

The issue isn=E2=80=99t that the PAR= endpoint needs access to one specific request object decryption key that could reasonably be shared across AS endpoints, but that it actually needs access to the private keys for all encryption public keys in the JWK set pointed to by the AS=E2=80=99s jwks_uri metadata property. Since the= re is no way to designate one particular key as the one to use for encrypting request objects, clients may reasonably use any encryption public key in the JWK set to encrypt a request object. As one example of how this could expose sensitive data to the PAR endpoint, if the PAR endpoint has all the decryption keys for the keys in the AS=E2=80=99s JWK set, it would be able to decrypt ID Toke= ns sent in id_token_hint request parameters. As more and more use cases develop for encrypting blobs for the AS, this issue will only get worse.

=C2=A0

The PAR endpoint can=E2=80=99t simpl= y stash the encrypted request object, as it is required to verify the request, according to =C2=A72.1:

=C2=A0

The AS MUST process the request as follows:
=C2=A0
...
=C2=A0
3.=C2=A0 The AS MUST validate the request in the same way as at the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorization endpoint. ...
=C2=A0

This language needs to be more flexible, IMHO, to allow for lightweight PAR endpoints that may not have the information or authority needed to perform all the validation that happens at the authorization endpoint. I need to think about this more before I can say if it would adequately address my concerns, but it=E2=80=99d be a good start and makes sens= e in its own right.

=C2=A0

I think it=E2=80=99s pretty risky fo= r us to base decision on an assumption that no one is going to need or want to encrypt pushed request objects, particularly when they=E2=80=99re JWTs, and JWTs have wel= l established support for encryption, and encrypted JWTs are supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for why someone might want to do this:

  1. The request object is passed by reference, and accessible on the public Internet.
  2. The request object contains sensitive transaction-related data in RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80= =99t need to have access to.
  3. The AS requires request objec= t encryption to minimize exposure to the hosted PAR endpoint service it uses.
  4. #2, but the threat vector is gaps in end-to-end TLS.
  5. Any of the above, but the concern is message integrity, and the AS requires requested objects to be encrypted for confidentiality and integrity protection and does not support signed request objects.

=C2=A0

=E2= =80=93=C2=A0

Ann= abelle Richard Backman

AWS= Identity

=C2=A0

=C2=A0

From: <= /b>Neil Madden <= neil.mad= den@forgerock.com>
Date: Monday, January 6, 2020 at 6:29 AM
To: Brian Campbell <bcampbel= l@pingidentity.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>= ;, Nat Sakimura <nat@saki= mura.org>, Dave Tonge <dave.ton= ge@moneyhub.com>, Torsten Lodderstedt <torsten@= lodderstedt..net>, oauth <oauth@ie= tf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata

=C2=A0

Agreed.

=C2=A0

In addition, I'm not sure why the PAR endpoint would need access to the decryption keys at all. If you're using encrypted request objects then the PAR endpoint receives an encrypted JWT and then later makes the same (still encrypted) JWT available to the authorization endpoint. If the PAR endpoint is doing any kind of decryption or validation on behalf of the authorization endpoint then they are clearly not in separate trust boundaries.

=C2=A0

-- Neil

=C2=A0



=

On 6 Jan 2020, at 13:57, Brian Campbell <bcam= pbell=3D40pingidentity.com@dmarc.ietf.org> wrote:

=C2=A0

I really struggle to see= the assumption that an entity be able to use the same key to decrypt the same type of message ultimately intended for the same purpose as an artificial limit. The same general assumption =C2=A0 underlies everythin= g else in OAuth/OIDC (Vladimir's post points to some but not all examples of such). There's no reason for PAR to make a one-off exception. And should there be some deployment specific reason that truly requires that kind of isolation, there are certainly implementation options that aren't compatibility-breaking. And having said all that, I'm honestly a little surprised anyone is thinking much about encrypted request objects with PAR as, at least with my limited imagination, there's not really a need for it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=3D= 40amazon.com@dmarc.ietf.org> wrote:

PAR introduces an added wrinkle for encrypted request objects: the PAR endpoint and authorization endpoint may not have access to the same cryptographic keys, even though they're both part of the "authorization server." Since they're different endpoints with different roles, it's reasonable to put them in separate trust boundaries. There is no way to support this isolation with just a single "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that don't care (i.e., they just set par_jwks_uri and jwks_uri to the same value) and failing to support this trust boundary creates an artificial limit on implementation architecture and could lead to compatibility-breaking workarounds.
=E2=80=93
Annabelle Richard Backman
AWS Identity


On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <= oauth-bounces@ietf.org on behalf of torsten=3D= 40lodderstedt.net@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 Hi Filip,

=C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22,= Filip Skokan <= panva.ip@gmail.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I don't think we need a *_auth_method_* metadata for every endpoint the client calls directly, none of the new specs defined these (e.g. device authorization endpoint or CIBA), meaning they also didn't follow the scheme from RFC 8414 where introspection and revocation got its own metadata. In most cases the unfortunately named `token_endpoint_auth_method` and its related metadata is what's used by clients for all direct calls anyway.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The same principle could b= e applied to signing (and encryption) algorithms as well.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This I do not follow, auth= methods and their signing is dealt with by using `token_endpoint_auth_methods_supported` and `token_endpoint_auth_signing_alg_values_supported` - there's no encryption for the `_jwt` client auth methods.
=C2=A0 =C2=A0 > Unless it was meant to add= ress the Request Object signing and encryption metadata, which is defined and IANA registered by OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signature validation and these do not mention the metadata (e.g. request_object_signing_alg) anymore since draft 07.

=C2=A0 =C2=A0 Dammed! You are so right. Sorry= , I got confused somehow.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > PS: I also found this comm= ent related to the same question about auth metadata but for CIBA.

=C2=A0 =C2=A0 Thanks for sharing.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 > Filip

=C2=A0 =C2=A0 thanks,
=C2=A0 =C2=A0 Torsten.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:= 38, Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
=C2=A0 =C2=A0 > Hi all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Ronald just sent me an ema= il asking whether we will define metadata for
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_su= pported and
=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_signing_al= g_values_supported.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The draft right now utilis= es the existing token endpoint authentication methods so there is basically no need to define another parameter. The same principle could be applied to signing (and encryption) algorithms as well.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What=E2=80=99s your opinio= n?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > best regards,
=C2=A0 =C2=A0 > Torsten.



_______________________________________________
OAuth mailing list
= OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth


--------------B13116EA8C3AFD96FEC57117-- --------------ms030205050400070805000602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDcxMzU4MjFaMC8G CSqGSIb3DQEJBDEiBCD3cFSwWsCh71Ok9aW4Yoi+up6+0U/oGARJWPBgdzH/YjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAHaBWCR15Q3B6iHavj7emcj/OCO4DZAuWsx0rZm9b2dXfxvz iQZVF+/MM+l3KtWDQjMvLBNmanKI2madbN4epJKvc4Ds3Nl14JHRqtBhOWgfoDSt9aGePHOD er3zbhRdMu/kqb4GSlGudti5gKBfSg4T/H8rDTBlY3Ny/jMflZgNsAcl2rFA9WiYAwNQq9Bi 0CebokzQz07oTszI1sj2bFao0hZtwp9BVIiWj73GO1HJUaG1Bby5C2tzfr+a80vqlphcvMBq 63sAX89ysA73y76u0b3ZkY17RQ87KHoj2rJnaqH8uARNizQA2yEHZgz3y6e90AYyqpncM62Q YNqSJG4AAAAAAAA= --------------ms030205050400070805000602--