From nobody Mon Mar 2 11:42:16 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599C3A0FE3 for ; Mon, 2 Mar 2020 11:42:14 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QKMTEblnc6yj for ; Mon, 2 Mar 2020 11:42:11 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 84B943A0FE8 for ; Mon, 2 Mar 2020 11:42:10 -0800 (PST)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 022Jg5XI027936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Mar 2020 14:42:05 -0500
From: Justin Richer
Message-Id:
Content-Type: multipart/alternative; boundary="Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 2 Mar 2020 14:42:05 -0500
In-Reply-To:
Cc: "Richard Backman, Annabelle" , "txauth@ietf.org"
To: Dick Hardt
References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At:
Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 02 Mar 2020 19:42:15 -0000
--Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Working with that kind of setup, where you=E2=80=99ve got two different =
users at the client and the AS, is the driving goal behind CIBA and UMA, =
and in some instances, the device flow. All of these have a polling =
mechanism that allows an asynchronous update.
In XYZ, the client explicitly signals this kind of expectation by not =
sending a =E2=80=9Ccallback=E2=80=9D field in its request, indicating =
that it doesn=E2=80=99t expect the approving user to get returned =
through the front channel. It=E2=80=99s not just about signaling the =
client about when to poll next, it=E2=80=99s about signaling the intent =
to poll at all.
It=E2=80=99s a different security profile that both the AS and the =
Client need to know about, since it might not be appropriate for all =
different forms of access.=20
XYZ (and to some extent XAuth) also allows the client to present =
information about the current user at the client so that the AS can =
figure out if it expects the same user or a different user during the =
interactive bits by allowing things to be passed in the =E2=80=9Cuser=E2=80=
=9D object of the request. It=E2=80=99s not just there as a login hint, =
at least in XYZ. There are some details from UMA and CIBA that we can =
import, like the user-displayed confirmation codes and the like, that =
can help security and usability of the overall protocol. But as is the =
case with just about everything in XYZ, I didn=E2=80=99t want to add it =
to the spec document until I=E2=80=99d implemented it to make sure that =
it made sense to carry that information through to the different =
parties.
=E2=80=94 Justin
> On Feb 28, 2020, at 5:56 PM, Dick Hardt wrote:
>=20
> Thinking about this, the fixation attack is against the Client where =
the attacker is at the Client, and the victim is at the AS.
>=20
> Does the AS need to know the attacker and victim are different? IE, if =
the client knows that the User at the Client is the same as the User =
that came from the AS, have we prevented the attack?
> =E1=90=A7
>=20
> On Tue, Feb 25, 2020 at 7:38 AM Justin Richer > wrote:
> That=E2=80=99s good enough for the AS, but is it good enough for the =
client? The hash allows the client to make sure that the reference =
they=E2=80=99re getting back in the front channel is related to =
something they sent out in the first place. We originally had a =
=E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but =
realized that since the client can push its callback URI we didn=E2=80=99t=
need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80=
=9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash =
parameter that the client can check before it calls the TX endpoint =
again.
>=20
> =E2=80=94 Justin
>=20
>> On Feb 21, 2020, at 8:12 PM, Dick Hardt > wrote:
>>=20
>>=20
>> The Client presents the interact_ref to the AS with the transaction =
handle. The AS will be able to tell the Client if the interact_ref =
belongs to the transaction.
>>=20
>> Why is that enough?
>> =E1=90=A7
>>=20
>> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer > wrote:
>> The hash offers the same kinds of protections to the client that the =
OIDC nonce does =E2=80=94 it binds the front channel return to something =
you get from the back channel.=20
>>=20
>> In other words, the client can be sure that the return value that =
it=E2=80=99s getting is related to the request it made in the first =
place, and not another one. Clients using per-request redirect URIs can =
also help with this, but this is something that the server can provide =
directly.
>>=20
>> =E2=80=94 Justin
>>=20
>>> On Feb 21, 2020, at 4:14 PM, Dick Hardt > wrote:
>>>=20
>>> While I can see the value of the interact_ref (aka interaction_ref) =
in the return URI that allows the Client to ensure the user that started =
the transaction is the same one that interacted at the AS, I don't =
understand why a hash is required. Would you elaborate?
>>> =E1=90=A7
>>>=20
>>> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer > wrote:
>>> But that=E2=80=99s exactly the point =E2=80=94 it helps in that =
case, which is a very common case. For cases where the client doesn=E2=80=99=
t expect the user to come back on the same channel, then they don=E2=80=99=
t use the callback mechanism. They might use the =E2=80=9Cfinish =
message=E2=80=9D URL that Annabelle mentioned in the other thread, or =
they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at =
the AS, which is common today.
>>>=20
>>> XYZ=E2=80=99s interaction structure allows the composition of these =
things, under the control of the client. This is exactly why it=E2=80=99s =
important to be able to specify how to get to the AS and how to get back =
as separate items, so that the client can compose the combination that =
makes the most sense for that client.
>>>=20
>>> =E2=80=94 Justin
>>>=20
>>>=20
>>>> On Feb 21, 2020, at 3:52 PM, Dick Hardt > wrote:
>>>>=20
>>>> I got ahead of myself. A completion URI protects the User only if =
the User is sent back to the same channel the transaction started so the =
Client can confirm it is the same User that started the transaction.
>>>>=20
>>>> so this does not help the security:
>>>>=20
>>>> "Being able to provide a completion URI even if the user is =
starting on a device is a great insight on how to address the threat =
above."
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt > wrote:
>>>> The lightbulb finally clicked on for me. Thanks for your patience.
>>>>=20
>>>> The threat you are describing is where the attacker starts a =
transaction at the client, and gets the victim to complete it. Correct?
>>>>=20
>>>> I still think the Client should be able to signal if it will be =
doing a redirect vs showing a QR code (or wants to do both).
>>>>=20
>>>> Being able to provide a completion URI even if the user is starting =
on a device is a great insight on how to address the threat above.=20
>>>>=20
>>>> I'm going to ponder how to align XAuth more with these features of =
XYZ.
>>>> =E1=90=A7
>>>>=20
>>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer > wrote:
>>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt > wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote:
>>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we =
realized that both the QR Code and Authorization Code, and that the only =
difference is how the user gets back to the client. So instead of =
inventing a new type of interaction, we split them. In XYZ, we have:
>>>>>=20
>>>>> This sentence looks to be missing something.
>>>>=20
>>>> Apologies: We realized they both used AS-composed URLs to get the =
user to the AS in a web browser for interaction purposes.
>>>>=20
>>>>> =20
>>>>>=20
>>>>> - redirect: tells the AS that the client can send the user to an =
arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that =
info to the user; could be a redirect or an image or send a push =
notification to a secondary device, we don=E2=80=99t care as long as the =
user shows up in a browser at the AS =E2=80=94 so maybe this field can =
be renamed to be more universally accurate)
>>>>>=20
>>>>> As stated in this thread, it may be useful for the AS to know if =
the URL will be in a QR code, or in a full redirect.
>>>>>=20
>>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a =
Client has to do, so it needs to know the difference between a popup, =
and a full browser redirect. This is targetted at SPAs, where an =
additional URL to redirect to is extra work.
>>>>> =20
>>>>> - code: tells the AS that the client can present a short code the =
user can type (along with a static URL the user can get to, maybe by =
typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the =
redirect method)
>>>>> - callback: tells the AS that the client can receive the =
completion message from a front channel interaction through a redirect. =
Note that the client might have gotten to the AS through a redirect =
on-device, through a QR-code off device, or through some other magic, =
and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s =
only concerned with how to get the user :back:.
>>>>>=20
>>>>> In a full redirect, the Client wants the AS to send the user back =
so that it can continue.
>>>>>=20
>>>>> The only parameter in the completion message is the nonce, which =
seems superfluous. See below.
>>>>> =20
>>>>>=20
>>>>> These three can be combined in different ways depending on what =
you want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and =
OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=
=9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a =
plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99=
re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=
=9D to get the long URL. If you=E2=80=99re doing a user code and a QR =
code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D=
to get the long URL and the short code not he screen at the same time.=20=
>>>>>=20
>>>>> On top of that, they can be combined with other methods. Maybe I =
can send the user to an arbitrary URL but also display a human-readable =
verification code (like CIBA), or send something in a push notification =
but also give them a message to type, or I=E2=80=99m getting claims from =
an agent but I want them redirected back through the browser. The client =
gets to decide what kinds of interaction it can do and how to use these =
pieces in ways that make the most sense.
>>>>>=20
>>>>> Per my question later in this thread, why would the Client not =
know what interaction it wants prior to the request?
>>>>=20
>>>> What do you mean? The client does know what it wants and that=E2=80=99=
s why it=E2=80=99s asking for what it wants. We=E2=80=99re debating =
different methods for the client to ask for what it wants. This question =
does not make sense to me.
>>>>=20
>>>>>=20
>>>>> If the AS is doing CIBA, that is not a decision just for the =
Client. Both the AS and the Client need to know they are doing CIBA. =
(FWIW: I think this work supersedes CIBA)
>>>>=20
>>>> As I=E2=80=99ve stated previously, I believe the interaction =
methods here can supersede CIBA.
>>>>=20
>>>>>=20
>>>>> Additionally, different interactions have different risk profiles. =
Sophisticated ASes will use that signal in the risk assessment, and may =
do ask for additional authentication or verification.
>>>>> =20
>>>>=20
>>>> Yes, exactly my point. Because different interactions have =
different risks, the AS will need to be able to decide which =
interactions it=E2=80=99s OK with for a given request. This could vary =
based on what=E2=80=99s being requested, or who=E2=80=99s doing the =
requesting.
>>>>=20
>>>>>=20
>>>>> An interesting difference between XYZ and XAuth=E2=80=99s =
approaches is that XYZ keeps the concept of the =E2=80=9Cauthorization =
code=E2=80=9D in the callback response (which in turn is based on the =
OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an =
=E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of =
nonces generated by the client and the AS in the back channel. This =
binds the front channel response to both the back channel request and =
the back channel response for a given transaction =E2=80=94 and note =
that I=E2=80=99m really open to having a better way to generate and =
calculate such a binding, but I think this works. In any event, this =
protects the client from session fixation and injection on the return =
from the front channel that it=E2=80=99s susceptible to in a pure =
polling model, and the hashing approach basically combines the security =
parameters of the OAuth 2 authorization code and (to an extent) state, =
PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. =
This is only applicable if you=E2=80=99re coming back to the client and =
you can validate the hash and present the reference parameter. If =
you=E2=80=99re doing just plain polling, you don=E2=80=99t have that =
protection =E2=80=94 but the client and the AS are aware of that risk, =
and there=E2=80=99s an option to prevent it.
>>>>>=20
>>>>> XAuth has removed the authorization code concept in its redirect =
return, and clients only do polling against the GS API in order to get =
tokens. While I obviously think it=E2=80=99s very valuable to remove =
things from the front channel, I don=E2=80=99t think this is something =
we can remove without opening up attack surfaces that have already been =
identified in previous protocols. I would like to understand why XAuth =
is not susceptible to the same kinds of attacks, or if it is, what =
mitigations there are for them.=20
>>>>>=20
>>>>> Unlike OAuth 2.0, there are no parameters in the front channel =
response to the Client. The redirect back to the Client is only needed =
to return the interaction back to the Client.
>>>>=20
>>>> This argument rings tautologically hollow =E2=80=94 there are no =
parameters because you=E2=80=99ve defined that there aren=E2=80=99t any =
in XAuth. XYZ does have parameters, to tie the front and back channel =
requests together when doing redirect back and forth.
>>>>=20
>>>> If you=E2=80=99re not doing a redirect back (ie, not sending a =
=E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a =
polling mechanism like XAuth, the device flow, etc. There are very real =
risks to this.
>>>>=20
>>>>>=20
>>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth =
1.0)
>>>>>=20
>>>>> In OAuth, the AS gives a code to the User to give to the Client =
that the Client then gives to the GS.
>>>>>=20
>>>>> In XAuth, the AS gives a "code" to the Client that givers it to =
the User to give to the GS.
>>>>>=20
>>>>> In XAuth, the "code" is either a user code, or something embedded =
in the URI the User is redirected to.
>>>>>=20
>>>>> Therefore, there is nothing to protect in the redirect back to the =
Client.
>>>>>=20
>>>>> If I'm missing an attack, please elaborate how it would happen.
>>>>=20
>>>> One form of impersonation is well documented: =
https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592=
50a0e7 =
>>>>=20
>>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar =
request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, =
etc, and it=E2=80=99s susceptible to the same kind of issue.
>>>>=20
>>>>> =20
>>>>>=20
>>>>> =E2=80=94 Justin
>>>>>=20
>>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle =
> wrote:
>>>>>>=20
>>>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my =
comments here to interaction mode design, setting aside whether or not =
we need =E2=80=9Cpopup=E2=80=9D. :D
>>>>>> =20
>>>>>> Once the GS hands that URI back to the Client, it has zero =
control over how the Client uses it. The Client could present any URI =
(of a reasonable size) into a QR code, or present it as a clickable =
link, or redirect to it, or open it in an external browser, or do any =
number of other as-yet-not-invented things with it. Moreover, the Client =
may not know yet what it wants to do with it. So what value is there in =
distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =
=E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI =
for =E2=80=9D?
>>>>>> =20
>>>>>> Even if we consider things like QR code data capacity, that=E2=80=99=
s really just a URI length limitation, which could apply to non-QR =
interaction modes, e.g., if the Client device wants to communicate the =
URI over an extremely bandwidth-constrained channel. And it=E2=80=99s =
not clear to me how including a URI length limitation in the request =
helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99=
t it always return that? On the client side, it can look at the length =
of the URI provided and decide what to do with it (e.g., render a QR =
code or display it or do nothing with it).
>>>>>> =20
>>>>>> So that really leaves us with two interaction modes that we need:
>>>>>> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be =
human friendly; and
>>>>>> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code =
entry page, both of which are human-friendly.
>>>>>> =20
>>>>>> Those could be combinable to get both, and even if we don=E2=80=99t=
go down the multiple interaction mode route we could add the full URI =
to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t =
hurt anything to do so.
>>>>>> =20
>>>>>> =E2=80=93
>>>>>> Annabelle Backman (she/her)
>>>>>> AWS Identity
>>>>>> https://aws.amazon.com/identity/ =
>>>>>> =20
>>>>>> =20
>>>>>> From: Txauth > on behalf of Dick Hardt =
>
>>>>>> Date: Tuesday, February 18, 2020 at 6:04 PM
>>>>>> To: "txauth@ietf.org " >
>>>>>> Subject: [Txauth] Fwd: New Version Notification for =
draft-hardt-xauth-protocol-03.txt
>>>>>> =20
>>>>>> Added in user code interaction and aligned QR code to be a =
superset of user code.
>>>>>> Fixed descriptions.
>>>>>> =20
>>>>>>=20
>>>>>> ---------- Forwarded message ---------
>>>>>> From: >
>>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM
>>>>>> Subject: New Version Notification for =
draft-hardt-xauth-protocol-03.txt
>>>>>> To: Dick Hardt >
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt
>>>>>> has been successfully submitted by Dick Hardt and posted to the
>>>>>> IETF repository.
>>>>>>=20
>>>>>> Name: draft-hardt-xauth-protocol
>>>>>> Revision: 03
>>>>>> Title: The XAuth Protocol
>>>>>> Document date: 2020-02-18
>>>>>> Group: Individual Submission
>>>>>> Pages: 53
>>>>>> URL: =
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt =
>>>>>> Status: =
https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ =
>>>>>> Htmlized: =
https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 =
>>>>>> Htmlized: =
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol =
>>>>>> Diff: =
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 =
>>>>>>=20
>>>>>> Abstract:
>>>>>> Client software often desires resources or identity claims =
that are
>>>>>> independent of the client. This protocol allows a user and/or
>>>>>> resource owner to delegate resource authorization and/or =
release of
>>>>>> identity claims to a server. Client software can then request =
access
>>>>>> to resources and/or identity claims by calling the server. =
The
>>>>>> server acquires consent and authorization from the user and/or
>>>>>> resource owner if required, and then returns to the client =
software
>>>>>> the authorization and identity claims that were approved. =
This
>>>>>> protocol can be extended to support alternative =
authorizations,
>>>>>> claims, interactions, and client authentication mechanisms.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Please note that it may take a couple of minutes from the time of =
submission
>>>>>> until the htmlized version and diff are available at =
tools.ietf.org .
>>>>>>=20
>>>>>> The IETF Secretariat
>>>>>>=20
>>>>>> =E1=90=A7
>>>>>> --=20
>>>>>> Txauth mailing list
>>>>>> Txauth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/txauth =
>>>>=20
>>>=20
>>=20
>=20
--Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
Working with that kind of setup, where you=E2=80=99ve got two =
different users at the client and the AS, is the driving goal behind =
CIBA and UMA, and in some instances, the device flow. All of these have =
a polling mechanism that allows an asynchronous update.
In XYZ, the client explicitly signals =
this kind of expectation by not sending a =E2=80=9Ccallback=E2=80=9D =
field in its request, indicating that it doesn=E2=80=99t expect the =
approving user to get returned through the front channel. It=E2=80=99s =
not just about signaling the client about when to poll next, it=E2=80=99s =
about signaling the intent to poll at all.
It=E2=80=99s a different security =
profile that both the AS and the Client need to know about, since it =
might not be appropriate for all different forms of =
access.
XYZ (and to some extent XAuth) also allows the client to =
present information about the current user at the client so that the AS =
can figure out if it expects the same user or a different user during =
the interactive bits by allowing things to be passed in the =E2=80=9Cuser=E2=
=80=9D object of the request. It=E2=80=99s not just there as a login =
hint, at least in XYZ. There are some details from UMA and CIBA that we =
can import, like the user-displayed confirmation codes and the like, =
that can help security and usability of the overall protocol. But as is =
the case with just about everything in XYZ, I didn=E2=80=99t want to add =
it to the spec document until I=E2=80=99d implemented it to make sure =
that it made sense to carry that information through to the different =
parties.
=E2=80=94 Justin
Thinking about this, the fixation =
attack is against the Client where the attacker is at the Client, and =
the victim is at the AS.
Does the AS need to know the attacker and victim are =
different? IE, if the client knows that the User at the Client is the =
same as the User that came from the AS, have we prevented the =
attack?
=E1=90=A7 That=E2=80=99s good enough for the AS, but is it =
good enough for the client? The hash allows the client to make sure that =
the reference they=E2=80=99re getting back in the front channel is =
related to something they sent out in the first place. We originally had =
a =E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but =
realized that since the client can push its callback URI we didn=E2=80=99t=
need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80=
=9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash =
parameter that the client can check before it calls the TX endpoint =
again.
=E2=80=94=
Justin
The Client presents the interact_ref to =
the AS with the transaction handle. The AS will be able to tell the =
Client if the interact_ref belongs to the transaction.
Why is that =
enough?
=E1=90=A7 The hash offers the =
same kinds of protections to the client that the OIDC nonce does =E2=80=94=
it binds the front channel return to something you get from the back =
channel.
In =
other words, the client can be sure that the return value that it=E2=80=99=
s getting is related to the request it made in the first place, and not =
another one. Clients using per-request redirect URIs can also help with =
this, but this is something that the server can provide =
directly.
=E2=80=94 Justin
While I can see the value of the =
interact_ref (aka interaction_ref) in the return URI that allows the =
Client to ensure the user that started the transaction is the same one =
that interacted at the AS, I don't understand why a hash is required. =
Would you elaborate?
=E1=90=A7 But that=E2=80=99s =
exactly the point =E2=80=94 it helps in that case, which is a very =
common case. For cases where the client doesn=E2=80=99t expect the user =
to come back on the same channel, then they don=E2=80=99t use the =
callback mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D =
URL that Annabelle mentioned in the other thread, or they might just =
print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is =
common today.
XYZ=E2=80=
=99s interaction structure allows the composition of these things, under =
the control of the client. This is exactly why it=E2=80=99s important to =
be able to specify how to get to the AS and how to get back as separate =
items, so that the client can compose the combination that makes the =
most sense for that client.
=E2=80=94 Justin
I got ahead of myself. A =
completion URI protects the User only if the User is sent back to the =
same channel the transaction started so the Client can confirm it is the =
same User that started the transaction.
so this does not help the =
security:
"Being=
able to provide a completion URI even if the user is starting on a =
device is a great insight on how to address the threat above."
=E1=90=A7 The =
lightbulb finally clicked on for me. Thanks for your patience.
The threat you are =
describing is where the attacker starts a transaction at the client, and =
gets the victim to complete it. Correct?
I still think the Client should be =
able to signal if it will be doing a redirect vs showing a QR code (or =
wants to do both).
Being able to provide a completion URI even if the user is =
starting on a device is a great insight on how to address the threat =
above.
I'm going to ponder how to align XAuth more with these =
features of XYZ.
=E1=90=A7
On Feb 21, 2020, at =
1:54 PM, Dick Hardt <
dick.hardt@gmail.com> wrote:
I=E2=80=99m in =
complete agreement with Annabelle. In XYZ we realized =
that both the QR Code and Authorization Code, and that the only =
difference is how the user gets back to the client. So instead of =
inventing a new type of interaction, we split them. In XYZ, we =
have:
This=
sentence looks to be missing =
something.
Apologies: We realized they both used =
AS-composed URLs to get the user to the AS in a web browser for =
interaction purposes.
- redirect: tells =
the AS that the client can send the user to an arbitrary URL (and the AS =
doesn=E2=80=99t care how the client gets that info to the user; could be =
a redirect or an image or send a push notification to a secondary =
device, we don=E2=80=99t care as long as the user shows up in a browser =
at the AS =E2=80=94 so maybe this field can be renamed to be more =
universally accurate)
As stated in this thread, it may be =
useful for the AS to know if the URL will be in a QR code, or in a full =
redirect.
In =
XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has =
to do, so it needs to know the difference between a popup, and a full =
browser redirect. This is targetted at SPAs, where an additional URL to =
redirect to is extra work.
- code: tells the AS that the client can present a =
short code the user can type (along with a static URL the user can get =
to, maybe by typing the URL manually, but it=E2=80=99s not =
dynamic/arbitrary like the redirect method)
- callback: tells the AS that the client can receive =
the completion message from a front channel interaction through a =
redirect. Note that the client might have gotten to the AS through a =
redirect on-device, through a QR-code off device, or through some other =
magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=
=99s only concerned with how to get the user =
:back:.
In a full redirect, the Client wants =
the AS to send the user back so that it can continue.
The only parameter in =
the completion message is the nonce, which seems superfluous. See =
below.
These three can be =
combined in different ways depending on what you want to do at the =
client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style =
authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =
=E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain =
user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re =
doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D=
to get the long URL. If you=E2=80=99re doing a user code and a QR code =
together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D =
to get the long URL and the short code not he screen at the same =
time.
On =
top of that, they can be combined with other methods. Maybe I can send =
the user to an arbitrary URL but also display a human-readable =
verification code (like CIBA), or send something in a push notification =
but also give them a message to type, or I=E2=80=99m getting claims from =
an agent but I want them redirected back through the browser. The client =
gets to decide what kinds of interaction it can do and how to use these =
pieces in ways that make the most =
sense.
Per my question later in this thread, =
why would the Client not know what interaction it wants prior to the =
request?
What do you mean? The client does know =
what it wants and that=E2=80=99s why it=E2=80=99s asking for what it =
wants. We=E2=80=99re debating different methods for the client to ask =
for what it wants. This question does not make sense to me.
If the AS is doing CIBA, that is not a =
decision just for the Client. Both the AS and the Client need to know =
they are doing CIBA. (FWIW: I think this work supersedes =
CIBA)
As I=E2=80=99ve stated previously, I =
believe the interaction methods here can supersede CIBA.
Additionally, different interactions =
have different risk profiles. Sophisticated ASes will use that signal in =
the risk assessment, and may do ask for additional authentication or =
verification.
Yes, exactly my point. Because =
different interactions have different risks, the AS will need to be able =
to decide which interactions it=E2=80=99s OK with for a given request. =
This could vary based on what=E2=80=99s being requested, or who=E2=80=99s =
doing the requesting.
An interesting =
difference between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps =
the concept of the =E2=80=9Cauthorization code=E2=80=9D in the callback =
response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=
=80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D =
which is hashed along with a pair of nonces generated by the client and =
the AS in the back channel. This binds the front channel response to =
both the back channel request and the back channel response for a given =
transaction =E2=80=94 and note that I=E2=80=99m really open to having a =
better way to generate and calculate such a binding, but I think this =
works. In any event, this protects the client from session fixation and =
injection on the return from the front channel that it=E2=80=99s =
susceptible to in a pure polling model, and the hashing approach =
basically combines the security parameters of the OAuth 2 authorization =
code and (to an extent) state, PKCE=E2=80=99s code_challenge, and =
OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99=
re coming back to the client and you can validate the hash and present =
the reference parameter. If you=E2=80=99re doing just plain polling, you =
don=E2=80=99t have that protection =E2=80=94 but the client and the AS =
are aware of that risk, and there=E2=80=99s an option to prevent =
it.
XAuth has =
removed the authorization code concept in its redirect return, and =
clients only do polling against the GS API in order to get tokens. While =
I obviously think it=E2=80=99s very valuable to remove things from the =
front channel, I don=E2=80=99t think this is something we can remove =
without opening up attack surfaces that have already been identified in =
previous protocols. I would like to understand why XAuth is not =
susceptible to the same kinds of attacks, or if it is, what mitigations =
there are for them.
Unlike OAuth 2.0, there =
are no parameters in the front channel response to the Client. The =
redirect back to the Client is only needed to return the interaction =
back to the Client.
This argument rings =
tautologically hollow =E2=80=94 there are no parameters because you=E2=80=99=
ve defined that there aren=E2=80=99t any in XAuth. XYZ does have =
parameters, to tie the front and back channel requests together when =
doing redirect back and forth.
If you=E2=80=99re not doing a redirect =
back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), =
then it=E2=80=99s a polling mechanism like XAuth, the device flow, etc. =
There are very real risks to this.
XAuth (and XYZ) have a different flow than OAuth 2.0 (or =
OAuth 1.0)
In =
OAuth, the AS gives a code to the User to give to the Client that the =
Client then gives to the GS.
In XAuth, the AS gives a "code" to the =
Client that givers it to the User to give to the GS.
In XAuth, the "code" is =
either a user code, or something embedded in the URI the User is =
redirected to.
Therefore, there is nothing to protect in the redirect back =
to the Client.
If I'm missing an attack, please elaborate how it would =
happen.
OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a =
similar request initiation step to what we see in XYZ, XAuth, PAR, =
FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same kind of =
issue.
=E2=80=94 =
Justin
Thanks =
for the update, Dick! I=E2=80=99m going to confine my comments here to =
interaction mode design, setting aside whether or not we need =
=E2=80=9Cpopup=E2=80=9D. :D
Once the GS hands that URI back to the Client, it has zero =
control over how the Client uses it. The Client could present any URI =
(of a reasonable size) into a QR code, or present it as a clickable =
link, or redirect to it, or open it in an external browser, or do any =
number of other as-yet-not-invented things with it. Moreover, the Client =
may not know yet what it wants to do with it. So what value is there in =
distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =
=E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI =
for <some other machine-driven interaction mode>=E2=80=9D?
Even if we consider things like QR code data capacity, =
that=E2=80=99s really just a URI length limitation, which could apply to =
non-QR interaction modes, e.g., if the Client device wants to =
communicate the URI over an extremely bandwidth-constrained channel. And =
it=E2=80=99s not clear to me how including a URI length limitation in =
the request helps. If a GS is capable of generating a shorter URI, why =
wouldn=E2=80=99t it always return that? On the client side, it can look =
at the length of the URI provided and decide what to do with it (e.g., =
render a QR code or display it or do nothing with it).
So =
that really leaves us with two interaction modes that we need:
- =E2=80=9Curi=E2=80=9D, which returns a full URI that may not =
be human friendly; and
- =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a =
code entry page, both of which are human-friendly.
Those could be combinable to get both, and even if we don=E2=80=
=99t go down the multiple interaction mode route we could add the full =
URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t =
hurt anything to do so.
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
Added in =
user code interaction and aligned QR code to be a superset of user =
code.
=E1=90=A7 -- Txauth mailing =
listTxauth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth =
blockquote>
=
--Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1--
From nobody Fri Mar 6 08:45:00 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D223A0AA5 for ; Fri, 6 Mar 2020 08:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.435
X-Spam-Level:
X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.663, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vf4CqYVn9ATL for ; Fri, 6 Mar 2020 08:44:58 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3CF3A0AA8 for ; Fri, 6 Mar 2020 08:44:57 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id v11so3122982wrm.9 for ; Fri, 06 Mar 2020 08:44:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=g/67VyLeYMvCEKDi9DZKyIWP7WrPYcON2j+ukIRIJx4=; b=av+bE6BB70xMoMQn+ZRjwvuqi289lWvFpi2JXhV7+qgbweDkiAP6lggTcb206mr4i8 uGTJGDKqspgRoSLkGbqkhujcYrm2pt/Ps3nv41SzLFZCzR0DQLenI3Jju7xwVvSdJCTR 4YZEV8XvL9BXiL+mb3vJcVXAp1UMFYhkmoebrP2i3m/kPcwPEmyyCWw+emRZShYORi/T NGr4GJhhPMQAT4l24z8YJjisL6cEGFb2Q9k1s0rxgQLyjQB8Rja1C3clTrRe5+zX8lxU fEFrgEhOzUqzj9H1Q2QlWnXNeNCbMBv/QmytVjHza/Zmf48zZoG6vgXwQXciAx67hcCf p69A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=g/67VyLeYMvCEKDi9DZKyIWP7WrPYcON2j+ukIRIJx4=; b=MI+52fBvzK2QR/XZSoVy/Zgi97pVp7aJR+PZ4ndTd75CivuuH/YQVybXrViWRjx/Ds dNs0ihvHloeNBsDdUJeJQS7RBaZx+IiU1cns8eE27C+cnIBJBQqx1wMkePf6n1LFjCFb v0sXzl8LIvW/LuxEgJhLuJOMf922jXcYuZvnVDgPcOO7C76zdz16IMmwVcwmuRpch6iH b2XJffbMCxWCX7TdNiTEml4YVpp5NbvRH9skFWmkToT0awjA+3TgkJmO7mZYYqLqBzbS /09l7kY4xdNkCyukmYeakJ+HMZTQCJU2yzpH1ePasQ5PQ9r0IeqD2klk4XAMswfAnmtR T+Dg==
X-Gm-Message-State: ANhLgQ3F6QPcACKdU7r7lrE8fH9Co+YE2js6M9OHLGDdA4h2Almpszbu BRTntwr+UpHK6lpDoZwEYBFx0euf
X-Google-Smtp-Source: ADFU+vvV5uuutPZ38DyaLx6/DNS7lym2Edb/nYuoiWri1v4BIriim8V1STzXEW72TYFbRk9lkouysg==
X-Received: by 2002:adf:f607:: with SMTP id t7mr4764265wrp.36.1583513095863; Fri, 06 Mar 2020 08:44:55 -0800 (PST)
Received: from [10.0.0.144] (bzq-79-178-61-110.red.bezeqint.net. [79.178.61.110]) by smtp.gmail.com with ESMTPSA id t1sm54002688wrs.41.2020.03.06.08.44.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2020 08:44:55 -0800 (PST)
User-Agent: Microsoft-MacOutlook/10.22.0.200209
Date: Fri, 06 Mar 2020 18:44:53 +0200
From: Yaron Sheffer
To: "txauth@ietf.org"
Message-ID:
Thread-Topic: Call for charter consensus - TxAuth WG
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At:
Subject: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 06 Mar 2020 16:45:00 -0000
Hi Everyone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu=
th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest in proceedin=
g with this work.=C2=A0 Please do so by responding to the following questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?=C2=A0 O=
r do you have major objections, blocking concerns or feedback (if so please =
elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the dra=
fts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char=
ter should be amended In a significant way, please reply on a separate threa=
d.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for=
mation of a new WG. Given the constraints of the chartering process, regardl=
ess of the outcome of this consensus call, we will be meeting in Vancouver a=
s a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---
This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authoriz=
ing party to delegate access to client software through an authorization ser=
ver. It will expand upon the uses cases currently supported by OAuth 2.0 and=
OpenID Connect (itself an extension of OAuth 2.0) to support authorizations=
scoped as narrowly as a single transaction, provide a clear framework for i=
nteraction among all parties involved in the protocol flow, and remove unnec=
essary dependence on a browser or user-agent for coordinating interactions.=20
The delegation process will be acted upon by multiple parties in the protoc=
ol, each performing a specific role. The protocol will decouple the interact=
ion channels, such as the end user=E2=80=99s browser, from the delegation channel,=
which happens directly between the client and the authorization server (in =
contrast with OAuth 2.0 which is initiated by the client redirecting the use=
r=E2=80=99s browser). The client and AS will involve a user to make an authorizati=
on decision as necessary through interaction mechanisms indicated by the pro=
tocol. This decoupling avoids many of the security concerns and technical ch=
allenges of OAuth 2.0 and provides a non-invasive path for supporting future=
types of clients and interaction channels.
Additionally, the delegation process will allow for:
- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the party operating t=
he client requesting access
- A variety of client applications, including Web, mobile, single-page, and=
interaction-constrained applications
The group will define extension points for this protocol to allow for flexi=
bility in areas including:
- Cryptographic agility for keys, message signatures, and proof of possessi=
on=20
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource=
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc=
ess (including identity)
Additionally, the group will provide mechanisms for management of the proto=
col lifecycle including:
- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers
Although the artifacts for this work are not intended or expected to be bac=
kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t=
o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w=
here possible.
This group is not chartered to develop extensions to OAuth 2.0, and as such=
will focus on new technological solutions not necessarily compatible with O=
Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed =
in the OAuth Working Group, including functionality back-ported from the pro=
tocol developed here to OAuth 2.0.
The group is chartered to develop mechanisms for applying cryptographic met=
hods, such as JOSE and COSE, to the delegation process. This group is not ch=
artered to develop new cryptographic methods.=20
The initial work will focus on using HTTP for communication between the cli=
ent and the authorization server, taking advantage of optimization features =
of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping =
to other protocols such as COAP when doing so does not conflict with the pri=
mary focus.
Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol for TLS, detach=
ed HTTP signature, and embedded HTTP signatures
- Identity and authentication conveyance mechanisms
- Guidelines for use of protocol extension points
From nobody Fri Mar 6 16:24:44 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE963A0E45 for ; Fri, 6 Mar 2020 16:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 01fImmR8djxl for ; Fri, 6 Mar 2020 16:24:39 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DA33A0E41 for ; Fri, 6 Mar 2020 16:24:38 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id d12so4057667lji.4 for ; Fri, 06 Mar 2020 16:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=toNM0bIHmHn6ZqTTgXS/GGznOtCiQyySW4G/YOZFDGs=; b=GEswzwX5gwPhBRygMuB7uEdUVZpsP0YQhCNUcDG6hQl0ZzaJ7F0tBLN8fDi53noyNa WfRHtMzNZLAGN6Kay0ar7Pl4+jaERzFp4lEjLARXknani/1rhOjE+NakQL6GQBwfXRGi /7c7EPC4KCTRfq/QiFqhKt7pNqqN3KJkHF2ZsSXzby9ecxqgdQLcyvpY5w8+JrjdExHx j1ozgY9EtopqVw7YZq4tvFyLJ55T/8XoPFY84M/tPImYEgcDgJJQ+VwMwbhQ2bqg1Lr6 RRzz1LfFPF0vnLj1grPr59d+dF1FAXRh5vVupARuqB/Ql97I1qcRlOswEzy2wWoi2Ath 78TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=toNM0bIHmHn6ZqTTgXS/GGznOtCiQyySW4G/YOZFDGs=; b=ssldcGcR/H3kAcdFQkgxFvzCs/KTwkqmTSv9A2ZkbwbM8tgeZ2EvmeePu/MRcXxC6h RHniTJ+CqcGKRKx/Hh5kCIFzYeQPCo8K8DZRqf5+dm62VnN/ZK3RqXWZpS+9Y7Lx2aAp CcIW9xBLJk9HmrcllIvxG3Rxn6ChdpoQf8Rrn852u09GBBFzxw2k41kR5drDUBVZ0inI b++kdGEty2xutJ2etpcYx5GrN3nIJcMRciYEtqYfCK2lBCmWpxMJEuXmf80r2lJd4Z7z 5ul2/eI/NMkYMmWrtrXo9IznN1RgqxMAleq+9JXMs0I5MKk1Tx+H3opWUgtEjaKfqje5 Vw4g==
X-Gm-Message-State: ANhLgQ1SMoxVbkbdU4m303vPbe7JY+u/sG5iOpAL5m7KsN4ZXs4UnxGr 0X+tfTd81hVc7VH0nx1cmRKnywlnYDTweGszxkM=
X-Google-Smtp-Source: ADFU+vtlAch4O9+WTvF6ZrmeJYxv4VhO7Ujq5jObgtfeuPIbJo1XYCyai7JwAPcgM3g3Cj0RfaDkAd7OXdLkxm7zPFU=
X-Received: by 2002:a2e:730e:: with SMTP id o14mr3487209ljc.51.1583540676352; Fri, 06 Mar 2020 16:24:36 -0800 (PST)
MIME-Version: 1.0
References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu>
In-Reply-To:
From: Dick Hardt
Date: Fri, 6 Mar 2020 16:24:09 -0800
Message-ID:
To: Justin Richer
Cc: "Richard Backman, Annabelle" , "txauth@ietf.org"
Content-Type: multipart/alternative; boundary="000000000000805e2305a038cb82"
Archived-At:
Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 00:24:43 -0000
--000000000000805e2305a038cb82
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Your response did not address the question I had. I'm not talking about UMA
or CIBA use cases -- I'm looking at requirements for addressing session
fixation.
To prevent the fixation attack, and assuming the Client can keep secrets,
does the AS need to know the User is the same at the Client and the AS?
IE: is it sufficient for the Client to verify that the User that came back
from the AS, is the same User the Client sent to the AS?
wrt. the Client keeping secrets. If the Client cannot keep a secret, an
attacker can deduce what a Client needs in a response -- so the Client
needs to get something from the AS via the redirect of the User to verify
it is the Client User is the same as the AS User.
=E1=90=A7
On Mon, Mar 2, 2020 at 11:42 AM Justin Richer wrote:
> Working with that kind of setup, where you=E2=80=99ve got two different u=
sers at
> the client and the AS, is the driving goal behind CIBA and UMA, and in so=
me
> instances, the device flow. All of these have a polling mechanism that
> allows an asynchronous update.
>
> In XYZ, the client explicitly signals this kind of expectation by not
> sending a =E2=80=9Ccallback=E2=80=9D field in its request, indicating tha=
t it doesn=E2=80=99t
> expect the approving user to get returned through the front channel. It=
=E2=80=99s
> not just about signaling the client about when to poll next, it=E2=80=99s=
about
> signaling the intent to poll at all.
>
> It=E2=80=99s a different security profile that both the AS and the Client=
need to
> know about, since it might not be appropriate for all different forms of
> access.
>
> XYZ (and to some extent XAuth) also allows the client to present
> information about the current user at the client so that the AS can figur=
e
> out if it expects the same user or a different user during the interactiv=
e
> bits by allowing things to be passed in the =E2=80=9Cuser=E2=80=9D object=
of the request.
> It=E2=80=99s not just there as a login hint, at least in XYZ. There are s=
ome
> details from UMA and CIBA that we can import, like the user-displayed
> confirmation codes and the like, that can help security and usability of
> the overall protocol. But as is the case with just about everything in XY=
Z,
> I didn=E2=80=99t want to add it to the spec document until I=E2=80=99d im=
plemented it to
> make sure that it made sense to carry that information through to the
> different parties.
>
> =E2=80=94 Justin
>
> On Feb 28, 2020, at 5:56 PM, Dick Hardt wrote:
>
> Thinking about this, the fixation attack is against the Client where the
> attacker is at the Client, and the victim is at the AS.
>
> Does the AS need to know the attacker and victim are different? IE, if th=
e
> client knows that the User at the Client is the same as the User that cam=
e
> from the AS, have we prevented the attack?
> =E1=90=A7
>
> On Tue, Feb 25, 2020 at 7:38 AM Justin Richer wrote:
>
>> That=E2=80=99s good enough for the AS, but is it good enough for the cli=
ent? The
>> hash allows the client to make sure that the reference they=E2=80=99re g=
etting back
>> in the front channel is related to something they sent out in the first
>> place. We originally had a =E2=80=9Cstate=E2=80=9D parameter like OAuth =
2 for this purpose,
>> but realized that since the client can push its callback URI we didn=E2=
=80=99t need
>> that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80=9D =
and =E2=80=9Cc_hash=E2=80=9D have
>> in OIDC, we added this simple hash parameter that the client can check
>> before it calls the TX endpoint again.
>>
>> =E2=80=94 Justin
>>
>> On Feb 21, 2020, at 8:12 PM, Dick Hardt wrote:
>>
>>
>> The Client presents the interact_ref to the AS with the transaction
>> handle. The AS will be able to tell the Client if the interact_ref belon=
gs
>> to the transaction.
>>
>> Why is that enough?
>> =E1=90=A7
>>
>> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer wrote:
>>
>>> The hash offers the same kinds of protections to the client that the
>>> OIDC nonce does =E2=80=94 it binds the front channel return to somethin=
g you get
>>> from the back channel.
>>>
>>> In other words, the client can be sure that the return value that it=E2=
=80=99s
>>> getting is related to the request it made in the first place, and not
>>> another one. Clients using per-request redirect URIs can also help with
>>> this, but this is something that the server can provide directly.
>>>
>>> =E2=80=94 Justin
>>>
>>> On Feb 21, 2020, at 4:14 PM, Dick Hardt wrote:
>>>
>>> While I can see the value of the interact_ref (aka interaction_ref) in
>>> the return URI that allows the Client to ensure the user that started t=
he
>>> transaction is the same one that interacted at the AS, I don't understa=
nd
>>> why a hash is required. Would you elaborate?
>>> =E1=90=A7
>>>
>>> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer wrote:
>>>
>>>> But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, =
which is a very
>>>> common case. For cases where the client doesn=E2=80=99t expect the use=
r to come
>>>> back on the same channel, then they don=E2=80=99t use the callback mec=
hanism. They
>>>> might use the =E2=80=9Cfinish message=E2=80=9D URL that Annabelle ment=
ioned in the other
>>>> thread, or they might just print out =E2=80=9Cyou=E2=80=99re done now!=
=E2=80=9D at the AS, which is
>>>> common today.
>>>>
>>>> XYZ=E2=80=99s interaction structure allows the composition of these th=
ings,
>>>> under the control of the client. This is exactly why it=E2=80=99s impo=
rtant to be
>>>> able to specify how to get to the AS and how to get back as separate i=
tems,
>>>> so that the client can compose the combination that makes the most sen=
se
>>>> for that client.
>>>>
>>>> =E2=80=94 Justin
>>>>
>>>>
>>>> On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote:
>>>>
>>>> I got ahead of myself. A completion URI protects the User only if the
>>>> User is sent back to the same channel the transaction started so the C=
lient
>>>> can confirm it is the same User that started the transaction.
>>>>
>>>> so this does not help the security:
>>>>
>>>> "Being able to provide a completion URI even if the user is starting o=
n
>>>> a device is a great insight on how to address the threat above."
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt
>>>> wrote:
>>>>
>>>>> The lightbulb finally clicked on for me. Thanks for your patience.
>>>>>
>>>>> The threat you are describing is where the attacker starts a
>>>>> transaction at the client, and gets the victim to complete it. Correc=
t?
>>>>>
>>>>> I still think the Client should be able to signal if it will be doing
>>>>> a redirect vs showing a QR code (or wants to do both).
>>>>>
>>>>> Being able to provide a completion URI even if the user is starting o=
n
>>>>> a device is a great insight on how to address the threat above.
>>>>>
>>>>> I'm going to ponder how to align XAuth more with these features of XY=
Z.
>>>>> =E1=90=A7
>>>>>
>>>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer
>>>>> wrote:
>>>>>
>>>>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote=
:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer
>>>>>> wrote:
>>>>>>
>>>>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realize=
d that
>>>>>>> both the QR Code and Authorization Code, and that the only differen=
ce is
>>>>>>> how the user gets back to the client. So instead of inventing a new
>>>>>>> type of interaction, we split them. In XYZ, we have:
>>>>>>>
>>>>>>
>>>>>> This sentence looks to be missing something.
>>>>>>
>>>>>>
>>>>>> Apologies: We realized they both used AS-composed URLs to get the
>>>>>> user to the AS in a web browser for interaction purposes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> - redirect: tells the AS that the client can send the user to an
>>>>>>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets =
that info to the
>>>>>>> user; could be a redirect or an image or send a push notification t=
o a
>>>>>>> secondary device, we don=E2=80=99t care as long as the user shows u=
p in a browser
>>>>>>> at the AS =E2=80=94 so maybe this field can be renamed to be more u=
niversally
>>>>>>> accurate)
>>>>>>>
>>>>>>
>>>>>> As stated in this thread, it may be useful for the AS to know if the
>>>>>> URL will be in a QR code, or in a full redirect.
>>>>>>
>>>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a
>>>>>> Client has to do, so it needs to know the difference between a popup=
, and a
>>>>>> full browser redirect. This is targetted at SPAs, where an additiona=
l URL
>>>>>> to redirect to is extra work.
>>>>>>
>>>>>>
>>>>>>> - code: tells the AS that the client can present a short code the
>>>>>>> user can type (along with a static URL the user can get to, maybe b=
y typing
>>>>>>> the URL manually, but it=E2=80=99s not dynamic/arbitrary like the r=
edirect method)
>>>>>>> - callback: tells the AS that the client can receive the completio=
n
>>>>>>> message from a front channel interaction through a redirect. Note t=
hat the
>>>>>>> client might have gotten to the AS through a redirect on-device, th=
rough a
>>>>>>> QR-code off device, or through some other magic, and this field isn=
=E2=80=99t
>>>>>>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how =
to get the user :back:.
>>>>>>>
>>>>>>
>>>>>> In a full redirect, the Client wants the AS to send the user back so
>>>>>> that it can continue.
>>>>>>
>>>>>> The only parameter in the completion message is the nonce, which
>>>>>> seems superfluous. See below.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> These three can be combined in different ways depending on what you
>>>>>>> want to do at the client. Let=E2=80=99s say you=E2=80=99re doing an=
d OAuth2 style
>>>>>>> authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D an=
d =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re
>>>>>>> doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. =
If you=E2=80=99re doing just a QR code
>>>>>>> with polling, you use just =E2=80=9Credirect=E2=80=9D to get the lo=
ng URL. If you=E2=80=99re doing
>>>>>>> a user code and a QR code together, you use =E2=80=9Credirect=E2=80=
=9D and =E2=80=9Ccode=E2=80=9D to get
>>>>>>> the long URL and the short code not he screen at the same time.
>>>>>>>
>>>>>>> On top of that, they can be combined with other methods. Maybe I ca=
n
>>>>>>> send the user to an arbitrary URL but also display a human-readable
>>>>>>> verification code (like CIBA), or send something in a push notifica=
tion but
>>>>>>> also give them a message to type, or I=E2=80=99m getting claims fro=
m an agent but I
>>>>>>> want them redirected back through the browser. The client gets to d=
ecide
>>>>>>> what kinds of interaction it can do and how to use these pieces in =
ways
>>>>>>> that make the most sense.
>>>>>>>
>>>>>>
>>>>>> Per my question later in this thread, why would the Client not know
>>>>>> what interaction it wants prior to the request?
>>>>>>
>>>>>>
>>>>>> What do you mean? The client does know what it wants and that=E2=80=
=99s why
>>>>>> it=E2=80=99s asking for what it wants. We=E2=80=99re debating differ=
ent methods for the
>>>>>> client to ask for what it wants. This question does not make sense t=
o me.
>>>>>>
>>>>>>
>>>>>> If the AS is doing CIBA, that is not a decision just for the Client.
>>>>>> Both the AS and the Client need to know they are doing CIBA. (FWIW: =
I think
>>>>>> this work supersedes CIBA)
>>>>>>
>>>>>>
>>>>>> As I=E2=80=99ve stated previously, I believe the interaction methods=
here can
>>>>>> supersede CIBA.
>>>>>>
>>>>>>
>>>>>> Additionally, different interactions have different risk profiles.
>>>>>> Sophisticated ASes will use that signal in the risk assessment, and =
may do
>>>>>> ask for additional authentication or verification.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, exactly my point. Because different interactions have different
>>>>>> risks, the AS will need to be able to decide which interactions it=
=E2=80=99s OK
>>>>>> with for a given request. This could vary based on what=E2=80=99s be=
ing requested,
>>>>>> or who=E2=80=99s doing the requesting.
>>>>>>
>>>>>>
>>>>>>> An interesting difference between XYZ and XAuth=E2=80=99s approache=
s is that
>>>>>>> XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D i=
n the callback response
>>>>>>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=
=80=9D field). In XYZ, you
>>>>>>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with=
a pair of nonces
>>>>>>> generated by the client and the AS in the back channel. This binds =
the
>>>>>>> front channel response to both the back channel request and the bac=
k
>>>>>>> channel response for a given transaction =E2=80=94 and note that I=
=E2=80=99m really open to
>>>>>>> having a better way to generate and calculate such a binding, but I=
think
>>>>>>> this works. In any event, this protects the client from session fix=
ation
>>>>>>> and injection on the return from the front channel that it=E2=80=99=
s susceptible to
>>>>>>> in a pure polling model, and the hashing approach basically combine=
s the
>>>>>>> security parameters of the OAuth 2 authorization code and (to an ex=
tent)
>>>>>>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in o=
ne element. This is only
>>>>>>> applicable if you=E2=80=99re coming back to the client and you can =
validate the
>>>>>>> hash and present the reference parameter. If you=E2=80=99re doing j=
ust plain
>>>>>>> polling, you don=E2=80=99t have that protection =E2=80=94 but the c=
lient and the AS are
>>>>>>> aware of that risk, and there=E2=80=99s an option to prevent it.
>>>>>>>
>>>>>>> XAuth has removed the authorization code concept in its redirect
>>>>>>> return, and clients only do polling against the GS API in order to =
get
>>>>>>> tokens. While I obviously think it=E2=80=99s very valuable to remov=
e things from
>>>>>>> the front channel, I don=E2=80=99t think this is something we can r=
emove without
>>>>>>> opening up attack surfaces that have already been identified in pre=
vious
>>>>>>> protocols. I would like to understand why XAuth is not susceptible =
to the
>>>>>>> same kinds of attacks, or if it is, what mitigations there are for =
them.
>>>>>>>
>>>>>>
>>>>>> Unlike OAuth 2.0, there are no parameters in the front channel
>>>>>> response to the Client. The redirect back to the Client is only need=
ed to
>>>>>> return the interaction back to the Client.
>>>>>>
>>>>>>
>>>>>> This argument rings tautologically hollow =E2=80=94 there are no par=
ameters
>>>>>> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAut=
h. XYZ does have
>>>>>> parameters, to tie the front and back channel requests together when=
doing
>>>>>> redirect back and forth.
>>>>>>
>>>>>> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=
=80=9Ccallback=E2=80=9D
>>>>>> interaction block), then it=E2=80=99s a polling mechanism like XAuth=
, the device
>>>>>> flow, etc. There are very real risks to this.
>>>>>>
>>>>>>
>>>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0)
>>>>>>
>>>>>> In OAuth, the AS gives a code to the User to give to the Client that
>>>>>> the Client then gives to the GS.
>>>>>>
>>>>>> In XAuth, the AS gives a "code" to the Client that givers it to the
>>>>>> User to give to the GS.
>>>>>>
>>>>>> In XAuth, the "code" is either a user code, or something embedded in
>>>>>> the URI the User is redirected to.
>>>>>>
>>>>>> Therefore, there is nothing to protect in the redirect back to the
>>>>>> Client.
>>>>>>
>>>>>> If I'm missing an attack, please elaborate how it would happen.
>>>>>>
>>>>>>
>>>>>> One form of impersonation is well documented:
>>>>>> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-=
aa759250a0e7
>>>>>>
>>>>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar req=
uest initiation step to
>>>>>> what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s sus=
ceptible to the
>>>>>> same kind of issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> =E2=80=94 Justin
>>>>>>>
>>>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <
>>>>>>> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my commen=
ts here
>>>>>>> to interaction mode design, setting aside whether or not we need =
=E2=80=9Cpopup=E2=80=9D. :D
>>>>>>>
>>>>>>> Once the GS hands that URI back to the Client, it has zero control
>>>>>>> over how the Client uses it. The Client could present any URI (of a
>>>>>>> reasonable size) into a QR code, or present it as a clickable link,=
or
>>>>>>> redirect to it, or open it in an external browser, or do any number=
of
>>>>>>> other as-yet-not-invented things with it. Moreover, the Client may =
not know
>>>>>>> yet what it wants to do with it. So what value is there in distingu=
ishing
>>>>>>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9C=
I want a URI for a QR code=E2=80=9D vs.
>>>>>>> =E2=80=9CI want a URI for =E2=80=9D?
>>>>>>>
>>>>>>> Even if we consider things like QR code data capacity, that=E2=80=
=99s really
>>>>>>> just a URI length limitation, which could apply to non-QR interacti=
on
>>>>>>> modes, e.g., if the Client device wants to communicate the URI over=
an
>>>>>>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear=
to me how
>>>>>>> including a URI length limitation in the request helps. If a GS is =
capable
>>>>>>> of generating a shorter URI, why wouldn=E2=80=99t it always return =
that? On the
>>>>>>> client side, it can look at the length of the URI provided and deci=
de what
>>>>>>> to do with it (e.g., render a QR code or display it or do nothing w=
ith it).
>>>>>>>
>>>>>>> So that really leaves us with two interaction modes that we need:
>>>>>>>
>>>>>>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not b=
e human
>>>>>>> friendly; and
>>>>>>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a cod=
e entry page,
>>>>>>> both of which are human-friendly.
>>>>>>>
>>>>>>>
>>>>>>> Those could be combinable to get both, and even if we don=E2=80=99t=
go down
>>>>>>> the multiple interaction mode route we could add the full URI to th=
e =E2=80=9Ccode=E2=80=9D
>>>>>>> interaction object. It wouldn=E2=80=99t hurt anything to do so.
>>>>>>>
>>>>>>> =E2=80=93
>>>>>>> Annabelle Backman (she/her)
>>>>>>> AWS Identity
>>>>>>> https://aws.amazon.com/identity/
>>>>>>>
>>>>>>>
>>>>>>> *From: *Txauth on behalf of Dick Hardt <
>>>>>>> dick.hardt@gmail.com>
>>>>>>> *Date: *Tuesday, February 18, 2020 at 6:04 PM
>>>>>>> *To: *"txauth@ietf.org"
>>>>>>> *Subject: *[Txauth] Fwd: New Version Notification for
>>>>>>> draft-hardt-xauth-protocol-03.txt
>>>>>>>
>>>>>>> Added in user code interaction and aligned QR code to be a superset
>>>>>>> of user code.
>>>>>>> Fixed descriptions.
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ---------
>>>>>>> From:
>>>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM
>>>>>>> Subject: New Version Notification for
>>>>>>> draft-hardt-xauth-protocol-03.txt
>>>>>>> To: Dick Hardt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt
>>>>>>> has been successfully submitted by Dick Hardt and posted to the
>>>>>>> IETF repository.
>>>>>>>
>>>>>>> Name: draft-hardt-xauth-protocol
>>>>>>> Revision: 03
>>>>>>> Title: The XAuth Protocol
>>>>>>> Document date: 2020-02-18
>>>>>>> Group: Individual Submission
>>>>>>> Pages: 53
>>>>>>> URL:
>>>>>>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.=
txt
>>>>>>> Status:
>>>>>>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
>>>>>>> Htmlized:
>>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03
>>>>>>> Htmlized:
>>>>>>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
>>>>>>> Diff:
>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03
>>>>>>>
>>>>>>> Abstract:
>>>>>>> Client software often desires resources or identity claims that
>>>>>>> are
>>>>>>> independent of the client. This protocol allows a user and/or
>>>>>>> resource owner to delegate resource authorization and/or release
>>>>>>> of
>>>>>>> identity claims to a server. Client software can then request
>>>>>>> access
>>>>>>> to resources and/or identity claims by calling the server. The
>>>>>>> server acquires consent and authorization from the user and/or
>>>>>>> resource owner if required, and then returns to the client
>>>>>>> software
>>>>>>> the authorization and identity claims that were approved. This
>>>>>>> protocol can be extended to support alternative authorizations,
>>>>>>> claims, interactions, and client authentication mechanisms.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>> submission
>>>>>>> until the htmlized version and diff are available at tools.ietf.org=
.
>>>>>>>
>>>>>>> The IETF Secretariat
>>>>>>> =E1=90=A7
>>>>>>> --
>>>>>>> Txauth mailing list
>>>>>>> Txauth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
--000000000000805e2305a038cb82
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Your response did not address the question I had. I'm =
not talking about=C2=A0UMA or CIBA use cases -- I'm looking at requirem=
ents for addressing session fixation.
To prevent the fix=
ation attack, and assuming the Client can keep secrets, does the AS need to=
know the User is the same at the Client and the AS?
IE: is it sufficient for the Client to verify that the User that came ba=
ck from the AS, is the same User the Client sent to the AS?<=
/div>
wrt. the Client keeping secrets. If the Client cannot keep a secr=
et, an attacker can deduce what a Client needs in a response -- so the Clie=
nt needs to get something from the AS via the redirect of the User to verif=
y it is the Client User is the same as the AS User.
=
=E1=90=A7
Working with that kind of setup, where you=E2=80=99ve got two dif=
ferent users at the client and the AS, is the driving goal behind CIBA and =
UMA, and in some instances, the device flow. All of these have a polling me=
chanism that allows an asynchronous update.
In XYZ, the =
client explicitly signals this kind of expectation by not sending a =E2=80=
=9Ccallback=E2=80=9D field in its request, indicating that it doesn=E2=80=
=99t expect the approving user to get returned through the front channel. I=
t=E2=80=99s not just about signaling the client about when to poll next, it=
=E2=80=99s about signaling the intent to poll at all.
<=
div>It=E2=80=99s a different security profile that both the AS and the Clie=
nt need to know about, since it might not be appropriate for all different =
forms of access.=C2=A0
XYZ (and to some extent XAu=
th) also allows the client to present information about the current user at=
the client so that the AS can figure out if it expects the same user or a =
different user during the interactive bits by allowing things to be passed =
in the =E2=80=9Cuser=E2=80=9D object of the request. It=E2=80=99s not just =
there as a login hint, at least in XYZ. There are some details from UMA and=
CIBA that we can import, like the user-displayed confirmation codes and th=
e like, that can help security and usability of the overall protocol. But a=
s is the case with just about everything in XYZ, I didn=E2=80=99t want to a=
dd it to the spec document until I=E2=80=99d implemented it to make sure th=
at it made sense to carry that information through to the different parties=
.
=C2=A0=E2=80=94 Justin
Thinking about this, the fixation atta=
ck is against the Client where the attacker is at the Client, and the victi=
m is at the AS.
Does the AS need to know the attacker an=
d victim are different? IE, if the client knows that the User at the Client=
is the same as the User that came from the AS, have we prevented the attac=
k?
=E1=90=A7 That=E2=80=99s good enough for the AS, but is it good eno=
ugh for the client? The hash allows the client to make sure that the refere=
nce they=E2=80=99re getting back in the front channel is related to somethi=
ng they sent out in the first place. We originally had a =E2=80=9Cstate=E2=
=80=9D parameter like OAuth 2 for this purpose, but realized that since the=
client can push its callback URI we didn=E2=80=99t need that. But to get t=
he kind of functionality that =E2=80=9Cnonce=E2=80=9D and =E2=80=9Cc_hash=
=E2=80=9D have in OIDC, we added this simple hash parameter that the client=
can check before it calls the TX endpoint again.
=C2=A0=
=E2=80=94 Justin
The Client presents the interact_ref to the AS with=
the transaction handle. The AS will be able to tell the Client if the inte=
ract_ref belongs to the transaction.
Why is that e=
nough?
<=
img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src=
=3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%=
3D&type=3Dzerocontent&guid=3De8149d62-27cd-484b-8310-c923c4e1e484">=
=E1=90=A7
The hash offers the same kinds of protections to th=
e client that the OIDC nonce does =E2=80=94 it binds the front channel retu=
rn to something you get from the back channel.=C2=A0
In =
other words, the client can be sure that the return value that it=E2=80=99s=
getting is related to the request it made in the first place, and not anot=
her one. Clients using per-request redirect URIs can also help with this, b=
ut this is something that the server can provide directly.
=
div>
=C2=A0=E2=80=94 Justin
While I can see the value of the interact_ref (aka inter=
action_ref) in the return URI that allows the Client to ensure the user tha=
t started the transaction is the same one that interacted at the AS, I don&=
#39;t understand why a hash is required. Would you elaborate?
=E1=90=A7
But =
that=E2=80=99s exactly the point =E2=80=94 it helps in that case, which is =
a very common case. For cases where the client doesn=E2=80=99t expect the u=
ser to come back on the same channel, then they don=E2=80=99t use the callb=
ack mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D URL that=
Annabelle mentioned in the other thread, or they might just print out =E2=
=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is common today.
XYZ=E2=80=99s interaction structure allows the compositio=
n of these things, under the control of the client. This is exactly why it=
=E2=80=99s important to be able to specify how to get to the AS and how to =
get back as separate items, so that the client can compose the combination =
that makes the most sense for that client.
=C2=A0=
=E2=80=94 Justin
I got ahead of myself. A completion URI protects the User on=
ly if the User is sent back to the same channel the transaction started so =
the Client can confirm it is the same User that started the transaction.
so this does not help the security:
"Being able to provide a completion URI even if the user is sta=
rting on a device is a great insight on how to address the threat above.&qu=
ot;
=E1=90=A7
=
The lightbulb fin=
ally clicked on for me. Thanks for your patience.
The th=
reat you are describing is where the attacker starts a transaction at the c=
lient, and gets the victim to complete it. Correct?
=
I still think the Client should be able to signal if it will be doing a red=
irect vs showing a QR code (or wants to do both).
=
Being able to provide a completion URI even if the user is starting on a de=
vice is a great insight on how to address the threat above.=C2=A0
<=
br>
I'm going to ponder how to align XAuth more with these fe=
atures of XYZ.
=E1=90=A7
On Feb 21, 2020, at 1:54 PM, Di=
ck Hardt <
dick=
.hardt@gmail.com> wrote:
=
=
I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized that both the QR Code =
and Authorization Code, and that the only difference is how the user gets b=
ack to the client. So instead of inventing a new type of interaction=
, we split them. In XYZ, we have:
This sentence looks to be miss=
ing something.
Apologies: We realized they both used AS-composed URLs to get the user t=
o the AS in a web browser for interaction purposes.=C2=A0
=C2=A0- redirect: tells the AS that the client can send the user to an a=
rbitrary URL (and the AS doesn=E2=80=99t care how the client gets that info=
to the user; could be a redirect or an image or send a push notification t=
o a secondary device, we don=E2=80=99t care as long as the user shows up in=
a browser at the AS =E2=80=94 so maybe this field can be renamed to be mor=
e universally accurate)
As stat=
ed in this thread, it may be useful for the AS to know if the URL will be i=
n a QR code, or in a full redirect.
In XAuth, the =
GS(AS min XYA) closes the popup to minimize what a Client has to do, so it =
needs to know the difference between a popup, and a full browser redirect. =
This is targetted at SPAs, where an additional URL to redirect to is extra =
work.
=C2=A0
=C2=A0- code: tells the AS that the client can present a short=
code the user can type (along with a static URL the user can get to, maybe=
by typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like th=
e redirect method)
=C2=A0- callback: tells the AS that the client c=
an receive the completion message from a front channel interaction through =
a redirect. Note that the client might have gotten to the AS through a redi=
rect on-device, through a QR-code off device, or through some other magic, =
and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s onl=
y concerned with how to get the user :back:.
=
In a full redirect, the Client wants the AS to send the=
user back so that it can continue.
The only param=
eter in the completion message is the nonce, which seems superfluous. See b=
elow.
=C2=A0
These three can be combined in different w=
ays depending on what you want to do at the client. Let=E2=80=99s say you=
=E2=80=99re doing and OAuth2 style authorization code, you=E2=80=99d use =
=E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D together. If you=
=E2=80=99re doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=
=9D. If you=E2=80=99re doing just a QR code with polling, you use just =E2=
=80=9Credirect=E2=80=9D to get the long URL. If you=E2=80=99re doing a user=
code and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=
=9Ccode=E2=80=9D to get the long URL and the short code not he screen at th=
e same time.=C2=A0
On top of that, they can be com=
bined with other methods. Maybe I can send the user to an arbitrary URL but=
also display a human-readable verification code (like CIBA), or send somet=
hing in a push notification but also give them a message to type, or I=E2=
=80=99m getting claims from an agent but I want them redirected back throug=
h the browser. The client gets to decide what kinds of interaction it can d=
o and how to use these pieces in ways that make the most sense.
=
Per my question later in this thread=
, why would the Client not know what interaction it wants prior to the requ=
est?
What do you me=
an? The client does know what it wants and that=E2=80=99s why it=E2=80=99s =
asking for what it wants. We=E2=80=99re debating different methods for the =
client to ask for what it wants. This question does not make sense to me.=
div>
If the AS is doing CIBA, that is not a decision=
just for the Client. Both the AS and the Client need to know they are doin=
g CIBA. (FWIW: I think this work supersedes CIBA)
=
blockquote>
As I=E2=80=99ve stated previously, I believe=
the interaction methods here can supersede CIBA.
<=
div>Additionally, different interactions have different risk profiles. Soph=
isticated ASes will use that signal in the risk assessment, and may do ask =
for additional authentication or verification.
=C2=A0
=
Yes, exactly my point. Because=
different interactions have different risks, the AS will need to be able t=
o decide which interactions it=E2=80=99s OK with for a given request. This =
could vary based on what=E2=80=99s being requested, or who=E2=80=99s doing =
the requesting.
=
An interesting difference between XYZ and XAu=
th=E2=80=99s approaches is that XYZ keeps the concept of the =E2=80=9Cautho=
rization code=E2=80=9D in the callback response (which in turn is based on =
the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an =E2=
=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of nonces =
generated by the client and the AS in the back channel. This binds the fron=
t channel response to both the back channel request and the back channel re=
sponse for a given transaction =E2=80=94 and note that I=E2=80=99m really o=
pen to having a better way to generate and calculate such a binding, but I =
think this works. In any event, this protects the client from session fixat=
ion and injection on the return from the front channel that it=E2=80=99s su=
sceptible to in a pure polling model, and the hashing approach basically co=
mbines the security parameters of the OAuth 2 authorization code and (to an=
extent) state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in =
one element. This is only applicable if you=E2=80=99re coming back to the c=
lient and you can validate the hash and present the reference parameter. If=
you=E2=80=99re doing just plain polling, you don=E2=80=99t have that prote=
ction =E2=80=94 but the client and the AS are aware of that risk, and there=
=E2=80=99s an option to prevent it.
XAuth has remo=
ved the authorization code concept in its redirect return, and clients only=
do polling against the GS API in order to get tokens. While I obviously th=
ink it=E2=80=99s very valuable to remove things from the front channel, I d=
on=E2=80=99t think this is something we can remove without opening up attac=
k surfaces that have already been identified in previous protocols. I would=
like to understand why XAuth is not susceptible to the same kinds of attac=
ks, or if it is, what mitigations there are for them.=C2=A0
Unlike OAuth 2.0, there are no parameter=
s in the front channel response to the Client. The redirect back to the Cli=
ent is only needed to return the interaction back to the Client.
This argument rings tautologi=
cally hollow =E2=80=94 there are no parameters because you=E2=80=99ve defin=
ed that there aren=E2=80=99t any in XAuth. XYZ does have parameters, to tie=
the front and back channel requests together when doing redirect back and =
forth.
If you=E2=80=99re not doing a redirect back=
(ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), then it=
=E2=80=99s a polling mechanism like XAuth, the device flow, etc. There are =
very real risks to this.
XAuth (and XYZ) hav=
e a different flow than OAuth 2.0 (or OAuth 1.0)
I=
n OAuth, the AS gives a code to the User to give to the Client that the Cli=
ent then gives to the GS.
In XAuth, the AS gives a=
"code" to the Client that givers it to the User to give to the G=
S.
In XAuth, the "code" is either a user=
code, or something embedded in the URI the User is redirected to.
Therefore, there is nothing to protect in the redirect bac=
k to the Client.
If I'm missing an attack, ple=
ase elaborate how it would happen.
OAuth 1.0=
=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request initiation =
step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s su=
sceptible to the same kind of issue.
=C2=A0
=C2=A0=
=E2=80=94 Justin
Thank=
s for the update, Dick! I=E2=80=99m going to confine my comments here to in=
teraction mode design, setting aside whether or not we need =E2=80=9Cpopup=
=E2=80=9D. :D
=C2=A0
Once the GS hands that URI back to the Client, it has zero control over=
how the Client uses it. The Client could present any URI (of a reasonable =
size) into a QR code, or present it as a clickable link, or redirect to it,=
or open it in an external browser, or do any number of other as-yet-not-in=
vented things with it. Moreover, the Client may not know yet what it wants =
to do with it. So what value is there in distinguishing between =E2=80=9CI =
want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=
=E2=80=9D vs. =E2=80=9CI want a URI for <some other machine-driven inter=
action mode>=E2=80=9D?
=C2=A0=
Even if we consider things like QR code data capacity, that=
=E2=80=99s really just a URI length limitation, which could apply to non-QR=
interaction modes, e.g., if the Client device wants to communicate the URI=
over an extremely bandwidth-constrained channel. And it=E2=80=99s not clea=
r to me how including a URI length limitation in the request helps. If a GS=
is capable of generating a shorter URI, why wouldn=E2=80=99t it always ret=
urn that? On the client side, it can look at the length of the URI provided=
and decide what to do with it (e.g., render a QR code or display it or do =
nothing with it).
=C2=A0
So that really leaves us with two interaction modes that we need:- =E2=80=9Curi=E2=80=9D, which returns a full URI that may not b=
e human friendly; and
- =E2=80=9Ccode=E2=80=9D, wh=
ich returns a code and URI for a code entry page, both of which are human-f=
riendly.
=C2=A0
Those could be combinable to get both, and even if we don=E2=80=99t go d=
own the multiple interaction mode route we could add the full URI to the =
=E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt anythin=
g to do so.
=C2=A0
=E2=80=93
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">
Annabelle Backman (she/her)<=
u>AWS Identity=
=
=C2=A0
=C2=A0
Added in user code interaction and aligned QR c=
ode to be a superset of user code.
=C2=A0
A new version o=
f I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted=
by Dick Hardt and posted to the
IETF repository.
Name:=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2=
=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The =
XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=
=A0https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.=
txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/dr=
aft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.or=
g/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =
=C2=A0ht=
tps://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft=
-hardt-xauth-protocol-03
Abstract:
=C2=A0 =C2=A0Client softwa=
re often desires resources or identity claims that are
=C2=A0 =C2=A0inde=
pendent of the client.=C2=A0 This protocol allows a user and/or
=C2=A0 =
=C2=A0resource owner to delegate resource authorization and/or release of=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then =
request access
=C2=A0 =C2=A0to resources and/or identity claims by calli=
ng the server.=C2=A0 The
=C2=A0 =C2=A0server acquires consent and author=
ization from the user and/or
=C2=A0 =C2=A0resource owner if required, an=
d then returns to the client software
=C2=A0 =C2=A0the authorization and=
identity claims that were approved.=C2=A0 This
=C2=A0 =C2=A0protocol ca=
n be extended to support alternative authorizations,
=C2=A0 =C2=A0claims=
, interactions, and client authentication mechanisms.
Pl=
ease note that it may take a couple of minutes from the time of submission<=
br>until the htmlized version and diff are available at=C2=A0<=
a href=3D"http://tools.ietf.org/" style=3D"color:blue;text-decoration:under=
line" target=3D"_blank">tools.ietf.org.
The IETF Secretariat<=
/u>
=E1=90=A7 --=C2=A0Txauth mailing listTxauth@ietf.orghttps://www.ietf.org/mailman/=
listinfo/txauth
=
blockquote>
--000000000000805e2305a038cb82--
From nobody Sat Mar 7 09:47:55 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E23A16FD for ; Sat, 7 Mar 2020 09:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
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 LfA8oBrOoJrQ for ; Sat, 7 Mar 2020 09:47:46 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A243A16F8 for ; Sat, 7 Mar 2020 09:47:45 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id s24so5241633iog.5 for ; Sat, 07 Mar 2020 09:47:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3iF6G2JPLYJBp0LYikEKozbGaXubux8Z5spZ3FK5Bfo=; b=ahrDUucxuub3poL7cqMjQDKyDuOmH2TlnueXP6foYtXsB3PAgyaKF6lCUsNnm5gJgp TlIwaI0gRtKgendaYyCi7dqHw33G/hryD/N1HYcenHz5MkE7ZdoomTziWzVpLWM4QavJ IoNJSGgx5da+2Hw1WPQ+wp/0mmyeWMChTZO689gbK2mwEp8fnXorTFT21ViUCgbbvdnV SA9RV9WUfgkX1nJhzHSipokDVcZFvPqTzVsg9AQDCKj49YB8CUbyoX3EA4Rftc1eARHy GTu+ubBqJyqEGY4EqKI33dOmNf93woKIIM9+FZLLNfIWU9ZHx7uF8bJN1McahpBdb259 Q4cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3iF6G2JPLYJBp0LYikEKozbGaXubux8Z5spZ3FK5Bfo=; b=NSqfv8Bjz0B8L8T1KP/Ns9qI9S7jgiAUdJrokWm5U/nKg/pwLrPVhm0TwdoLXNbZJo Z21Y189Mv6MnFz9YGJeyaPuywbHT0a/5EmWbpm+2WiwQDGDRNr0+lckbS93mqMYw+dJy wjwQLyJH+KXuuT1+KRTvNKetDRbFuzUQ+ChJISGQ4aYx/TjyzM8RRXiCdWsRILOoqIye dCfjszbtGiNDtZflkipsZySHKgt0o1BJz382OwY6nTK2l8MHoXH7i4kroHIcV9IUCqoB WEl2CHdIEgqsBu7y5xd6+9rC0hzkdjJRU+z0+q0g8QxVftn9HmTYiENk/SitX8BLtMBW K/yg==
X-Gm-Message-State: ANhLgQ1eL5y/WuHQShnWrnZqX/SMhap0WlUtLM8R2bG/jcSzO8FvJ1vQ zsyizX307H2qEfeH9IjTfjLaM/LRtBM=
X-Google-Smtp-Source: ADFU+vuJQZQhDIqC8AMpWPsWAQ/psPE0fX8xML6dIkddTZ67wIs49a7igkFcIIoWriMHJlLI/+6hYQ==
X-Received: by 2002:a05:6602:20cf:: with SMTP id 15mr7463605ioz.24.1583603263419; Sat, 07 Mar 2020 09:47:43 -0800 (PST)
Received: from mail-il1-f169.google.com (mail-il1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id c12sm12777525ile.12.2020.03.07.09.47.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2020 09:47:42 -0800 (PST)
Received: by mail-il1-f169.google.com with SMTP id j69so4996308ila.11 for ; Sat, 07 Mar 2020 09:47:42 -0800 (PST)
X-Received: by 2002:a92:5f45:: with SMTP id t66mr8619080ilb.28.1583603262418; Sat, 07 Mar 2020 09:47:42 -0800 (PST)
MIME-Version: 1.0
References:
In-Reply-To:
From: Aaron Parecki
Date: Sat, 7 Mar 2020 09:47:29 -0800
X-Gmail-Original-Message-ID:
Message-ID:
To: Yaron Sheffer
Cc: "txauth@ietf.org"
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 17:47:55 -0000
> 1. Do you support the charter text provided at the end of this email? O=
r do you have major objections, blocking concerns or feedback (if so please=
elaborate)?
Yes
> 2. Are you willing to author or participate in the development of the dr=
afts of this WG?
Yes
> 3. Are you willing to help review the drafts of this WG?
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes
----
Aaron Parecki
aaronparecki.com
@aaronpk
On Fri, Mar 6, 2020 at 8:45 AM Yaron Sheffer wrote:
>
> Hi Everyone,
>
> It appears that momentum is forming around the proposed formation of a Tx=
Auth working group. We=E2=80=99d like to more formally gauge interest in p=
roceeding with this work. Please do so by responding to the following ques=
tions:
>
> 1. Do you support the charter text provided at the end of this email? O=
r do you have major objections, blocking concerns or feedback (if so please=
elaborate)?
>
> 2. Are you willing to author or participate in the development of the dr=
afts of this WG?
>
> 3. Are you willing to help review the drafts of this WG?
>
> 4. Are you interested in implementing drafts of this WG?
>
> The call will run for two weeks, until March 21. If you think that the ch=
arter should be amended In a significant way, please reply on a separate th=
read.
>
> The feedback provided here will help the IESG come to a decision on the f=
ormation of a new WG. Given the constraints of the chartering process, rega=
rdless of the outcome of this consensus call, we will be meeting in Vancouv=
er as a BoF.
>
> Thanks,
> Yaron and Dick
>
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol for=
authorization, identity, and API access. This protocol will allow an autho=
rizing party to delegate access to client software through an authorization=
server. It will expand upon the uses cases currently supported by OAuth 2.=
0 and OpenID Connect (itself an extension of OAuth 2.0) to support authoriz=
ations scoped as narrowly as a single transaction, provide a clear framewor=
k for interaction among all parties involved in the protocol flow, and remo=
ve unnecessary dependence on a browser or user-agent for coordinating inter=
actions.
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol, each performing a specific role. The protocol will decouple the inter=
action channels, such as the end user=E2=80=99s browser, from the delegatio=
n channel, which happens directly between the client and the authorization =
server (in contrast with OAuth 2.0 which is initiated by the client redirec=
ting the user=E2=80=99s browser). The client and AS will involve a user to =
make an authorization decision as necessary through interaction mechanisms =
indicated by the protocol. This decoupling avoids many of the security conc=
erns and technical challenges of OAuth 2.0 and provides a non-invasive path=
for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interacti=
on
> - Separation between the party authorizing access and the party operating=
the client requesting access
> - A variety of client applications, including Web, mobile, single-page, a=
nd interaction-constrained applications
>
> The group will define extension points for this protocol to allow for fle=
xibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of posses=
sion
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces=
of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resour=
ce requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation pr=
ocess (including identity)
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to be b=
ackwards-compatible with OAuth 2.0 or OpenID Connect, the group will attemp=
t to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc=
ol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch will focus on new technological solutions not necessarily compatible wit=
h OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develo=
ped in the OAuth Working Group, including functionality back-ported from th=
e protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic m=
ethods, such as JOSE and COSE, to the delegation process. This group is not=
chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between the c=
lient and the authorization server, taking advantage of optimization featur=
es of HTTP2 and HTTP3 where possible, and will strive to enable simple mapp=
ing to other protocols such as COAP when doing so does not conflict with th=
e primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, deta=
ched HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
From nobody Sat Mar 7 12:27:35 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432E3A19D8 for ; Sat, 7 Mar 2020 12:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=spotify.com
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 acfC1QXTnwir for ; Sat, 7 Mar 2020 12:27:32 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A333A19D5 for ; Sat, 7 Mar 2020 12:27:31 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id n8so1982665wmc.4 for ; Sat, 07 Mar 2020 12:27:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SjD4O4TONr9vWk+o+b89F/aPmPNFiPDcvyC8UGzzkKc=; b=XrIY1ZpFImjg5VGtraCvn9gke1jAy2ca6GsG6PQBVF0ulK1D6vSYZqpBNRffqn2j9o x+/kyQC+6s5D4ymD3sVVg/f9XufEuaWBmL3AKMGBiLsPOBCP9lmxMmMyF0qcjf9ItkD8 D6QYUEo6xhTNuemFwMHCpTc5yxUoWfyAEHV8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SjD4O4TONr9vWk+o+b89F/aPmPNFiPDcvyC8UGzzkKc=; b=aFTyt/QvywOKF7VcqtYq8y1q2jXBbivGaR1vuab8w3cmeMaLvLAgWvV+u5vNt9+ta4 g5keEW5a5ChqFFFlw94iv9uRdVsEEzV7wFt38W4p7rYovjeJPi9Xat89JEG8lkqRb0Qu ZNrWP0Kh2NRitVhCCioStwgGbjbOgiG8y4eApbB/P9tpE8skcNn0QKjCvUW1C96tT9dc BftB6A4F3zj/m1hPBBmOwEjhi+Zv5iFn33AWFlL505vrPRpESf8bnAZl5TcjwltPeZFG V+Dzze+Kj+eDTOh0AwcQeoUNa5D1pR7D/+P8iAvxjSf4SM6JJ+45nS5Ml0HsD3l3pij5 Voug==
X-Gm-Message-State: ANhLgQ2pi4vI+VF9pCzwd1O4F4ogrMPcVmW1OE+Fn87iOlTADUK24QYs Bqe31BbA3o8nc8khDxIaU0I2yxzjSTn8SE+8EIM6Jw==
X-Google-Smtp-Source: ADFU+vs120v1UpcDgImK03Obb/+XN34MakOheCR81om/Y4cikROpaQHpEZDKwLRF58a79NqbtK2xOkM8L2NZ2TO6pec=
X-Received: by 2002:a1c:b743:: with SMTP id h64mr11014596wmf.88.1583612849680; Sat, 07 Mar 2020 12:27:29 -0800 (PST)
MIME-Version: 1.0
References:
In-Reply-To:
From: Aleksei Petrov
Date: Sat, 7 Mar 2020 21:27:17 +0100
Message-ID:
To: Yaron Sheffer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005e09cd05a04999ba"
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 20:27:34 -0000
--0000000000005e09cd05a04999ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
> 1. Do you support the charter text provided at the end of this email? O=
r
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
Yes
> 2. Are you willing to author or participate in the development of the
> drafts of this WG?
Yes
> 3. Are you willing to help review the drafts of this WG?
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes
----
Aleksei Petrov | Senior Software Engineer | User Platform
Spotify AB
Regeringsgatan 19
111 53 Stockholm
On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer wrote:
> Hi Everyone,
>
> It appears that momentum is forming around the proposed formation of a
> TxAuth working group. We=E2=80=99d like to more formally gauge interest =
in
> proceeding with this work. Please do so by responding to the following
> questions:
>
> 1. Do you support the charter text provided at the end of this email? O=
r
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
>
> 2. Are you willing to author or participate in the development of the
> drafts of this WG?
>
> 3. Are you willing to help review the drafts of this WG?
>
> 4. Are you interested in implementing drafts of this WG?
>
> The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separat=
e
> thread.
>
> The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
>
> Thanks,
> Yaron and Dick
>
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. It will expand upon the uses cases currently
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
> 2.0) to support authorizations scoped as narrowly as a single transaction=
,
> provide a clear framework for interaction among all parties involved in t=
he
> protocol flow, and remove unnecessary dependence on a browser or user-age=
nt
> for coordinating interactions.
>
> The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user=E2=80=99s browser, from the de=
legation
> channel, which happens directly between the client and the authorization
> server (in contrast with OAuth 2.0 which is initiated by the client
> redirecting the user=E2=80=99s browser). The client and AS will involve a=
user to
> make an authorization decision as necessary through interaction mechanism=
s
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasiv=
e
> path for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interacti=
on
> - Separation between the party authorizing access and the party operating
> the client requesting access
> - A variety of client applications, including Web, mobile, single-page,
> and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of
> possession
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces
> of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation
> process (including identity)
>
> Additionally, the group will provide mechanisms for management of the
> protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne=
w
> protocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back-ported
> from the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
--0000000000005e09cd05a04999ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
1.=C2=A0=
Do you support the charter text provided at the end of this email?=C2=A0 O=
r do you have major objections, blocking concerns or feedback (if so please=
elaborate)?
Yes=C2=A0
=C2=A0
2.=C2=A0 Are you willing to au=
thor or participate in the development of the drafts of this WG?
Yes=C2=A0
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of=
this WG?
=C2=A0
Yes=C2=A0
=C2=A0
4.=C2=A0 Are you interested in =
implementing drafts of this WG?=C2=A0
Yes=C2=A0=
----
Alekse=
i Petrov=C2=A0| Senior Software Engineer=C2=A0| User Platform
Spotify AB
Regeringsgatan 19
111 53 Stockholm
<=
/div>
Hi Everyone,=
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu=
th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i=
n proceeding with this work.=C2=A0 Please do so by responding to the follow=
ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?=
=C2=A0 Or do you have major objections, blocking concerns or feedback (if s=
o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the=
drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char=
ter should be amended In a significant way, please reply on a separate thre=
ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for=
mation of a new WG. Given the constraints of the chartering process, regard=
less of the outcome of this consensus call, we will be meeting in Vancouver=
as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---
This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authori=
zing party to delegate access to client software through an authorization s=
erver. It will expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat=
ions scoped as narrowly as a single transaction, provide a clear framework =
for interaction among all parties involved in the protocol flow, and remove=
unnecessary dependence on a browser or user-agent for coordinating interac=
tions.
The delegation process will be acted upon by multiple parties in the protoc=
ol, each performing a specific role. The protocol will decouple the interac=
tion channels, such as the end user=E2=80=99s browser, from the delegation =
channel, which happens directly between the client and the authorization se=
rver (in contrast with OAuth 2.0 which is initiated by the client redirecti=
ng the user=E2=80=99s browser). The client and AS will involve a user to ma=
ke an authorization decision as necessary through interaction mechanisms in=
dicated by the protocol. This decoupling avoids many of the security concer=
ns and technical challenges of OAuth 2.0 and provides a non-invasive path f=
or supporting future types of clients and interaction channels.
Additionally, the delegation process will allow for:
- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t=
he client requesting access
- A variety of client applications, including Web, mobile, single-page, and=
interaction-constrained applications
The group will define extension points for this protocol to allow for flexi=
bility in areas including:
- Cryptographic agility for keys, message signatures, and proof of possessi=
on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource=
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc=
ess (including identity)
Additionally, the group will provide mechanisms for management of the proto=
col lifecycle including:
- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers
Although the artifacts for this work are not intended or expected to be bac=
kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt =
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol=
where possible.
This group is not chartered to develop extensions to OAuth 2.0, and as such=
will focus on new technological solutions not necessarily compatible with =
OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope=
d in the OAuth Working Group, including functionality back-ported from the =
protocol developed here to OAuth 2.0.
The group is chartered to develop mechanisms for applying cryptographic met=
hods, such as JOSE and COSE, to the delegation process. This group is not c=
hartered to develop new cryptographic methods.
The initial work will focus on using HTTP for communication between the cli=
ent and the authorization server, taking advantage of optimization features=
of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin=
g to other protocols such as COAP when doing so does not conflict with the =
primary focus.
Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d=
etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--0000000000005e09cd05a04999ba--
From nobody Sat Mar 7 16:19:45 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4183A1428 for ; Sat, 7 Mar 2020 06:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 oUSvcJ2A2nBo for ; Sat, 7 Mar 2020 06:30:35 -0800 (PST)
Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 2CDBF3A1427 for ; Sat, 7 Mar 2020 06:30:35 -0800 (PST)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id AaTJjiWlMJHZdAaTKj33MQ; Sat, 07 Mar 2020 07:30:34 -0700
X-CMAE-Analysis: v=2.3 cv=KYasTjQD c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=Zp0L8TXmEty27ntzuMYA:9 a=QEXdDO2ut3YA:10 a=mh4ueyR6XC0F2eu3eXgA:9 a=yNwISwW-LHsqJXiW:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: txauth@ietf.org
From: Vladimir Dzhuvinov
Organization: Connect2id Ltd.
Message-ID: <6ec848be-8912-be33-9de2-542aed917107@connect2id.com>
Date: Sat, 7 Mar 2020 16:30:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060202000608040802080802"
X-CMAE-Envelope: MS4wfICvGHiEZfmEDi8SkOWV3jq03r6N7GkNOMjiFiEmlBz6fGH15yeotfUBrWc8C6eLMkUyEJN/aWqqimsC60kRQMKj8ldD8Jbx9JpO3ZV2B9fWcFpl+y/t 070hThABgzhRWfu9azIKcEhcjWNLA81dNDc9h7JGN0dpAQULM4my6IWi
Archived-At:
Subject: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 14:30:36 -0000
X-List-Received-Date: Sat, 07 Mar 2020 14:30:36 -0000
This is a cryptographically signed message in MIME format.
--------------ms060202000608040802080802
Content-Type: multipart/alternative;
boundary="------------CBB21F010F1A6A98E0A4BC36"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------CBB21F010F1A6A98E0A4BC36
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
This is the future, so
> 1.=C2=A0 Do you support the charter text provided at the end of this em=
ail?=C2=A0 Or do you have major objections, blocking concerns or feedback=
(if so please elaborate)?
Yes
> 2.=C2=A0 Are you willing to author or participate in the development of=
the drafts of this WG?
Not sure I can be of much help here
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
Yes
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
Yes
Vladimir
--=20
Vladimir Dzhuvinov
--------------CBB21F010F1A6A98E0A4BC36
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
This is the future, so
1.=C2=A0 Do you support the charter text =
provided at the end of this email?=C2=A0 Or do you have major objections,=
blocking concerns or feedback (if so please elaborate)?
Yes
2.=C2=A0 Are you willing to author or par=
ticipate in the development of the drafts of this WG?
Not sure I can be of much help here
3.=C2=A0 Are you willing to help review t=
he drafts of this WG?
Yes
4.=C2=A0 Are you interested in implementi=
ng drafts of this WG?
Yes
Vladimir
--=20
Vladimir Dzhuvinov
--------------CBB21F010F1A6A98E0A4BC36--
--------------ms060202000608040802080802
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMDcxNDMwMzNaMC8G
CSqGSIb3DQEJBDEiBCAGufSgATR474mR2IAbi1ILQ0CKHyfodQDcf3bE6nfFsDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBABU235effQiQ7uPANabqzIPWnNmu/y89I00uelXrDnzkJ185
rOXuYTqF+f9XvIDQKIqzAnDi7MaPhHWeOG3z8WRh9C7v0F/00eKG+UM2B3HIm6xlBsxfPhTT
0VvGPw2J34/GgaqJXV5ERxhDO63iNICDHalvTF1XkT4V6oyuVc193fN0fogIw5I1/SkPzSzA
A+onwKc/vNAVeO5tIAEoxDDK+zcsByUgdOFISacKqrAU+7t10bOD1qU0pdXezNoUGuUJ3NEl
Gupa6/6JZijZyy0fKbq7RPJmc/MCU751S++fGgp2FAiuvq+c68Pg2HS0Ckv60qTy7p3j/yjA
MQUrhYcAAAAAAAA=
--------------ms060202000608040802080802--
From nobody Sat Mar 7 16:20:22 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6A3A149E for ; Sat, 7 Mar 2020 07:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amanjeev.com header.b=KM64DFlF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2ngBgfVc
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 XtSARiubgqro for ; Sat, 7 Mar 2020 07:06:52 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908773A14A2 for ; Sat, 7 Mar 2020 07:06:52 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B100F21FE9 for ; Sat, 7 Mar 2020 10:06:51 -0500 (EST)
Received: from imap8 ([10.202.2.58]) by compute2.internal (MEProxy); Sat, 07 Mar 2020 10:06:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amanjeev.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=JUW1t kDj70928+UeKvtx4Ix7lxX4ZaJ4qUh7RIP5GBQ=; b=KM64DFlFESl6mT5U5Bx3G yV8tnsv3xVLOfrAmaiCp3EFu1fnSnOJz29VV1VxItvzu0IudmJ4q2E7ir9uJy7/v 04PPohw2J7odg8NbXWrAiGeoP8M+j6VIxTw7spwlqcxvvQZamIE2Y32K4GHw2LeT 5O9aL5AUOZ6dEg55Mb6D7Ps42sDfEmYdTNbJ9D2hUpIhvpPZl7as9kT8NPBeZ34B M5g1hEQW21Q4GRJZRKvFm89NBLTBgndeYtRrgOOWsgoHbLQbOKCy6ZKJQV4D2jXP Tlg/khNjRhCVXIDUR1SMoMYE6aQqux6rPykrvuP4essqBsaAFjufsHV63p7CUTI0 A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JUW1tkDj70928+UeKvtx4Ix7lxX4ZaJ4qUh7RIP5G BQ=; b=2ngBgfVcUdpTHU5qc0BvBioi1Tz8gzfd/UqA++f395VlHC75NBnMxtx6f EBTl3bJdQfc+k+/7pJ69XYRcFywoe4KPI0Ip05gJvk4JxBT17Pq04qdCoXDRlEki lpLgGRXUuxmaglFK7dYdMzFEUx9V9SK80rystapc2HoMdujQlz5QFzn5XmrZGuMa i+f8MSPCtKyLTn4VCYYEWMFKeWh0JrdIiyhbir2LXJCXBX4xmOSz7mp/I+CKuFJa /j7Fh/uG1Lcm6IL5x2fEAfuGyjTymB5k5UWn6z/38UB1ZX7iCXT21nIODIPOq6Sb iba3QbCqeylBvQXv5dWTuO1IFU55g==
X-ME-Sender:
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddugedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdetmhgrnhhjvggvvhcuufgvthhhihdfuceorghjsegr mhgrnhhjvggvvhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrjhesrghmrghnjhgv vghvrdgtohhm
X-ME-Proxy:
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01F92520093; Sat, 7 Mar 2020 10:06:51 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3
Mime-Version: 1.0
Message-Id: <7cd5726f-cda5-4a2c-adc7-d854e0e81a34@www.fastmail.com>
In-Reply-To:
References:
Date: Sat, 07 Mar 2020 10:06:29 -0500
From: "Amanjeev Sethi"
To: txauth@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 15:06:55 -0000
X-List-Received-Date: Sat, 07 Mar 2020 15:06:55 -0000
Hello Everyone,
I am relatively new here and in fact only been reading OIDC spec for pas=
t 6-8 months. I am still trying to grasp the TxAuth by watching Justin's=
talks and posts. I am here to mostly see and hopefully participate in s=
ome corners of this spec.=20
> 1. Do you support the charter text provided at the end of this email?=
=20
> Or do you have major objections, blocking concerns or feedback (if so=20=
> please elaborate)?
Yes.
> 2. Are you willing to author or participate in the development of the=
=20
> drafts of this WG?
Yes
> 3. Are you willing to help review the drafts of this WG?
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes
On Fri, Mar 6, 2020, at 11:44 AM, Yaron Sheffer wrote:
> Hi Everyone,
> =C2=A0
> It appears that momentum is forming around the proposed formation of a=
=20
> TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i=
nterest in=20
> proceeding with this work.=C2=A0 Please do so by responding to the fol=
lowing=20
> questions:
> =C2=A0
> 1.=C2=A0 Do you support the charter text provided at the end of this e=
mail?=C2=A0=20
> Or do you have major objections, blocking concerns or feedback (if so=20=
> please elaborate)?
> =C2=A0
> 2.=C2=A0 Are you willing to author or participate in the development o=
f the=20
> drafts of this WG?
> =C2=A0
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
> =C2=A0
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
> =C2=A0
> The call will run for two weeks, until March 21. If you think that the=
=20
> charter should be amended In a significant way, please reply on a=20
> separate thread.
> =C2=A0
> The feedback provided here will help the IESG come to a decision on th=
e=20
> formation of a new WG. Given the constraints of the chartering process=
,=20
> regardless of the outcome of this consensus call, we will be meeting i=
n=20
> Vancouver as a BoF.
> =C2=A0
> Thanks,
> Yaron and Dick
> =C2=A0
> --- Charter Text Follows ---
>=20
> This group is chartered to develop a fine-grained delegation protocol=20=
> for authorization, identity, and API access. This protocol will allow=20=
> an authorizing party to delegate access to client software through an=20=
> authorization server. It will expand upon the uses cases currently=20
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAut=
h=20
> 2.0) to support authorizations scoped as narrowly as a single=20
> transaction, provide a clear framework for interaction among all=20
> parties involved in the protocol flow, and remove unnecessary=20
> dependence on a browser or user-agent for coordinating interactions.=20=
>=20
> The delegation process will be acted upon by multiple parties in the=20=
> protocol, each performing a specific role. The protocol will decouple=20=
> the interaction channels, such as the end user=E2=80=99s browser, from=
the=20
> delegation channel, which happens directly between the client and the=20=
> authorization server (in contrast with OAuth 2.0 which is initiated by=
=20
> the client redirecting the user=E2=80=99s browser). The client and AS =
will=20
> involve a user to make an authorization decision as necessary through=20=
> interaction mechanisms indicated by the protocol. This decoupling=20
> avoids many of the security concerns and technical challenges of OAuth=
=20
> 2.0 and provides a non-invasive path for supporting future types of=20=
> clients and interaction channels.
>=20
> Additionally, the delegation process will allow for:
>=20
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single=20
> interaction
> - Separation between the party authorizing access and the party=20
> operating the client requesting access
> - A variety of client applications, including Web, mobile, single-page=
,=20
> and interaction-constrained applications
>=20
> The group will define extension points for this protocol to allow for=20=
> flexibility in areas including:
>=20
> - Cryptographic agility for keys, message signatures, and proof of=20
> possession=20
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other=20
> pieces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding=20
> resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation=
=20
> process (including identity)
>=20
> Additionally, the group will provide mechanisms for management of the=20=
> protocol lifecycle including:
>=20
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>=20
> Although the artifacts for this work are not intended or expected to b=
e=20
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will=20=
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the=
=20
> new protocol where possible.
>=20
> This group is not chartered to develop extensions to OAuth 2.0, and as=
=20
> such will focus on new technological solutions not necessarily=20
> compatible with OAuth 2.0. Functionality that builds directly on OAuth=
=20
> 2.0 will be developed in the OAuth Working Group, including=20
> functionality back-ported from the protocol developed here to OAuth 2.=
0.
>=20
> The group is chartered to develop mechanisms for applying cryptographi=
c=20
> methods, such as JOSE and COSE, to the delegation process. This group=20=
> is not chartered to develop new cryptographic methods.=20
>=20
> The initial work will focus on using HTTP for communication between th=
e=20
> client and the authorization server, taking advantage of optimization=20=
> features of HTTP2 and HTTP3 where possible, and will strive to enable=20=
> simple mapping to other protocols such as COAP when doing so does not=20=
> conflict with the primary focus.
>=20
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS,=20=
> detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
From nobody Sat Mar 7 16:20:35 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0F3A14BE for ; Sat, 7 Mar 2020 07:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 bngk4J-qi8tz for ; Sat, 7 Mar 2020 07:17:52 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C3D3A14C0 for ; Sat, 7 Mar 2020 07:17:52 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id r7so5803006wro.2 for ; Sat, 07 Mar 2020 07:17:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=waF5+PoyVQ3c64NbJEXyoLPPjx38DGv2WNrVEtkhaXk=; b=oLyEC30NoH+VAVs3ZBHGnP6GpCzMGRiEGuRgA21lvIjnBwMlavhdF67o7pPX/MIwrs c+0ikmPYix4rZgAm2R3WstgLOH01U6QAE5x5Cjtx5m7BVVL2x7A1rL8OmPgtKpTpx20U FMXcVKcdkbF6y7TV2TKF/P7E/Q23PGjkxh57GISq0WZ3uc4m+8HhNQzO+Owygt98nP+U bhifiGEObtzkorWToou7XIJwo0FEgzy/SckiVZ6GAfenOClsKGUhxvmojks/mz776+5/ IdR0r/t2xM3jDAd6Fyx43zeeYhZJX+Gp3CLfrfFgcp3LJ5klmZa944c+60EwOJl23pdY K/+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=waF5+PoyVQ3c64NbJEXyoLPPjx38DGv2WNrVEtkhaXk=; b=HkEgk95gVBOcadU8/0Zmmk8RBcraPuApidsbyWGJkArPZ6okMiBIDyOcrzboHoDIuj y7sBxN1o8qJQKx67iQjRjNRKnAnkRqCFSwIMxtrYlSDcDO5KqkNV0IIgFAME4LDOQxXN zuxSgtT+UW7A9CyopmbmC2BZy5gFm08DviYZLdTJyVUCVV+DYf0B643pL1zpB+Kr7crO qWWUf4DyxFbsyLQZT1KQ/oZVH5mOzbq2qhVrIc7PniArUn739yJO8YHzPAElSTDpvHTN wt5/2gEg0OQzfqy7UbwH8Rwg59Wdr3SAl92vHiVxzEwHWpH0h+hsJ3YRhtSpsnu0C3qm qTgw==
X-Gm-Message-State: ANhLgQ1/GFajeWsAmDWRFmQX8BKkf+y2qEagX64f1qXZheAYfR+xo7sg nOHu8DhJ6rbHwQ8w0mz+nOWIq+JQeQQ=
X-Google-Smtp-Source: ADFU+vsZJ8pzGUN3iyr/mHbBDNb9eR/0O36/AnaD1cfnL7+loHVCMgdDgwTNGt+lFlCXoUnCpXaqXA==
X-Received: by 2002:adf:ee02:: with SMTP id y2mr9631555wrn.23.1583594270032; Sat, 07 Mar 2020 07:17:50 -0800 (PST)
Received: from ?IPv6:2a01:598:a090:1028:9069:f1b5:ad4a:b3a? ([2a01:598:a090:1028:9069:f1b5:ad4a:b3a]) by smtp.gmail.com with ESMTPSA id v16sm36237296wrp.84.2020.03.07.07.17.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2020 07:17:48 -0800 (PST)
Content-Type: multipart/signed; boundary=Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt
Mime-Version: 1.0 (1.0)
Date: Sat, 7 Mar 2020 16:17:47 +0100
Message-Id: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net>
References:
Cc: "txauth@ietf.org"
In-Reply-To:
To: Yaron Sheffer
X-Mailer: iPhone Mail (17D50)
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 15:17:54 -0000
X-List-Received-Date: Sat, 07 Mar 2020 15:17:54 -0000
--Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer :
>=20
> =EF=BB=BFHi Everyone,
> =20
> It appears that momentum is forming around the proposed formation of a TxA=
uth working group. We=E2=80=99d like to more formally gauge interest in pro=
ceeding with this work. Please do so by responding to the following questio=
ns:
> =20
> 1. Do you support the charter text provided at the end of this email? Or=
do you have major objections, blocking concerns or feedback (if so please e=
laborate)?
I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned the s=
cope of the charter is too broad, e.g. identify alone is a huge topic.
We need to keep an eye on this aspect in order to make sure, the group is ab=
le to work effectively and the specs we will be producing are as simple as p=
ossible and foster interoperability.
> =20
> 2. Are you willing to author or participate in the development of the dra=
fts of this WG?
yes
> =20
> 3. Are you willing to help review the drafts of this WG?
yes
> =20
> 4. Are you interested in implementing drafts of this WG?
yes
best regards,
Torsten.
> =20
> The call will run for two weeks, until March 21. If you think that the cha=
rter should be amended In a significant way, please reply on a separate thre=
ad.
> =20
> The feedback provided here will help the IESG come to a decision on the fo=
rmation of a new WG. Given the constraints of the chartering process, regard=
less of the outcome of this consensus call, we will be meeting in Vancouver a=
s a BoF.
> =20
> Thanks,
> Yaron and Dick
> =20
> --- Charter Text Follows ---
>=20
> This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authoriz=
ing party to delegate access to client software through an authorization ser=
ver. It will expand upon the uses cases currently supported by OAuth 2.0 and=
OpenID Connect (itself an extension of OAuth 2.0) to support authorizations=
scoped as narrowly as a single transaction, provide a clear framework for i=
nteraction among all parties involved in the protocol flow, and remove unnec=
essary dependence on a browser or user-agent for coordinating interactions.=20=
>=20
> The delegation process will be acted upon by multiple parties in the proto=
col, each performing a specific role. The protocol will decouple the interac=
tion channels, such as the end user=E2=80=99s browser, from the delegation c=
hannel, which happens directly between the client and the authorization serv=
er (in contrast with OAuth 2.0 which is initiated by the client redirecting t=
he user=E2=80=99s browser). The client and AS will involve a user to make an=
authorization decision as necessary through interaction mechanisms indicate=
d by the protocol. This decoupling avoids many of the security concerns and t=
echnical challenges of OAuth 2.0 and provides a non-invasive path for suppor=
ting future types of clients and interaction channels.
>=20
> Additionally, the delegation process will allow for:
>=20
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interactio=
n
> - Separation between the party authorizing access and the party operating t=
he client requesting access
> - A variety of client applications, including Web, mobile, single-page, an=
d interaction-constrained applications
>=20
> The group will define extension points for this protocol to allow for flex=
ibility in areas including:
>=20
> - Cryptographic agility for keys, message signatures, and proof of possess=
ion=20
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resourc=
e requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation pro=
cess (including identity)
>=20
> Additionally, the group will provide mechanisms for management of the prot=
ocol lifecycle including:
>=20
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>=20
> Although the artifacts for this work are not intended or expected to be ba=
ckwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t=
o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w=
here possible.
>=20
> This group is not chartered to develop extensions to OAuth 2.0, and as suc=
h will focus on new technological solutions not necessarily compatible with O=
Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed i=
n the OAuth Working Group, including functionality back-ported from the prot=
ocol developed here to OAuth 2.0.
>=20
> The group is chartered to develop mechanisms for applying cryptographic me=
thods, such as JOSE and COSE, to the delegation process. This group is not c=
hartered to develop new cryptographic methods.=20
>=20
> The initial work will focus on using HTTP for communication between the cl=
ient and the authorization server, taking advantage of optimization features=
of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping=
to other protocols such as COAP when doing so does not conflict with the pr=
imary focus.
>=20
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, detach=
ed HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w
ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG
EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE
CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G
A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN
Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F
jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb
IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy
zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr
BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw
MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R
BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr
BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp
cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7
2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe
GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/
L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE
tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q
CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3
/crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG
9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv
IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw
MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl
ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d
LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z
8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV
IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q
PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc
B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw
HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E
AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw
QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv
LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv
UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE
fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB
dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz
cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG
9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW
0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj
2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF
6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT
wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN
MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy
bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC
AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMDcx
NTE3NDdaMC8GCSqGSIb3DQEJBDEiBCC+6UxRKUZfkw4U1qfmHboJ4q4f8l3Cf/PsMdJI1zhTyjCB
vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV
BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT
D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBAQUA
BIIBAC7IlpNSuGAlQdXXCTq8EWTc1y0e6mXChWE4ENNWvNmJcuYJILxX0Ido6btScQavi20eqk3y
n5NEUISNU2F464NGWo5oLzrAx2ptGPFUQ6qgCo2Gf9TxYCU4zOjahfQypdeb5xzYgTbLqQLyZ0+q
WqfXvn7zVMYezeih+vhvRspwzQiEyvUSv3nGcfl6RXgTJ+oHVPsqz/1xcPATdOWxbJPoZFdvPWiB
5YHmRfmHpqcS0mjOXPaIssJZW4LCvx3mxWQI58ff9n9wJF6GLgpMeLPoRKs5jlRbyyJBrYTRYQ29
L2CR1qGWRi/ebr1GfZAahk5ipv4FWWXv37RzkGVNE0MAAAAAAAA=
--Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0--
From nobody Sat Mar 7 16:21:06 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ABD3A152A for ; Sat, 7 Mar 2020 07:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qGaXlbRHTzgl for ; Sat, 7 Mar 2020 07:53:24 -0800 (PST)
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817703A1528 for ; Sat, 7 Mar 2020 07:53:23 -0800 (PST)
Received: by mail-ed1-x544.google.com with SMTP id g19so6363238eds.11 for ; Sat, 07 Mar 2020 07:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eFajJbtPZuz8CfAYWQH59gx1DmPezrorW0aj+arjI7Y=; b=l+tU+3EUOh/Egju/ONNNT29OIh+SVYKk2agEDyNdGtnePXfKZwdEOTJwTLFw3ElsiH La70PIJ+9LJA46EJNMk6yy968OL6TlhojOipgzo+2/SnylcPU219atHXl639z3DIpWxd g5UUD4pqXkFuq69XP/c3YvTuCVRrxBllUj01pR6TWE9BYfnrqw+B1uxH0GuYVwscx881 3Hegt3KPcWRE0bZpB8gA2VUioEVudD27oh0T2OwzI88Il9o7Xxlrat530TOcoTshlQt5 hIRnLWEsdik8F6Plh0+txQlWBG+cm6XNvxfTziPUB5mx6Y9Li22jOkK62PylYEv5iMex 2WYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eFajJbtPZuz8CfAYWQH59gx1DmPezrorW0aj+arjI7Y=; b=p28GOTOG6YECozzisN4E8qIhuxSbOupmsLFUPnEjnYJhKnQDi5JnKpWv8RvY7PLQ/z jLGh+vBMzGGCUn46DH8PBiM86u/i0F5TXb26M/6LAir9UWfHJncQL+dSOB99e+9rW1go pdgj+o/iaggN8o//qIqBZ9owBUbhZ0t8+4c0ASWGnR+c/4Fy4wnOUdX1nI23OUWivTuz xcc2mVV2+eLUwRteMe4hLiqzQe8nlVme/feFxc7DBHEFFZxkFhUb0Jk39jYJYDXKANow /qjx6WI4H3ppB5kWZ/y0Zc7duCPWDaEhIP3l+lV6dmNlE3IaK6qzJaGaQ8nS+MMqbVWn Ex5g==
X-Gm-Message-State: ANhLgQ3pO4EI0+nPSlzSvnZb/ni27vW7Y6iWmrh0Htr64I2rmIvgRhnD vCLR/qHBwpTEWd/TTzLmcAveXXaB7ZbnMrp3giO4CZ/pL2c=
X-Google-Smtp-Source: ADFU+vsVQHd4ruK9Zql2wa8IwNAISMLKu07DYZhD9X5S4GWIjeiiYvYZ9WxtdRdoWabT42dQhQlkIb5dQxa1PhZ7tnU=
X-Received: by 2002:a05:6402:b85:: with SMTP id cf5mr8601822edb.27.1583596401840; Sat, 07 Mar 2020 07:53:21 -0800 (PST)
MIME-Version: 1.0
References: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net>
In-Reply-To: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net>
From: David Skaife
Date: Sat, 7 Mar 2020 15:53:10 +0000
Message-ID:
To: Yaron Sheffer
Cc: "txauth@ietf.org"
Content-Type: multipart/alternative; boundary="000000000000ffd77605a045c451"
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 07 Mar 2020 15:53:26 -0000
X-List-Received-Date: Sat, 07 Mar 2020 15:53:26 -0000
--000000000000ffd77605a045c451
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
I'm fairly new to this group (and the OAuth group) but I'm hoping to
participate and help here.
> 1. Do you support the charter text provided at the end of this email?
Or do you have major objections, blocking concerns or feedback (if so
please elaborate)?
Yes. I share some of the same concerns that Torsten has highlighted, but
overall I'm happy with the charter text. I like that it explicitly states
that we're aiming to create a *protocol*, not a *framework *(like OAuth 2.0
was).
>
> 2. Are you willing to author or participate in the development of the
drafts of this WG?
Yes, I will help as much as my time permits.
>
> 3. Are you willing to help review the drafts of this WG?
Yes.
>
> 4. Are you interested in implementing drafts of this WG?
Yes.
Many thanks,
David Skaife
On Sat, Mar 7, 2020 at 3:17 PM Torsten Lodderstedt wrote:
> Hi,
>
> > Am 06.03.2020 um 17:45 schrieb Yaron Sheffer :
> >
> > =EF=BB=BFHi Everyone,
> >
> > It appears that momentum is forming around the proposed formation of a
> TxAuth working group. We=E2=80=99d like to more formally gauge interest =
in
> proceeding with this work. Please do so by responding to the following
> questions:
> >
> > 1. Do you support the charter text provided at the end of this email?
> Or do you have major objections, blocking concerns or feedback (if so
> please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned th=
e scope of the
> charter is too broad, e.g. identify alone is a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the group is
> able to work effectively and the specs we will be producing are as simple
> as possible and foster interoperability.
>
> >
> > 2. Are you willing to author or participate in the development of the
> drafts of this WG?
>
> yes
>
> >
> > 3. Are you willing to help review the drafts of this WG?
>
> yes
>
> >
> > 4. Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
> >
> > The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separat=
e
> thread.
> >
> > The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
> >
> > Thanks,
> > Yaron and Dick
> >
> > --- Charter Text Follows ---
> >
> > This group is chartered to develop a fine-grained delegation protocol
> for authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. It will expand upon the uses cases currently
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
> 2.0) to support authorizations scoped as narrowly as a single transaction=
,
> provide a clear framework for interaction among all parties involved in t=
he
> protocol flow, and remove unnecessary dependence on a browser or user-age=
nt
> for coordinating interactions.
> >
> > The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user=E2=80=99s browser, from the de=
legation
> channel, which happens directly between the client and the authorization
> server (in contrast with OAuth 2.0 which is initiated by the client
> redirecting the user=E2=80=99s browser). The client and AS will involve a=
user to
> make an authorization decision as necessary through interaction mechanism=
s
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasiv=
e
> path for supporting future types of clients and interaction channels.
> >
> > Additionally, the delegation process will allow for:
> >
> > - Fine-grained specification of access
> > - Approval of AS attestation to identity claims
> > - Approval of access to multiple resources and APIs in a single
> interaction
> > - Separation between the party authorizing access and the party
> operating the client requesting access
> > - A variety of client applications, including Web, mobile, single-page,
> and interaction-constrained applications
> >
> > The group will define extension points for this protocol to allow for
> flexibility in areas including:
> >
> > - Cryptographic agility for keys, message signatures, and proof of
> possession
> > - User interaction mechanisms including web and non-web methods
> > - Mechanisms for conveying user, software, organization, and other
> pieces of information used in authorization decisions
> > - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> > - Optimized inclusion of additional information through the delegation
> process (including identity)
> >
> > Additionally, the group will provide mechanisms for management of the
> protocol lifecycle including:
> >
> > - Discovery of the authorization server
> > - Revocation of active tokens
> > - Query of token rights by resource servers
> >
> > Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne=
w
> protocol where possible.
> >
> > This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back-ported
> from the protocol developed here to OAuth 2.0.
> >
> > The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
> >
> > The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
> >
> > Milestones to include:
> > - Core delegation protocol
> > - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> > - Identity and authentication conveyance mechanisms
> > - Guidelines for use of protocol extension points
> >
> >
> > --
> > Txauth mailing list
> > Txauth@ietf.org
> > https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
--000000000000ffd77605a045c451
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
I'm fairly new to this group (and the OAuth=
group) but I'm hoping to participate and help here.
=
> 1.=C2=A0 Do=
you support the charter text provided at the end of this email?=C2=A0 Or d=
o you have major objections, blocking concerns or feedback (if so please el=
aborate)?
Yes. I share some of the same concerns that Torsten=
has highlighted, but overall I'm happy with the charter text. I like t=
hat it explicitly states that we're aiming to create a protocol,=
not a framework (like OAuth 2.0 was).
>=C2=A0
> 2.=C2=A0 Are you willing=
to author or participate in the development of the drafts of this WG?
<=
br>Yes, I will help as much as my time permits.
>=C2=A0
> 3.=C2=A0 Are yo=
u willing to help review the drafts of this WG?
Yes.
>=C2=A0
> 4.=
=C2=A0 Are you interested in implementing drafts of this WG?=C2=A0=
=C2=A0
Yes.
Many thanks,
David Skaife
Hi,
> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>
> =EF=BB=BFHi Everyone,
>=C2=A0
> It appears that momentum is forming around the proposed formation of a=
TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge inter=
est in proceeding with this work.=C2=A0 Please do so by responding to the f=
ollowing questions:
>=C2=A0
> 1.=C2=A0 Do you support the charter text provided at the end of this e=
mail?=C2=A0 Or do you have major objections, blocking concerns or feedback =
(if so please elaborate)?
I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned the =
scope of the charter is too broad, e.g. identify alone is a huge topic.
We need to keep an eye on this aspect in order to make sure, the group is a=
ble to work effectively and the specs we will be producing are as simple as=
possible and foster interoperability.
>=C2=A0
> 2.=C2=A0 Are you willing to author or participate in the development o=
f the drafts of this WG?
yes
>=C2=A0
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
yes
>=C2=A0
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
yes
best regards,
Torsten.
>=C2=A0
> The call will run for two weeks, until March 21. If you think that the=
charter should be amended In a significant way, please reply on a separate=
thread.
>=C2=A0
> The feedback provided here will help the IESG come to a decision on th=
e formation of a new WG. Given the constraints of the chartering process, r=
egardless of the outcome of this consensus call, we will be meeting in Vanc=
ouver as a BoF.
>=C2=A0
> Thanks,
> Yaron and Dick
>=C2=A0
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol =
for authorization, identity, and API access. This protocol will allow an au=
thorizing party to delegate access to client software through an authorizat=
ion server. It will expand upon the uses cases currently supported by OAuth=
2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support autho=
rizations scoped as narrowly as a single transaction, provide a clear frame=
work for interaction among all parties involved in the protocol flow, and r=
emove unnecessary dependence on a browser or user-agent for coordinating in=
teractions.
>
> The delegation process will be acted upon by multiple parties in the p=
rotocol, each performing a specific role. The protocol will decouple the in=
teraction channels, such as the end user=E2=80=99s browser, from the delega=
tion channel, which happens directly between the client and the authorizati=
on server (in contrast with OAuth 2.0 which is initiated by the client redi=
recting the user=E2=80=99s browser). The client and AS will involve a user =
to make an authorization decision as necessary through interaction mechanis=
ms indicated by the protocol. This decoupling avoids many of the security c=
oncerns and technical challenges of OAuth 2.0 and provides a non-invasive p=
ath for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single intera=
ction
> - Separation between the party authorizing access and the party operat=
ing the client requesting access
> - A variety of client applications, including Web, mobile, single-page=
, and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for =
flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of pos=
session
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pie=
ces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding res=
ource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation=
process (including identity)
>
> Additionally, the group will provide mechanisms for management of the =
protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to b=
e backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att=
empt to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro=
tocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as=
such will focus on new technological solutions not necessarily compatible =
with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dev=
eloped in the OAuth Working Group, including functionality back-ported from=
the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographi=
c methods, such as JOSE and COSE, to the delegation process. This group is =
not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between th=
e client and the authorization server, taking advantage of optimization fea=
tures of HTTP2 and HTTP3 where possible, and will strive to enable simple m=
apping to other protocols such as COAP when doing so does not conflict with=
the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, de=
tached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org=
a>
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--000000000000ffd77605a045c451--
From nobody Sat Mar 7 19:17:28 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB853A0791 for ; Sat, 7 Mar 2020 19:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SOxezQ0Tr2iE for ; Sat, 7 Mar 2020 19:17:25 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91953A078C for ; Sat, 7 Mar 2020 19:17:24 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id j17so348653lfe.7 for ; Sat, 07 Mar 2020 19:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rpB2/WrOYFwSx7l+N0S9w9hdy8PkW0NAKFjts/kcAg0=; b=DwAu4m8WNQomdSK0l3CffMUfiMB1hWw6dnRALj/iy2046fTr7V5JcUx8IIDW3IRYYt zHrbP2jCDTXymBGmOqoStisLpkLzwqBupuR+NXmJiNfXtnR2ZQxrGdnaTeXrjHRY81XH NfDat8sxFLIlE0FAVJHFoOr731bZSyLtbGq7xqFvMDfJiNmnqHCxVKO4nA85KAGqmEqr NiHkTjWP9/Dyp/1OPfKr1sc3zVxd6PSK7yHgFVVg8astlKKpkwQeswGMzqMOWjs6rBHz OEwtz3CW95BYNQl1tU3D7R/ZTQFYek6Qe2DmkW+8y8jriFNiKsqijo5Uhqk32UhRo1Qy BuBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rpB2/WrOYFwSx7l+N0S9w9hdy8PkW0NAKFjts/kcAg0=; b=IvjsROVEIlEWbdEOV6VRSbVsbQRbHyVgulkS1NQTgmb4aOJ8oat0y4XqQlFnMmPnja eRpPQ92EaUPxC0j7dERKQbFcVo/jAMU/DXd0Dd3aXmWLfxJxT2iaklztjLn7kbmJxuus B//rS7+UMPUSiU2W/fGj5zA8JzLW77ZaADj9QQ0ZimidwYd7Ci5MFBiqzcQfcaQP1Wyo 0RdDBbX8GTVLtYZuUxuHR/0nf4u3uIuWPMY1nDWE1CuRksxYqlY8zbcuX4qQqPdSg3m1 2Z9yJMCBkXakGoa+9XkryRYbEo1D2OIpoK4tmu/ExBw8pu+A0UIW5UgkolevFQY3sW9p yLLQ==
X-Gm-Message-State: ANhLgQ3ZkQzWyovN04HzB4jVlnOnuZFIE/p4z2iiu+GPAvQMhf8k5PEX SjIAg5vurOmC4PcqUuwWaRIW8/Qm3ttVeOyenNoz2woHt0s=
X-Google-Smtp-Source: ADFU+vvbTAn6QjvZiubjcpPRwlUTtL17h5JYJlTk56Um9+7XWCtj+7rO28LNLgthbuf0+RVT4LMM6DTlyZ+r2mA+LVI=
X-Received: by 2002:ac2:4c36:: with SMTP id u22mr5902669lfq.91.1583637442088; Sat, 07 Mar 2020 19:17:22 -0800 (PST)
MIME-Version: 1.0
References: <158363691397.25530.3652753138946434165@ietfa.amsl.com>
In-Reply-To: <158363691397.25530.3652753138946434165@ietfa.amsl.com>
From: Dick Hardt
Date: Sat, 7 Mar 2020 19:16:56 -0800
Message-ID:
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003053c005a04f5316"
Archived-At:
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-05.txt
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 08 Mar 2020 03:17:27 -0000
--0000000000003053c005a04f5316
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Please forgive, and point out inconsistencies! If anything is confusing,
please let me know. It is likely a mistake on my part!
1. I'm proposing there are only 2 types of interactions defined: a
redirect interaction where the Client can redirect to the GS, and the GS
back to the Client; or an indirect interaction where the User somehow ge=
ts
to the GS, and there is no redirect back to the Client. The security
characteristics are different, as session fixation can be prevented if t=
he
GS redirects back to the Client as the Client is able to verify the User=
it
is interacting with is the same as the User the GS is interacting with.
2. I added a sequence where the Client does a PATCH on the Grant URI
with an interaction nonce received from the GS in the redirect back to t=
he
Client to protect against fixation attacks.
3. The Authorization lifecycle and management is now independent of the
Grant. A Client now receives an access token, OR an AuthZ URI. Reading a=
nd
refreshing an access token are the same thing.
A more complete list of changes is below:
draft-hardt-xauth-protocol-05
- separated claims from identifiers in request user object
- simplified reciprocal grant flow
- reduced interactions to redirect and indirect
- simplified interaction parameters
- added in language for Client to verify interaction completion
- added Verify Grant API and Interaction Nonce
- replaced Refresh AuthZ with Read AuthZ. Read and refresh are same
operation.
---------- Forwarded message ---------
From:
Date: Sat, Mar 7, 2020 at 7:08 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-05.txt
To: Dick Hardt
A new version of I-D, draft-hardt-xauth-protocol-05.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.
Name: draft-hardt-xauth-protocol
Revision: 05
Title: The XAuth Protocol
Document date: 2020-03-07
Group: Individual Submission
Pages: 59
URL:
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt
Status: https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol=
/
Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-05
Abstract:
Client software often desires resources or identity claims that are
independent of the client. This protocol allows a user and/or
resource owner to delegate resource authorization and/or release of
identity claims to a server. Client software can then request access
to resources and/or identity claims by calling the server. The
server acquires consent and authorization from the user and/or
resource owner if required, and then returns to the client software
the authorization and identity claims that were approved. This
protocol can be extended to support alternative authorizations,
claims, interactions, and client authentication mechanisms.
Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
=E1=90=A7
--0000000000003053c005a04f5316
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Please forgive, and poin=
t out inconsistencies! If anything is confusing, please let me know. It is =
likely a mistake on=C2=A0my part!
- I'm proposing=
there are only 2 types of interactions defined: a redirect interaction whe=
re the Client can redirect to the GS, and the GS back to the Client; or an =
indirect interaction where the User somehow gets to the GS, and there is no=
redirect back to the Client. The security characteristics=C2=A0are differe=
nt, as session fixation can be prevented if the GS redirects back to the Cl=
ient as the Client is able to verify the User it is interacting with is the=
same as the User the GS is interacting with.=C2=A0
- =
I added a sequence where the Client does a PATCH on the Grant URI with an i=
nteraction nonce received=C2=A0from the GS in the redirect back to the Clie=
nt to protect against fixation attacks.
- The A=
uthorization lifecycle and management is now independent of the Grant. A Cl=
ient now receives an access token, OR an AuthZ URI. Reading and refreshing =
an access token are the same thing.=C2=A0
A more complete list of changes is below:
draft-hardt-xauth-protocol-05
- separat=
ed claims from identifiers in request user object
- simplified reciprocal grant=
flow
- reduced interactions to redirect and indirect
- simplified interaction para=
meters
- added in language for Client to verify interaction completion<=
/li>
- added =
Verify Grant API and Interaction Nonce
- replaced Refresh AuthZ with Read AuthZ=
. Read and refresh are same operation.
A new version of I-D, draft-hardt-xauth-protocol-05.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-03-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 59
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
https://www.ietf.org/internet-drafts/draft-hardt-xauth-prot=
ocol-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0
https:/=
/tools.ietf.org/html/draft-hardt-xauth-protocol-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0
=
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-=
05
Abstract:
=C2=A0 =C2=A0Client software often desires resources or identity claims tha=
t are
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a=
nd/or
=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea=
se of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re=
quest access
=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2=
=A0 The
=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=
=C2=A0 =C2=A0resource owner if required, and then returns to the client sof=
tware
=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2=
=A0 This
=C2=A0 =C2=A0protocol can be extended to support alternative authorizations=
,
=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.
Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at
tools.ietf.org.
The IETF Secretariat
=E1=90=A7
--0000000000003053c005a04f5316--
From nobody Sun Mar 8 03:23:00 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2E3A08AB for ; Sun, 8 Mar 2020 03:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0xPEnYLPisbT for ; Sun, 8 Mar 2020 03:22:57 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CC13A08AA for ; Sun, 8 Mar 2020 03:22:57 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id q128so6323004iof.9 for ; Sun, 08 Mar 2020 03:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MG02uSB2o0TiWil41hZLB4odLBco//6M6zr7Zn58xtk=; b=Y5C676wAa14MtSiDlU1Kr1+q5tGffP4G0KH7WqQVt1lHcfaB0zV+khBcIDsGfjDQu9 z7ULcfOoxWmeigUh+3jEEzLzXJ1JMlqMo5/TowWcGKVgtDY0HpYYAdh/L+UEj85VQBUf Evr3yjRnWDwJxCmn3E1N3AESMMCMc/Dx4cXTgtCjLkOzaOKLYueCFPkkXRSCy1Hn+oyg qj1SgoxAGy74bPEhl9W9EN9GcsYX1pxrFKO68MxYyyv0/G/+H4VUMAsCiK4igvMvN/HP MWP3AH1gVmnETqYTSipzC7+5wcrMigbnouSKOw1hfwpNbFOZh4tkZfW57CFLtIpw89UQ SeTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MG02uSB2o0TiWil41hZLB4odLBco//6M6zr7Zn58xtk=; b=lKHh8XAWgsrId5YEw8JOao82Ugpv7cHwk1HTEIvkG2WaToY2hjvyrbl4eAhnAEpeb9 1ebCRiXtJEFu+SzXnyltTWQNFXmLX/HIQFR740V7BHP04qcq7D45PtXsRDbEoeKJd0Mw 5KCKYWol9ozRZ5SpXegF3SCJuyYl+mbd3E0C2dZld/bHfyq7inHaDyncca6fet0Fc0Wa bJGzSk3p0nVhbYyqrAPEpjdGuLz1BDFkgVn2QOw3BEzqQMb5hm9aXgehzBCY1CAj8qGs FiGp5AoYtq1IWdPljkStXH39VOQMZTw/eRyNoti+W24iNIAmXBi+HAp7X+kPYJmoRll4 iYvQ==
X-Gm-Message-State: ANhLgQ26OqCsKpDgeW+kvbsvIojgX4sYAkPKgosgJVxKS6pC0+ITkhRS h0FmWPuahdbfNf8Aso1tqDHQ9COviSkIX3Zz+YIaigeJyqQ=
X-Google-Smtp-Source: ADFU+vvdgFrsKWZBVVjjcFsqP6lsKglGA5G3UtyhbkmZqJaiN/6OIWsao7FyqK7UCsCWW2Oqqu4sL4Herjoe8IFEWM4=
X-Received: by 2002:a02:c815:: with SMTP id p21mr11001065jao.20.1583662976475; Sun, 08 Mar 2020 03:22:56 -0700 (PDT)
MIME-Version: 1.0
From: Vijay IETF
Date: Sun, 8 Mar 2020 15:52:45 +0530
Message-ID:
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002829fa05a055459a"
Archived-At:
Subject: [Txauth] Response to Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 08 Mar 2020 10:22:59 -0000
--0000000000002829fa05a055459a
Content-Type: text/plain; charset="UTF-8"
Hi All,
I recently subscribed to the TxAuth WG mailing list after the Call for
charter consensus was posted. Therefore I am unable to reply to it directly
(as far as my knowledge of Mailman goes) because I don't have it in my
inbox. Apologies if this creates a new thread but I have been advised that
it is okay to do so.
My response to the consensus call is as below.
1. Do you support the charter text provided at the end of this email? Or
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
Yes.
> 2. Are you willing to author or participate in the development of the
> drafts of this WG?
Yes
> 3. Are you willing to help review the drafts of this WG?
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes
---
Brief aside:
My interest in this WG arises from my core belief that *consent* should be
transactional with an expires header. And that the Internet identity layer
(which OIDC claims to be) is fundamentally broken.
So when I read the charter it gave me hope and encouraged me to join this
list. I think this is a timely initiative and I will be happy to contribute
in any manner the WG finds suitable.
Thanks and regards!
Vijay
--0000000000002829fa05a055459a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi All,
I recently subscribe=
d to the TxAuth WG mailing list after the=C2=A0 Call
for charter consensus was posted. Therefore I am unable to reply to it=20
directly (as far as my knowledge of Mailman goes) because I don't have=
=20
it in my inbox. Apologies if this creates a new thread but I have been advi=
sed that it is okay to do so.
My response to t=
he consensus call is as below.
1.=C2=A0
Do you support the charter text provided at the end of this email?=C2=A0 O=
r=20
do you have major objections, blocking concerns or feedback (if so=20
please elaborate)?
Yes.
=C2=A0
=
2.=C2=A0 Are you willing =
to author or participate in the development of the drafts of this WG?
Yes=C2=A0
=C2=A0
3.=C2=A0 Are you willing to help review the draf=
ts of this WG?
=C2=A0
Yes=C2=A0
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">4.=C2=A0 Are you intereste=
d in implementing drafts of this WG?
=C2=A0
Yes =
---
Brief aside:
=
My interest in this WG arises from my core belief that *consent*=
should be transactional with an expires header. And that the Internet iden=
tity layer (which OIDC claims to be) is fundamentally broken.
So when I read the charter it gave me hope and encouraged =
me to join this list. I think this is a timely initiative and I will be hap=
py to contribute in any manner the WG finds suitable.
<=
div>Thanks and regards!
Vijay
=
div>
--0000000000002829fa05a055459a--
From nobody Sun Mar 8 12:44:12 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE243A0869 for ; Sun, 8 Mar 2020 12:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet.se
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 5XUmw6rLe8Np for ; Sun, 8 Mar 2020 12:44:07 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D523A0873 for ; Sun, 8 Mar 2020 12:44:06 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id e18so7690906ljn.12 for ; Sun, 08 Mar 2020 12:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=79kPRdCgabLqd45Y0RXubmfu19ECrZ78QOpQeAVEpM4=; b=Uxenxtf68pJrOwGZ1rhhTPQu43DuyGId1E/XWW9rkUfsO9clFzGEzrDeoT12mQElZA rFzVeMdkoC6D9c92HatyPd3Ms6nvs51N9e5P3tQWcbOOBEIWCgbXdfim7rZrntUn9Rmy 5F/8Dn948Bhxhpx9jEeAjVZy4sBjO8RKD+z2wiasMtskhF4LXJA7pPBvxO9Qw9DesIlg AxUoJihIJIO14DEqGo5oz93oYDAxhADotKMxnT/bQmzdEZEdK0KvilDg91uUOlozUcvt b64SjaYcgTGF434nqBvsqlQVJ8r6TEBtoyfp/l6tGrmyoo4ymZd1lb2fap4CPCrLLbwk w+Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=79kPRdCgabLqd45Y0RXubmfu19ECrZ78QOpQeAVEpM4=; b=n3UDGYGmXs8wTKtpNMmCy3A8Un3Y7HGn1XfKpCAYVpqLDIBKs63K9KyXjYKyi43RCu W+GZq5y+QhUNXogEBS+D55BAni8FWLoBDsx/Kw8kIqlsDpxMhNk8Luvn85eFutiXAAvf Gg2PL0Bd0jkaE6HAqS/G45aknLQQs+XcuXXXHTiFoGpksPQUZ++jS+Uec7dEjSOEvCCs gtf3V3ZjnDa39fTqIv9sLDl44/41bGd53ywZOB6xCM7M73vxwUsquHf2cSWpqmq4+r2R aWFuK/vExRvKHAMYXwcdFrFUXwhrngL2Ggnb8zOVa4nGr7iJc7UFXztLenE2gmJN4ujx SADw==
X-Gm-Message-State: ANhLgQ3u5WP3d7hToaXPunMDPCWl6uWAPzGwxEhR31SIq4mVgJ0gyW9x UPAQIr7cbeQSipBfMm5BO8gI/o/0QmY=
X-Google-Smtp-Source: ADFU+vsoRD1TFanzcEDV7JyiEVv4bLFkX4broBDcr2cg7hHBE8JLsfF9iVICQdwiPcA5hSAvcRV1ww==
X-Received: by 2002:a2e:9b90:: with SMTP id z16mr7931929lji.254.1583696644341; Sun, 08 Mar 2020 12:44:04 -0700 (PDT)
Received: from [10.0.0.192] (h-158-174-186-56.NA.cust.bahnhof.se. [158.174.186.56]) by smtp.gmail.com with ESMTPSA id k24sm1371826ljc.25.2020.03.08.12.44.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Mar 2020 12:44:03 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Leif Johansson
Mime-Version: 1.0 (1.0)
Date: Sun, 8 Mar 2020 20:44:01 +0100
Message-Id:
References:
Cc: "txauth@ietf.org"
In-Reply-To:
To: Yaron Sheffer
X-Mailer: iPhone Mail (17D50)
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 08 Mar 2020 19:44:10 -0000
Skickat fr=C3=A5n min iPhone
> 6 mars 2020 kl. 17:45 skrev Yaron Sheffer :
>=20
> =EF=BB=BFHi Everyone,
> =20
> It appears that momentum is forming around the proposed formation of a TxA=
uth working group. We=E2=80=99d like to more formally gauge interest in pro=
ceeding with this work. Please do so by responding to the following questio=
ns:
> =20
> 1. Do you support the charter text provided at the end of this email? Or=
do you have major objections, blocking concerns or feedback (if so please e=
laborate)?
Yes
> =20
> 2. Are you willing to author or participate in the development of the dra=
fts of this WG?
> =20
Review more than author probably
> 3. Are you willing to help review the drafts of this WG?
> =20
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes=20
> =20
> The call will run for two weeks, until March 21. If you think that the cha=
rter should be amended In a significant way, please reply on a separate thre=
ad.
> =20
> The feedback provided here will help the IESG come to a decision on the fo=
rmation of a new WG. Given the constraints of the chartering process, regard=
less of the outcome of this consensus call, we will be meeting in Vancouver a=
s a BoF.
> =20
> Thanks,
> Yaron and Dick
> =20
> --- Charter Text Follows ---
>=20
> This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authoriz=
ing party to delegate access to client software through an authorization ser=
ver. It will expand upon the uses cases currently supported by OAuth 2.0 and=
OpenID Connect (itself an extension of OAuth 2.0) to support authorizations=
scoped as narrowly as a single transaction, provide a clear framework for i=
nteraction among all parties involved in the protocol flow, and remove unnec=
essary dependence on a browser or user-agent for coordinating interactions.=20=
>=20
> The delegation process will be acted upon by multiple parties in the proto=
col, each performing a specific role. The protocol will decouple the interac=
tion channels, such as the end user=E2=80=99s browser, from the delegation c=
hannel, which happens directly between the client and the authorization serv=
er (in contrast with OAuth 2.0 which is initiated by the client redirecting t=
he user=E2=80=99s browser). The client and AS will involve a user to make an=
authorization decision as necessary through interaction mechanisms indicate=
d by the protocol. This decoupling avoids many of the security concerns and t=
echnical challenges of OAuth 2.0 and provides a non-invasive path for suppor=
ting future types of clients and interaction channels.
>=20
> Additionally, the delegation process will allow for:
>=20
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interactio=
n
> - Separation between the party authorizing access and the party operating t=
he client requesting access
> - A variety of client applications, including Web, mobile, single-page, an=
d interaction-constrained applications
>=20
> The group will define extension points for this protocol to allow for flex=
ibility in areas including:
>=20
> - Cryptographic agility for keys, message signatures, and proof of possess=
ion=20
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resourc=
e requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation pro=
cess (including identity)
>=20
> Additionally, the group will provide mechanisms for management of the prot=
ocol lifecycle including:
>=20
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>=20
> Although the artifacts for this work are not intended or expected to be ba=
ckwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t=
o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w=
here possible.
>=20
> This group is not chartered to develop extensions to OAuth 2.0, and as suc=
h will focus on new technological solutions not necessarily compatible with O=
Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed i=
n the OAuth Working Group, including functionality back-ported from the prot=
ocol developed here to OAuth 2.0.
>=20
> The group is chartered to develop mechanisms for applying cryptographic me=
thods, such as JOSE and COSE, to the delegation process. This group is not c=
hartered to develop new cryptographic methods.=20
>=20
> The initial work will focus on using HTTP for communication between the cl=
ient and the authorization server, taking advantage of optimization features=
of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping=
to other protocols such as COAP when doing so does not conflict with the pr=
imary focus.
>=20
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, detach=
ed HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
From nobody Mon Mar 9 02:12:20 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35933A0AD3 for ; Mon, 9 Mar 2020 02:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Os52wsEyj3Sc for ; Mon, 9 Mar 2020 02:12:08 -0700 (PDT)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DC43A0B00 for ; Mon, 9 Mar 2020 02:12:08 -0700 (PDT)
Received: by mail-io1-xd42.google.com with SMTP id r15so8413428iog.0 for ; Mon, 09 Mar 2020 02:12:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0ebz20upW8xx3EeTtTr5T6E9i+DGMELukHKsrZ2hYwg=; b=cbQITygCIv67tI0BveTyVfyX42jzblyRb38c+iciJuhm8EN6Fw8nqVQOWgLyzpIkwb Anae92fy0Iyct85IeVlL3lYuFnNXaKCGpIcqpEp/67mop8Tv1Xq2wZtvZfu/LlB7VubE SQgpx92AKkvDBN0f1FYrADG0Tl/csAbN7sG6nJ9bgE5xJ2GOvuCDreCCjeU1tmiikMXD x8cPIJYWog3B0y5FS+Hl8tMhPz1bJi0BxsXwh4Athc1gvWfTbQDdWbC55AOewjJAuC11 NnGVQGsogMk/C8UQgpXI4J9kCzKFVnZFd2BjaEtSEmxbroQEMTD2iQESpLP4vFBfEROH ODYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0ebz20upW8xx3EeTtTr5T6E9i+DGMELukHKsrZ2hYwg=; b=N+0deXbStb62a9oyH1ADFbAZXfq8s0R0UyhDNTOwctw24+Wu67VpxWlx6bwpCDUExG vcwshTHnmKwBc/ebm/4kAUyHitwB3F+M2Ntoa6EvEuRSWDZviUYQy8FfvsotTi467HBs pYpgwEFEnpe0GDASO+B6c7HoXsmaow0n/zzrNZCVoWeg9pYx3Dp9/6kgeEZrB/b2SlaK RhWNlq0JGLXAjN8etmIb0X6+ftkL64PhKng/oQ4EB8LZHJAeVUWwkg2lwwBBf8cvNGRY Pk6F7KmU9IPff+Zr51xWu8UlubjVJaEIX7tUXq3M3B/SKz/R32Jep4tqJVoNRSfES2Yn IJnQ==
X-Gm-Message-State: ANhLgQ2pWn0e6LVhReTG3QbFVYVDBUG5dzHqpFK9JG6KSd9oddiXMb1W UCmaD9OAtFO7NNCOr7bCbDKoEl7jfapWJsJ8wsWj1Yxj
X-Google-Smtp-Source: ADFU+vuIF+7BJRo2TJtQFLICGKpnGbVfaDTUcnmPISm5AvndzhcPOaG+KcATq7us3M3i2R8SeegdlMJS0+EfWD5n/AE=
X-Received: by 2002:a5d:9ed4:: with SMTP id a20mr12680058ioe.187.1583745127242; Mon, 09 Mar 2020 02:12:07 -0700 (PDT)
MIME-Version: 1.0
From: Vijay IETF
Date: Mon, 9 Mar 2020 14:41:55 +0530
Message-ID:
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b95f8705a06865fd"
Archived-At:
Subject: [Txauth] XAuth vs AuthZ vs ...
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 09 Mar 2020 09:12:19 -0000
--000000000000b95f8705a06865fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
I spent yesterday catching up with the mailing list. That was too much to
digest in a day and I am still trying to figure out the boundaries and
scope.
One thing that is not clear is regarding the multiple proposals in draft
form that have been going around.
The best disambiguation I could find was:
> To disambiguate between different efforts, I=E2=80=99ll refer to Dick=E2=
=80=99s draft as XAuth, my own draft as XYZ, and the proposed working group=
work here (as in our eventual output) as TxAuth.
My question is do these proposals converge, compete or the best one by
consensus or otherwise supersedes the other?
Apologies if that is a dumb question. A map of efforts/proposals/drafts of
this WG would be quite helpful to new comers such as myself. Thx!
---
Vijay
--000000000000b95f8705a06865fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
I spent yesterday catchi=
ng up with the mailing list. That was too much to digest in a day and I am =
still trying to figure out the boundaries and scope.
One thing that is not clear is regarding the multiple proposals in =
draft form that have been going around.
The be=
st disambiguation I could find was:
> To disambiguate between different efforts, I=E2=80=99ll refer to Dick=
=E2=80=99s draft as XAuth, my own draft as XYZ, and the proposed working gr=
oup work here (as in our eventual output) as TxAuth.
My qu=
estion is do these proposals converge, compete or the best one by consensus=
or otherwise supersedes the other?
Apologies if t=
hat is a dumb question. A map of efforts/proposals/drafts of this WG would =
be quite helpful to new comers such as myself. Thx!
---
Vijay
--000000000000b95f8705a06865fd--
From florianb@spotify.com Mon Mar 9 02:15:24 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9A3A0AEF for ; Mon, 9 Mar 2020 02:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=spotify.com
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 JwyWnG0iXJBf for ; Mon, 9 Mar 2020 02:15:21 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43DE3A0AEB for ; Mon, 9 Mar 2020 02:15:21 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id a14so4846217ilk.6 for ; Mon, 09 Mar 2020 02:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7a2Yv6NBqoYRSWeRfjdEqiKC0n9eTvNWwrEvuhba+E=; b=YuHyzefVkN7cX3snyopcTn8Fei2e7BX4XR7VULSpgYjbgKPkAZK3EQ3de3/THBE8Yg t55SGTGoGegLVSBdo/iZUAeOoLvrr3gg09XDaECs9f/RBBZWdy3RLDmNdb6BAN2uVgmA ePRc9Lui4IhGdVnCiUYbBNrI0qVS2mqEXfknI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7a2Yv6NBqoYRSWeRfjdEqiKC0n9eTvNWwrEvuhba+E=; b=MxNCactDzAaUanPLiCMv5BlsfZFVJjruoKglyJhMET90oiC/Wt6TSV9azKHZAYVui2 T+15l70jgv7M12O777YhYBS9QYVWUVEjT4Cdqqt8dlwBY1J1EuWjGt70vBvLmpHI9oIk X20JiPL73LCIaTyNBfepRPMr8uW2VNM5CN9jt618rDz9/kXOwwaTbQ+r+GC8fWT+SYJb S5hec1WLkZXUU7qBvDHnpv385CKPRDDjjLUE5ElpjyA32b1BAJ/v9PYWO6sUoYHuLz3V 9gtlU8ANeDh9a1zf+zu9n8/wWBQ7gqBPeHxvgyl1iRyFPcaVy+CYSB71nd1wxjdAFPbl lxtw==
X-Gm-Message-State: ANhLgQ3TB9Tb1k3BTNCYoPZhJGXhKxjmOSdrIMbU6gzSbDF0YI4iawR9 6uHH4RgIXJlYJGkCbrFOpKdd3Ox1ICh3pnl8IiCjWg==
X-Google-Smtp-Source: ADFU+vslInRsrwrx6m9hygOB+dDCRTAhTV7QZyNbGjs58XZLSkSix5FMPniPo6UO0c0e742WkeoMGhLwEq9G4urAmSg=
X-Received: by 2002:a92:86c6:: with SMTP id l67mr14740282ilh.225.1583745320773; Mon, 09 Mar 2020 02:15:20 -0700 (PDT)
MIME-Version: 1.0
References:
In-Reply-To:
From: Florian Biesinger
Date: Mon, 9 Mar 2020 10:15:09 +0100
Message-ID:
To: Yaron Sheffer
Cc: "txauth@ietf.org"
Content-Type: multipart/alternative; boundary="00000000000042851205a0687123"
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 09 Mar 2020 09:18:35 -0000
--00000000000042851205a0687123
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
4x yes as well.
On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer wrote:
> Hi Everyone,
>
> It appears that momentum is forming around the proposed formation of a
> TxAuth working group. We=E2=80=99d like to more formally gauge interest =
in
> proceeding with this work. Please do so by responding to the following
> questions:
>
> 1. Do you support the charter text provided at the end of this email? O=
r
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
>
> 2. Are you willing to author or participate in the development of the
> drafts of this WG?
>
> 3. Are you willing to help review the drafts of this WG?
>
> 4. Are you interested in implementing drafts of this WG?
>
> The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separat=
e
> thread.
>
> The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
>
> Thanks,
> Yaron and Dick
>
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. It will expand upon the uses cases currently
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
> 2.0) to support authorizations scoped as narrowly as a single transaction=
,
> provide a clear framework for interaction among all parties involved in t=
he
> protocol flow, and remove unnecessary dependence on a browser or user-age=
nt
> for coordinating interactions.
>
> The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user=E2=80=99s browser, from the de=
legation
> channel, which happens directly between the client and the authorization
> server (in contrast with OAuth 2.0 which is initiated by the client
> redirecting the user=E2=80=99s browser). The client and AS will involve a=
user to
> make an authorization decision as necessary through interaction mechanism=
s
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasiv=
e
> path for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interacti=
on
> - Separation between the party authorizing access and the party operating
> the client requesting access
> - A variety of client applications, including Web, mobile, single-page,
> and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of
> possession
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces
> of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation
> process (including identity)
>
> Additionally, the group will provide mechanisms for management of the
> protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne=
w
> protocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back-ported
> from the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
--=20
/Flo
--=20
Florian Biesinger =E2=99=AB | Backend Engineer | florian@spotify.com | +46 =
70 36 72
133
Spotify GmbH
c/o Mindspace
Krausenstra=C3=9Fe 9
10117 Berlin
Get Spotify here!
This e-mail (including any attachments) may contain information that
is confidential and/or privileged. It is intended only for the
recipient(s). If you have reason to believe that you are not the intended
recipient of this e-mail, please contact the sender immediately and delete
the e-mail from your computer.
--00000000000042851205a0687123
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
4x yes as well.
Hi Ever=
yone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu=
th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i=
n proceeding with this work.=C2=A0 Please do so by responding to the follow=
ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?=
=C2=A0 Or do you have major objections, blocking concerns or feedback (if s=
o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the=
drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char=
ter should be amended In a significant way, please reply on a separate thre=
ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for=
mation of a new WG. Given the constraints of the chartering process, regard=
less of the outcome of this consensus call, we will be meeting in Vancouver=
as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---
This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authori=
zing party to delegate access to client software through an authorization s=
erver. It will expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat=
ions scoped as narrowly as a single transaction, provide a clear framework =
for interaction among all parties involved in the protocol flow, and remove=
unnecessary dependence on a browser or user-agent for coordinating interac=
tions.
The delegation process will be acted upon by multiple parties in the protoc=
ol, each performing a specific role. The protocol will decouple the interac=
tion channels, such as the end user=E2=80=99s browser, from the delegation =
channel, which happens directly between the client and the authorization se=
rver (in contrast with OAuth 2.0 which is initiated by the client redirecti=
ng the user=E2=80=99s browser). The client and AS will involve a user to ma=
ke an authorization decision as necessary through interaction mechanisms in=
dicated by the protocol. This decoupling avoids many of the security concer=
ns and technical challenges of OAuth 2.0 and provides a non-invasive path f=
or supporting future types of clients and interaction channels.
Additionally, the delegation process will allow for:
- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t=
he client requesting access
- A variety of client applications, including Web, mobile, single-page, and=
interaction-constrained applications
The group will define extension points for this protocol to allow for flexi=
bility in areas including:
- Cryptographic agility for keys, message signatures, and proof of possessi=
on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource=
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc=
ess (including identity)
Additionally, the group will provide mechanisms for management of the proto=
col lifecycle including:
- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers
Although the artifacts for this work are not intended or expected to be bac=
kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt =
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol=
where possible.
This group is not chartered to develop extensions to OAuth 2.0, and as such=
will focus on new technological solutions not necessarily compatible with =
OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope=
d in the OAuth Working Group, including functionality back-ported from the =
protocol developed here to OAuth 2.0.
The group is chartered to develop mechanisms for applying cryptographic met=
hods, such as JOSE and COSE, to the delegation process. This group is not c=
hartered to develop new cryptographic methods.
The initial work will focus on using HTTP for communication between the cli=
ent and the authorization server, taking advantage of optimization features=
of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin=
g to other protocols such as COAP when doing so does not conflict with the =
primary focus.
Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d=
etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
/Flo
--=C2=A0Florian Biesinger=C2=A0=E2=99=AB=C2=A0| Backend Engineer=C2=A0|=C2=A0florian@spotify.com=C2=A0|=C2=A0+46=C2=A070 36 72 133
Spotify GmbH=C2=A0
c/o Mindspace
Krausenstra=C3=9Fe 910117 Berlin
This e-mail (including any attachments) may contai=
n information that is=C2=A0confidential and/or privileged. It is intended o=
nly for the recipient(s). If=C2=A0you have reason to believe that you are n=
ot the intended recipient of this=C2=A0e-mail, please contact the sender im=
mediately and delete the e-mail from=C2=A0your computer.
=
--00000000000042851205a0687123--
From nobody Mon Mar 9 03:08:37 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8593A0BF1 for ; Mon, 9 Mar 2020 03:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swissre.com
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 XeuaLeHg9e3F for ; Mon, 9 Mar 2020 03:08:33 -0700 (PDT)
Received: from esa2.hc1106-67.c3s2.iphmx.com (esa2.hc1106-67.c3s2.iphmx.com [139.138.62.206]) (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 EBBB93A0BF0 for ; Mon, 9 Mar 2020 03:08:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1583748513; x=1615284513; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hgY5F/xd5KCquo3PvJF6Qk9RwHcpwJ/dTVm3hCLUM8k=; b=XsxFwOrUaAfAyTnOIvgwLd4za5wL/M/28Vc/Wt2y8WhffhHkYkvvfumg xLL5gT1vOq89Rs8UD5XmdyIiFJiqyqlH7l8J5ABpuTGYFJpPCk4+FVaS3 iredlEZz6KbQOZ1K9RH1wiikxufAdV0LFl0oLcU7hVpBXZs3vKUWvNjhB c/857iLDzW2TbVRwf/zVzK6Q+7xUpYzBA+Ng5bHPz9fWoP0YOhm06xOWe G8D6ViyOMcVWwM98++943Ymnb8AKbP8534vnC7rHc3PFVf0DOqnXEqeNn VAoD10hGGJyJWESTT+hd7nTY9SSbSFtHSZPNgLCsCb5Koh79cRLg8jH0c g==;
IronPort-SDR: J9uPxhy7OW1XPSN/cMtddzLcJoSWnyZ7a//tuiVNMUspcQGMpt+ZbnsmYuy6AD5BHIASqetV5l 4oBZpqmPTSQkEs+OAEsbgtO/Rdko75jkq6lPVuxGrrEvqhlwH0kzR7C/H8zQ3jl47QcKcEL6Sr 385Du9OGl74ejTmiTx7JsRsRkeh20GH7zBTai+NuFvTgCDSymAVaEv07OWHqLBlCHDQnogWn/I q63tJJDj43pekmQ6a392119T/msCr020S5u8K187mVku0m2Zf6gEiBj3PDVR16tUIFWpgWj0lR jaE=
X-Amp-Result: SKIPPED(no attachment in message)
Received: from edge.swissre.com ([193.246.239.102]) by esa2.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 09 Mar 2020 10:08:28 +0000
Received: from CHRP5012.corp.gwpnet.com (10.53.3.187) by edge.swissre.com (193.246.239.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 11:08:27 +0100
Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5012.corp.gwpnet.com (10.53.3.187) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 11:08:25 +0100
Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Mon, 9 Mar 2020 11:08:25 +0100
From: Lee McGovern
To: Yaron Sheffer , "txauth@ietf.org"
Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG
Thread-Index: AQHV9PgjakXVRV1C5UOojMVg+gq+B6hACw4g
Date: Mon, 9 Mar 2020 10:08:24 +0000
Message-ID: <1f86898ed04543cb89388e56caaf946c@CHRP5009.corp.gwpnet.com>
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-03-09T10:08:23.9242824Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.62.28.9]
Content-Type: multipart/alternative; boundary="_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_"
MIME-Version: 1.0
X-GBS-PROC: 2hIY42bPeOGjeRR/kd6oj+Xv/zaQwqZdYfAi0AttK1Q=
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 09 Mar 2020 10:08:36 -0000
--_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
DQoxLiAgRG8geW91IHN1cHBvcnQgdGhlIGNoYXJ0ZXIgdGV4dCBwcm92aWRlZCBhdCB0aGUgZW5k
IG9mIHRoaXMgZW1haWw/ICBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25zLCBibG9ja2lu
ZyBjb25jZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/DQoNClllcw0K
DQoyLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2
ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQpZZXMNCg0KMy4gIEFyZSB5b3Ug
d2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQoNClllcw0KDQo0
LiAgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBXRz8N
Cg0KTm8NCg0KTGVlIE1jR292ZXJuIHwgSUFNIEFyY2hpdGVjdCB8IFZJQ0UgUFJFU0lERU5UIHwg
SW5mb3JtYXRpb24gVGVjaG5vbG9neQ0KU3dpc3MgUmUgTWFuYWdlbWVudCBMdGQgfCBNeXRoZW5x
dWFpIDUwLzYwLCA4MDIyIFpVUklDSCwgU1dJVFpFUkxBTkQNCkRpcmVjdDogKzQxIDQzIDI4NSA3
MCAxNyBGYXg6ICs0MSA0MyAyODIgNzAgMTcgRS1tYWlsOiBMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5j
b208bWFpbHRvOkxlZV9NY0dvdmVybkBzd2lzc3JlLmNvbT4NCg0KT24gRnJpLCBNYXIgNiwgMjAy
MCBhdCA1OjQ1IFBNIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86
eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBFdmVyeW9uZSwNCg0KSXQgYXBwZWFy
cyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRpb24g
b2YgYSBUeEF1dGggd29ya2luZyBncm91cC4gIFdl4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFsbHkg
Z2F1Z2UgaW50ZXJlc3QgaW4gcHJvY2VlZGluZyB3aXRoIHRoaXMgd29yay4gIFBsZWFzZSBkbyBz
byBieSByZXNwb25kaW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQoxLiAgRG8geW91
IHN1cHBvcnQgdGhlIGNoYXJ0ZXIgdGV4dCBwcm92aWRlZCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1h
aWw/ICBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25zLCBibG9ja2luZyBjb25jZXJucyBv
ciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/DQoNCjIuICBBcmUgeW91IHdpbGxp
bmcgdG8gYXV0aG9yIG9yIHBhcnRpY2lwYXRlIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJh
ZnRzIG9mIHRoaXMgV0c/DQoNCjMuICBBcmUgeW91IHdpbGxpbmcgdG8gaGVscCByZXZpZXcgdGhl
IGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQo0LiAgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGltcGxlbWVu
dGluZyBkcmFmdHMgb2YgdGhpcyBXRz8NCg0KVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVr
cywgdW50aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBi
ZSBhbWVuZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0
ZSB0aHJlYWQuDQoNClRoZSBmZWVkYmFjayBwcm92aWRlZCBoZXJlIHdpbGwgaGVscCB0aGUgSUVT
RyBjb21lIHRvIGEgZGVjaXNpb24gb24gdGhlIGZvcm1hdGlvbiBvZiBhIG5ldyBXRy4gR2l2ZW4g
dGhlIGNvbnN0cmFpbnRzIG9mIHRoZSBjaGFydGVyaW5nIHByb2Nlc3MsIHJlZ2FyZGxlc3Mgb2Yg
dGhlIG91dGNvbWUgb2YgdGhpcyBjb25zZW5zdXMgY2FsbCwgd2Ugd2lsbCBiZSBtZWV0aW5nIGlu
IFZhbmNvdXZlciBhcyBhIEJvRi4NCg0KVGhhbmtzLA0KWWFyb24gYW5kIERpY2sNCg0KLS0tIENo
YXJ0ZXIgVGV4dCBGb2xsb3dzIC0tLQ0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl
bG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24s
IGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1
dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhy
b3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNl
cyBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5l
Y3QgKGl0c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6
YXRpb25zIHNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlk
ZSBhIGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52
b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5k
ZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0
aW9ucy4NCg0KVGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVs
dGlwbGUgcGFydGllcyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmlj
IHJvbGUuIFRoZSBwcm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVs
cywgc3VjaCBhcyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24g
Y2hhbm5lbCwgd2hpY2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2gg
aXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dz
ZXIpLiBUaGUgY2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0
aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNo
YW5pc21zIGluZGljYXRlZCBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMg
bWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9m
IE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGlu
ZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCkFk
ZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCg0KLSBG
aW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCi0gQXBwcm92YWwgb2YgQVMgYXR0
ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xhaW1zDQotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0
aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMgaW4gYSBzaW5nbGUgaW50ZXJhY3Rpb24NCi0gU2VwYXJh
dGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBv
cGVyYXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzcw0KLSBBIHZhcmlldHkgb2YgY2xp
ZW50IGFwcGxpY2F0aW9ucywgaW5jbHVkaW5nIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5k
IGludGVyYWN0aW9uLWNvbnN0cmFpbmVkIGFwcGxpY2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2lsbCBk
ZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxl
eGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBm
b3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSBV
c2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRo
b2RzDQotIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0
aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlv
biBkZWNpc2lvbnMNCi0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3Vy
Y2Ugc2VydmVycyBhbmQgYmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFz
c29jaWF0ZWQgY3J5cHRvZ3JhcGhpYyBrZXlzDQotIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRk
aXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MgKGluY2x1
ZGluZyBpZGVudGl0eSkNCg0KQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1l
Y2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRp
bmc6DQoNCi0gRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcg0KLSBSZXZvY2F0
aW9uIG9mIGFjdGl2ZSB0b2tlbnMNCi0gUXVlcnkgb2YgdG9rZW4gcmlnaHRzIGJ5IHJlc291cmNl
IHNlcnZlcnMNCg0KQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3Qg
aW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0
aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxp
ZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3
IHByb3RvY29sIHdoZXJlIHBvc3NpYmxlLg0KDQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQg
dG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1
cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGli
bGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkgb24g
T0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBp
bmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrLXBvcnRlZCBmcm9tIHRoZSBwcm90b2NvbCBkZXZl
bG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuDQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2
ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2gg
YXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91cCBp
cyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy4NCg0K
VGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRp
b24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRha2lu
ZyBhZHZhbnRhZ2Ugb2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAyIGFuZCBIVFRQMyB3
aGVyZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUgbWFwcGluZyB0
byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29u
ZmxpY3Qgd2l0aCB0aGUgcHJpbWFyeSBmb2N1cy4NCg0KTWlsZXN0b25lcyB0byBpbmNsdWRlOg0K
IC0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sDQogLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlz
bSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNp
Z25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KIC0gSWRlbnRpdHkgYW5kIGF1
dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtcw0KIC0gR3VpZGVsaW5lcyBmb3IgdXNl
IG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHMNCg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlz
dA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KCgpUaGlzIGUtbWFpbCwgaW5jbHVkaW5n
IGF0dGFjaG1lbnRzLCBpcyBpbnRlbmRlZCBmb3IgdGhlIHBlcnNvbihzKSBvciBjb21wYW55IG5h
bWVkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbi4KClVuYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBv
ZiB0aGlzIGluZm9ybWF0aW9uIG1heSBiZSB1bmxhd2Z1bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYg
eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l
c3NhZ2UgYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpBbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUt
bWFpbCBtZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRoZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3Nh
Z2UgUmVwb3NpdG9yeS4KSWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50
aWFsbHkgcHJpdmF0ZSBlLW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91
IG5vdCB0byB1c2UgdGhlIFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwg
bm9uLWJ1c2luZXNzIHJlbGF0ZWQgY29tbXVuaWNhdGlvbnMuCg==
--_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVu
aWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u
b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iREUtQ0giIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiZuYnNwOyBEbyB5
b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBl
bWFpbD8mbmJzcDsgT3IgZG8geW91IGhhdmUgbWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcgY29u
Y2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBsZWFzZSBlbGFib3JhdGUpPzxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuJm5ic3A7IEFy
ZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50
IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0
OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiZuYnNwOyBBcmUgeW91IHdpbGxpbmcgdG8g
aGVscCByZXZpZXcgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuJm5ic3A7IEFyZSB5b3UgaW50
ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMgV0c/PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZjtjb2xvcjojNjg2
QUIwIj5MZWUgTWNHb3Zlcm48L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZjtjb2xvcjoj
ODI5QTkwIj4gfCBJQU0gQXJjaGl0ZWN0PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIFVuaWNvZGUgTVMmcXVvdDssc2VyaWY7
Y29sb3I6IzY4NkFCMCI+DQogfCBWSUNFIFBSRVNJREVOVDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBVbmljb2RlIE1TJnF1
b3Q7LHNlcmlmO2NvbG9yOiM4MjlBOTAiPiB8IEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8L3NwYW4+
PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM2ODZB
QjAiPlN3aXNzIFJlIE1hbmFnZW1lbnQgTHRkPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODI5
QTkwIj4gfCBNeXRoZW5xdWFpIDUwLzYwLCA4MDIyIFpVUklDSCwgU1dJVFpFUkxBTkQ8L3NwYW4+
PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM2ODZBQjAiPkRpcmVjdDogPC9zcGFuPjxzcGFuIHN0
eWxlPSJjb2xvcjojODI5QTkwIj4mIzQzOzQxIDQzIDI4NSA3MCAxNw0KPC9zcGFuPjxzcGFuIHN0
eWxlPSJjb2xvcjojNjg2QUIwIj5GYXg6IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgyOUE5
MCI+JiM0Mzs0MSA0MyAyODIgNzAgMTcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzY4NkFC
MCI+RS1tYWlsOiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MjlBOTAiPjxhIGhyZWY9Im1h
aWx0bzpMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojODI5QTkw
O3RleHQtZGVjb3JhdGlvbjpub25lIj5MZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb208L3NwYW4+PC9h
Pjwvc3Bhbj48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gRnJpLCBNYXIgNiwgMjAyMCBhdCA1OjQ1IFBNIFlhcm9uIFNoZWZmZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWls
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRXZlcnlvbmUsPGJyPg0KJm5ic3A7PGJyPg0KSXQgYXBw
ZWFycyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRp
b24gb2YgYSBUeEF1dGggd29ya2luZyBncm91cC4mbmJzcDsgV2XigJlkIGxpa2UgdG8gbW9yZSBm
b3JtYWxseSBnYXVnZSBpbnRlcmVzdCBpbiBwcm9jZWVkaW5nIHdpdGggdGhpcyB3b3JrLiZuYnNw
OyBQbGVhc2UgZG8gc28gYnkgcmVzcG9uZGluZyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8
YnI+DQombmJzcDs8YnI+DQoxLiZuYnNwOyBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0
IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8mbmJzcDsgT3IgZG8geW91IGhhdmUg
bWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcgY29uY2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBs
ZWFzZSBlbGFib3JhdGUpPzxicj4NCiZuYnNwOzxicj4NCjIuJm5ic3A7IEFyZSB5b3Ugd2lsbGlu
ZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50IG9mIHRoZSBkcmFm
dHMgb2YgdGhpcyBXRz88YnI+DQombmJzcDs8YnI+DQozLiZuYnNwOyBBcmUgeW91IHdpbGxpbmcg
dG8gaGVscCByZXZpZXcgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxicj4NCiZuYnNwOzxicj4NCjQu
Jm5ic3A7IEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMg
V0c/PGJyPg0KJm5ic3A7PGJyPg0KVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVrcywgdW50
aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBiZSBhbWVu
ZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0ZSB0aHJl
YWQuPGJyPg0KJm5ic3A7PGJyPg0KVGhlIGZlZWRiYWNrIHByb3ZpZGVkIGhlcmUgd2lsbCBoZWxw
IHRoZSBJRVNHIGNvbWUgdG8gYSBkZWNpc2lvbiBvbiB0aGUgZm9ybWF0aW9uIG9mIGEgbmV3IFdH
LiBHaXZlbiB0aGUgY29uc3RyYWludHMgb2YgdGhlIGNoYXJ0ZXJpbmcgcHJvY2VzcywgcmVnYXJk
bGVzcyBvZiB0aGUgb3V0Y29tZSBvZiB0aGlzIGNvbnNlbnN1cyBjYWxsLCB3ZSB3aWxsIGJlIG1l
ZXRpbmcgaW4gVmFuY291dmVyIGFzIGEgQm9GLjxicj4NCiZuYnNwOzxicj4NClRoYW5rcyw8YnI+
DQpZYXJvbiBhbmQgRGljazxicj4NCiZuYnNwOzxicj4NCi0tLSBDaGFydGVyIFRleHQgRm9sbG93
cyAtLS08YnI+DQo8YnI+DQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmlu
ZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5
LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5n
IHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBh
dXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcw0KIGNhc2Vz
IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRz
ZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMg
c2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCBwcm92aWRlIGEgY2xl
YXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBp
biB0aGUgcHJvdG9jb2wgZmxvdywgYW5kDQogcmVtb3ZlIHVubmVjZXNzYXJ5IGRlcGVuZGVuY2Ug
b24gYSBicm93c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMu
DQo8YnI+DQo8YnI+DQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBi
eSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3Bl
Y2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uIGNo
YW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUgZGVsZWdh
dGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4NCiB0aGUgY2xpZW50
IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGluIGNvbnRyYXN0IHdpdGggT0F1dGggMi4w
IHdoaWNoIGlzIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZ
cyBicm93c2VyKS4gVGhlIGNsaWVudCBhbmQgQVMgd2lsbCBpbnZvbHZlIGEgdXNlciB0byBtYWtl
IGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24gYXMgbmVjZXNzYXJ5IHRocm91Z2ggaW50ZXJhY3Rp
b24gbWVjaGFuaXNtcyBpbmRpY2F0ZWQNCiBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGlu
ZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFs
bGVuZ2VzIG9mIE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Ig
c3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5l
bHMuPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwg
YWxsb3cgZm9yOjxicj4NCjxicj4NCi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgYWNj
ZXNzPGJyPg0KLSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0eSBjbGFpbXM8
YnI+DQotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMg
aW4gYSBzaW5nbGUgaW50ZXJhY3Rpb248YnI+DQotIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcGFy
dHkgYXV0aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGllbnQg
cmVxdWVzdGluZyBhY2Nlc3M8YnI+DQotIEEgdmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRpb25z
LCBpbmNsdWRpbmcgV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29u
c3RyYWluZWQgYXBwbGljYXRpb25zPGJyPg0KPGJyPg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4
dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5
IGluIGFyZWFzIGluY2x1ZGluZzo8YnI+DQo8YnI+DQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBm
b3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiA8YnI+
DQotIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2Vi
IG1ldGhvZHM8YnI+DQotIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwg
b3JnYW5pemF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0
aG9yaXphdGlvbiBkZWNpc2lvbnM8YnI+DQotIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9r
ZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8g
dG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5czxicj4NCi0gT3B0aW1pemVk
IGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGRlbGVnYXRp
b24gcHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aXR5KTxicj4NCjxicj4NCkFkZGl0aW9uYWxseSwg
dGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBw
cm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxicj4NCjxicj4NCi0gRGlzY292ZXJ5IG9mIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlcjxicj4NCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5z
PGJyPg0KLSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxicj4NCjxi
cj4NCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVk
IG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9y
IE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3Jh
dGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlIG5ldyBwcm90b2Nv
bCB3aGVyZSBwb3NzaWJsZS48YnI+DQo8YnI+DQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQg
dG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1
cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGli
bGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkgb24g
T0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBp
bmNsdWRpbmcNCiBmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRl
dmVsb3BlZCBoZXJlIHRvIE9BdXRoIDIuMC48YnI+DQo8YnI+DQpUaGUgZ3JvdXAgaXMgY2hhcnRl
cmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYyBtZXRo
b2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRo
aXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9ncmFwaGljIG1l
dGhvZHMuDQo8YnI+DQo8YnI+DQpUaGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcg
SFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMg
b2YgSFRUUDIgYW5kIEhUVFAzIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5h
YmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVANCiB3aGVu
IGRvaW5nIHNvIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuPGJyPg0K
PGJyPg0KTWlsZXN0b25lcyB0byBpbmNsdWRlOjxicj4NCiZuYnNwOy0gQ29yZSBkZWxlZ2F0aW9u
IHByb3RvY29sPGJyPg0KJm5ic3A7LSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5n
cyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwg
YW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlczxicj4NCiZuYnNwOy0gSWRlbnRpdHkgYW5kIGF1
dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtczxicj4NCiZuYnNwOy0gR3VpZGVsaW5l
cyBmb3IgdXNlIG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHM8YnI+DQo8YnI+DQo8YnI+DQot
LSA8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj48ZGl2PlRo
aXMgZS1tYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUgcGVy
c29uKHMpIG9yIGNvbXBhbnkgbmFtZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQv
b3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLjwvZGl2PlVuYXV0aG9yaXplZCBkaXNj
bG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIG1heSBiZSB1bmxhd2Z1
bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu
dCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj5B
bGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUtbWFpbCBtZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRo
ZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3NhZ2UgUmVwb3NpdG9yeS48YnI+SWYgeW91IGRvIG5v
dCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50aWFsbHkgcHJpdmF0ZSBlLW1haWxzIGJ5IFN3
aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91IG5vdCB0byB1c2UgdGhlIFN3aXNzIFJlIGUt
bWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwgbm9uLWJ1c2luZXNzIHJlbGF0ZWQgY29tbXVu
aWNhdGlvbnMuPC9ib2R5Pg0KPC9odG1sPg0K
--_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_--
From nobody Mon Mar 9 20:49:46 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920B3A0EC5 for ; Mon, 9 Mar 2020 20:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fusionauth.io
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 vf60uyQAouBE for ; Mon, 9 Mar 2020 20:49:37 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487BA3A0ECE for ; Mon, 9 Mar 2020 20:49:27 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id u12so8303251ljo.2 for ; Mon, 09 Mar 2020 20:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fusionauth.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=Bt3jRDsN+DDXpvhZkuvBEd9HdK5GJXuzln+h9NvTpxgGD8mEply7oAp942+fuX+MdA Bp6VVAmxMc8LmAzfzhjXopu2bQCnI6UdthstUKXoyh9suNCDLmUPhYml1A4ebpue3x55 emKZVQ4JDUf6A+rpzdP/4cPlKWSasPfN8n5mgKMe2ufBfH21f3mQ4wO0b8DbpE8SLUwt NHl2lMELfoUGq78+SsIsZq8B/JZKaaA0lRF13ngFViUd15qdimrgpn7M52o/A2McjoWJ GnpfQispW8gJ0pDpGj3E2kDZXIaaJZdNnUx1/Yo/XvRw27Pkm7aVUP+HBW6QDU2Rcp63 XSDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=byTu/Y5T69z8Le/JjWT9VL1sNkz/dHOLWgNimEfSJTCpGOXRD5Vgjx4SAYT0Q6YMUb 9jjZAfI1M4ByJu5k5YXLQWyQKxX8n/p/AkpYcIGz523O+mNwqNGKJwRYIsydap+HwhxF yHN1g9cMqNDxSP8J1rxw9kswi/BBmU9LSkHy69L/8qzT2C0uma0kwwgNyPeazokmGvUH ZMgZR834JpHYb5Cmus7bPc0k3R0fqVz4fDaWjha9JVa1q8HtPIq7Gcxaput//d/rZsz4 WGC1YSzBo85cOSBKj+zz4AX2tOP3FmQqa5mOsNYnjSyhV9kWhPvhJTGaUDToD/JtDJsC wbOQ==
X-Gm-Message-State: ANhLgQ0dmpR69CpQWYIRfnc2tSfNAkRKODFECNOskaHg2GsGuU1DfEwT j3H3g8x+urXYy6XRQTJ+i6qRV2Rj4aMB6riqR3LXzQ==
X-Google-Smtp-Source: ADFU+vtyyFfCrtqYLyWwbaD7qtvH9deGY2NvXoIrO/9eZ0mCRlcUXLPq7hbdNYSC1ysEAu4dJCAzh8uAoNUPvpF2HSo=
X-Received: by 2002:a2e:a419:: with SMTP id p25mr1504579ljn.206.1583812159918; Mon, 09 Mar 2020 20:49:19 -0700 (PDT)
MIME-Version: 1.0
References:
In-Reply-To:
From: Daniel DeGroff
Date: Mon, 9 Mar 2020 21:49:08 -0600
Message-ID:
To: Yaron Sheffer
Cc: "txauth@ietf.org"
Content-Type: multipart/alternative; boundary="0000000000002ee8be05a07801f0"
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 10 Mar 2020 03:49:45 -0000
--0000000000002ee8be05a07801f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
> 1. Do you support the charter text provided at the end of this email?
Or do you have major objections, blocking concerns or feedback (if so
please elaborate)?
Yes
> 2. Are you willing to author or participate in the development of the
drafts of this WG?
Yes
> 3. Are you willing to help review the drafts of this WG?
Yes
> 4. Are you interested in implementing drafts of this WG?
Yes
Daniel
daniel@fusionauth.io
On Fri, Mar 6, 2020 at 9:45 AM Yaron Sheffer wrote:
> Hi Everyone,
>
> It appears that momentum is forming around the proposed formation of a
> TxAuth working group. We=E2=80=99d like to more formally gauge interest =
in
> proceeding with this work. Please do so by responding to the following
> questions:
>
> 1. Do you support the charter text provided at the end of this email? O=
r
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
>
> 2. Are you willing to author or participate in the development of the
> drafts of this WG?
>
> 3. Are you willing to help review the drafts of this WG?
>
> 4. Are you interested in implementing drafts of this WG?
>
> The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separat=
e
> thread.
>
> The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
>
> Thanks,
> Yaron and Dick
>
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. It will expand upon the uses cases currently
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
> 2.0) to support authorizations scoped as narrowly as a single transaction=
,
> provide a clear framework for interaction among all parties involved in t=
he
> protocol flow, and remove unnecessary dependence on a browser or user-age=
nt
> for coordinating interactions.
>
> The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user=E2=80=99s browser, from the de=
legation
> channel, which happens directly between the client and the authorization
> server (in contrast with OAuth 2.0 which is initiated by the client
> redirecting the user=E2=80=99s browser). The client and AS will involve a=
user to
> make an authorization decision as necessary through interaction mechanism=
s
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasiv=
e
> path for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single interacti=
on
> - Separation between the party authorizing access and the party operating
> the client requesting access
> - A variety of client applications, including Web, mobile, single-page,
> and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of
> possession
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pieces
> of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation
> process (including identity)
>
> Additionally, the group will provide mechanisms for management of the
> protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne=
w
> protocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back-ported
> from the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
--0000000000002ee8be05a07801f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
=
> 1.=C2=
=A0 Do you support the charter text provided at the end of this email?=C2=
=A0 Or do you have major objections, blocking concerns or feedback (if so p=
lease elaborate)?
Yes
> 2.=C2=A0 Are you willing to author or participat=
e in the development of the drafts of this WG?
Yes
> 3.=C2=A0 Are you wi=
lling to help review the drafts of this WG?
Yes
> 4.=C2=A0 Are you inter=
ested in implementing drafts of this WG?
Yes
Daniel=C2=A0
Hi Everyone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu=
th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i=
n proceeding with this work.=C2=A0 Please do so by responding to the follow=
ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?=
=C2=A0 Or do you have major objections, blocking concerns or feedback (if s=
o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the=
drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char=
ter should be amended In a significant way, please reply on a separate thre=
ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for=
mation of a new WG. Given the constraints of the chartering process, regard=
less of the outcome of this consensus call, we will be meeting in Vancouver=
as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---
This group is chartered to develop a fine-grained delegation protocol for a=
uthorization, identity, and API access. This protocol will allow an authori=
zing party to delegate access to client software through an authorization s=
erver. It will expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat=
ions scoped as narrowly as a single transaction, provide a clear framework =
for interaction among all parties involved in the protocol flow, and remove=
unnecessary dependence on a browser or user-agent for coordinating interac=
tions.
The delegation process will be acted upon by multiple parties in the protoc=
ol, each performing a specific role. The protocol will decouple the interac=
tion channels, such as the end user=E2=80=99s browser, from the delegation =
channel, which happens directly between the client and the authorization se=
rver (in contrast with OAuth 2.0 which is initiated by the client redirecti=
ng the user=E2=80=99s browser). The client and AS will involve a user to ma=
ke an authorization decision as necessary through interaction mechanisms in=
dicated by the protocol. This decoupling avoids many of the security concer=
ns and technical challenges of OAuth 2.0 and provides a non-invasive path f=
or supporting future types of clients and interaction channels.
Additionally, the delegation process will allow for:
- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t=
he client requesting access
- A variety of client applications, including Web, mobile, single-page, and=
interaction-constrained applications
The group will define extension points for this protocol to allow for flexi=
bility in areas including:
- Cryptographic agility for keys, message signatures, and proof of possessi=
on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o=
f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource=
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc=
ess (including identity)
Additionally, the group will provide mechanisms for management of the proto=
col lifecycle including:
- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers
Although the artifacts for this work are not intended or expected to be bac=
kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt =
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol=
where possible.
This group is not chartered to develop extensions to OAuth 2.0, and as such=
will focus on new technological solutions not necessarily compatible with =
OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope=
d in the OAuth Working Group, including functionality back-ported from the =
protocol developed here to OAuth 2.0.
The group is chartered to develop mechanisms for applying cryptographic met=
hods, such as JOSE and COSE, to the delegation process. This group is not c=
hartered to develop new cryptographic methods.
The initial work will focus on using HTTP for communication between the cli=
ent and the authorization server, taking advantage of optimization features=
of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin=
g to other protocols such as COAP when doing so does not conflict with the =
primary focus.
Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d=
etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--0000000000002ee8be05a07801f0--
From nobody Tue Mar 10 06:47:42 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB53A0F58 for ; Tue, 10 Mar 2020 06:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SM6AVBp7Tea5 for ; Tue, 10 Mar 2020 06:47:38 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E94B23A0F53 for ; Tue, 10 Mar 2020 06:47:37 -0700 (PDT)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02ADlZgC006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 09:47:35 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer
In-Reply-To:
Date: Tue, 10 Mar 2020 09:47:35 -0400
Cc: "txauth@ietf.org"
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: Yaron Sheffer
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At:
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 10 Mar 2020 13:47:40 -0000
On Mar 6, 2020, at 11:44 AM, Yaron Sheffer =
wrote:
>=20
> Hi Everyone,
> =20
> It appears that momentum is forming around the proposed formation of a =
TxAuth working group. We=E2=80=99d like to more formally gauge interest =
in proceeding with this work. Please do so by responding to the =
following questions:
> =20
> 1. Do you support the charter text provided at the end of this email? =
Or do you have major objections, blocking concerns or feedback (if so =
please elaborate)?
Yes.
> =20
> 2. Are you willing to author or participate in the development of the =
drafts of this WG?
Yes, and I am volunteering to edit.
> =20
> 3. Are you willing to help review the drafts of this WG?
Yes.
> =20
> 4. Are you interested in implementing drafts of this WG?
Yes, and I have implemented one of the input drafts.
> =20
> The call will run for two weeks, until March 21. If you think that the =
charter should be amended In a significant way, please reply on a =
separate thread.
> =20
> The feedback provided here will help the IESG come to a decision on =
the formation of a new WG. Given the constraints of the chartering =
process, regardless of the outcome of this consensus call, we will be =
meeting in Vancouver as a BoF.
> =20
> Thanks,
> Yaron and Dick
> =20
> --- Charter Text Follows ---
>=20
> This group is chartered to develop a fine-grained delegation protocol =
for authorization, identity, and API access. This protocol will allow an =
authorizing party to delegate access to client software through an =
authorization server. It will expand upon the uses cases currently =
supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth =
2.0) to support authorizations scoped as narrowly as a single =
transaction, provide a clear framework for interaction among all parties =
involved in the protocol flow, and remove unnecessary dependence on a =
browser or user-agent for coordinating interactions.=20
>=20
> The delegation process will be acted upon by multiple parties in the =
protocol, each performing a specific role. The protocol will decouple =
the interaction channels, such as the end user=E2=80=99s browser, from =
the delegation channel, which happens directly between the client and =
the authorization server (in contrast with OAuth 2.0 which is initiated =
by the client redirecting the user=E2=80=99s browser). The client and AS =
will involve a user to make an authorization decision as necessary =
through interaction mechanisms indicated by the protocol. This =
decoupling avoids many of the security concerns and technical challenges =
of OAuth 2.0 and provides a non-invasive path for supporting future =
types of clients and interaction channels.
>=20
> Additionally, the delegation process will allow for:
>=20
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single =
interaction
> - Separation between the party authorizing access and the party =
operating the client requesting access
> - A variety of client applications, including Web, mobile, =
single-page, and interaction-constrained applications
>=20
> The group will define extension points for this protocol to allow for =
flexibility in areas including:
>=20
> - Cryptographic agility for keys, message signatures, and proof of =
possession=20
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other =
pieces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding =
resource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation =
process (including identity)
>=20
> Additionally, the group will provide mechanisms for management of the =
protocol lifecycle including:
>=20
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>=20
> Although the artifacts for this work are not intended or expected to =
be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will =
attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the =
new protocol where possible.
>=20
> This group is not chartered to develop extensions to OAuth 2.0, and as =
such will focus on new technological solutions not necessarily =
compatible with OAuth 2.0. Functionality that builds directly on OAuth =
2.0 will be developed in the OAuth Working Group, including =
functionality back-ported from the protocol developed here to OAuth 2.0.
>=20
> The group is chartered to develop mechanisms for applying =
cryptographic methods, such as JOSE and COSE, to the delegation process. =
This group is not chartered to develop new cryptographic methods.=20
>=20
> The initial work will focus on using HTTP for communication between =
the client and the authorization server, taking advantage of =
optimization features of HTTP2 and HTTP3 where possible, and will strive =
to enable simple mapping to other protocols such as COAP when doing so =
does not conflict with the primary focus.
>=20
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, =
detached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
From nobody Tue Mar 10 06:58:58 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B13A133D for ; Tue, 10 Mar 2020 06:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 Z35mWz5B4oD2 for ; Tue, 10 Mar 2020 06:58:44 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 518F63A133B for ; Tue, 10 Mar 2020 06:58:30 -0700 (PDT)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02ADwR5d010553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 09:58:28 -0400
From: Justin Richer
Message-Id: <476DCE51-67E9-4C25-9B00-2B1D994138A5@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Mar 2020 09:58:27 -0400
In-Reply-To:
Cc: txauth@ietf.org
To: Dick Hardt
References: <158363691397.25530.3652753138946434165@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At:
Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-05.txt
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 10 Mar 2020 13:58:55 -0000
--Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
The interaction structure mimics the two return styles in XYZ (which are =
switched on whether you provide a =E2=80=9Ccallback=E2=80=9D structure =
or not) but still doesn=E2=80=99t allow the client to specify different =
interaction mechanisms. It seems that now the GS needs to guess what the =
client is capable of. To me, one of our greatest opportunities here is =
moving away from the assumptions of web-based interaction. I believe we =
need to account for this in a way that=E2=80=99s more flexible than a =
single-type system.=20
If I have a client app that could get the user to you in a browser or =
send you VC=E2=80=99s directly, I should be able to tell you that =
upfront and have the AS respond to any and all actions that it can do.
=E2=80=94 Justin
> On Mar 7, 2020, at 10:16 PM, Dick Hardt wrote:
>=20
> Please forgive, and point out inconsistencies! If anything is =
confusing, please let me know. It is likely a mistake on my part!
> I'm proposing there are only 2 types of interactions defined: a =
redirect interaction where the Client can redirect to the GS, and the GS =
back to the Client; or an indirect interaction where the User somehow =
gets to the GS, and there is no redirect back to the Client. The =
security characteristics are different, as session fixation can be =
prevented if the GS redirects back to the Client as the Client is able =
to verify the User it is interacting with is the same as the User the GS =
is interacting with.=20
> I added a sequence where the Client does a PATCH on the Grant URI with =
an interaction nonce received from the GS in the redirect back to the =
Client to protect against fixation attacks.
> The Authorization lifecycle and management is now independent of the =
Grant. A Client now receives an access token, OR an AuthZ URI. Reading =
and refreshing an access token are the same thing.=20
> A more complete list of changes is below:
> draft-hardt-xauth-protocol-05
> separated claims from identifiers in request user object =
> simplified reciprocal grant flow =
> reduced interactions to redirect and indirect =
> simplified interaction parameters =
> added in language for Client to verify interaction completion =
> added Verify Grant API and Interaction Nonce =
> replaced Refresh AuthZ with Read AuthZ.. Read and refresh are same =
operation.
>=20
> ---------- Forwarded message ---------
> From: >
> Date: Sat, Mar 7, 2020 at 7:08 PM
> Subject: New Version Notification for =
draft-hardt-xauth-protocol-05.txt
> To: Dick Hardt >
>=20
>=20
>=20
> A new version of I-D, draft-hardt-xauth-protocol-05.txt
> has been successfully submitted by Dick Hardt and posted to the
> IETF repository.
>=20
> Name: draft-hardt-xauth-protocol
> Revision: 05
> Title: The XAuth Protocol
> Document date: 2020-03-07
> Group: Individual Submission
> Pages: 59
> URL: =
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt =
> Status: =
https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ =
> Htmlized: =
https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 =
> Htmlized: =
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol =
> Diff: =
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-05 =
>=20
> Abstract:
> Client software often desires resources or identity claims that are
> independent of the client. This protocol allows a user and/or
> resource owner to delegate resource authorization and/or release of
> identity claims to a server. Client software can then request =
access
> to resources and/or identity claims by calling the server. The
> server acquires consent and authorization from the user and/or
> resource owner if required, and then returns to the client software
> the authorization and identity claims that were approved. This
> protocol can be extended to support alternative authorizations,
> claims, interactions, and client authentication mechanisms.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org =
.
>=20
> The IETF Secretariat
>=20
>=20
> =E1=90=A7
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
The =
interaction structure mimics the two return styles in XYZ (which are =
switched on whether you provide a =E2=80=9Ccallback=E2=80=9D structure =
or not) but still doesn=E2=80=99t allow the client to specify different =
interaction mechanisms. It seems that now the GS needs to guess what the =
client is capable of. To me, one of our greatest opportunities here is =
moving away from the assumptions of web-based interaction. I believe we =
need to account for this in a way that=E2=80=99s more flexible than a =
single-type system.
If I have a client app that could get the user to you in a =
browser or send you VC=E2=80=99s directly, I should be able to tell you =
that upfront and have the AS respond to any and all actions that it can =
do.
=E2=80=
=94 Justin
Please forgive, and point out inconsistencies! If =
anything is confusing, please let me know. It is likely a mistake =
on my part!
- I'm proposing there are only 2 types of interactions defined: =
a redirect interaction where the Client can redirect to the GS, and the =
GS back to the Client; or an indirect interaction where the User somehow =
gets to the GS, and there is no redirect back to the Client. The =
security characteristics are different, as session fixation can be =
prevented if the GS redirects back to the Client as the Client is able =
to verify the User it is interacting with is the same as the User the GS =
is interacting with.
- I added a sequence where the Client does a PATCH on =
the Grant URI with an interaction nonce received from the GS in the =
redirect back to the Client to protect against fixation =
attacks.
- The Authorization lifecycle and management is now =
independent of the Grant. A Client now receives an access token, OR an =
AuthZ URI. Reading and refreshing an access token are the same =
thing.
A more complete list of changes is =
below:
draft-hardt-xauth-protocol-05
- separated claims from identifiers in request user object
- simplified reciprocal grant flow
- reduced interactions to redirect and indirect
- simplified interaction parameters
- added in language for Client to verify interaction =
completion
- added Verify Grant API and Interaction Nonce
- replaced Refresh AuthZ with Read AuthZ.. Read and =
refresh are same operation.
=E1=90=A7
--
Txauth mailing list
Txauth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth
=
--Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16--
From nobody Tue Mar 10 07:12:06 2020
Return-Path:
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2A3A0FDE for ; Tue, 10 Mar 2020 07:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ReJhyEvZ_dqL for ; Tue, 10 Mar 2020 07:12:02 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9FFAD3A0865 for ; Tue, 10 Mar 2020 07:12:02 -0700 (PDT)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02AEBx9t015875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 10:12:00 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer
In-Reply-To:
Date: Tue, 10 Mar 2020 10:11:59 -0400
Cc: txauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <72806D82-664F-464A-B682-8F2E6F1AF616@mit.edu>
References:
To: Vijay IETF
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At:
Subject: Re: [Txauth] XAuth vs AuthZ vs ...
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id:
List-Unsubscribe: ,
List-Archive: