Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D4966E2FB5DC for ; Sat, 25 Apr 2026 07:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777127700; bh=wbE6GVDiqMsV9Ncb5ggGfiwdIbrMTjfvGgPAhBtsVgw=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=KUpGb2iOLEQKtIMuSZNZph9yA/ORg+jhjEb7LeLT/8qhMqwEC4A/JotV2H6ymoeBF dZtTmnfGLrvoRlKnti9zBHbQO2ciMJevRGNDEkk+C5HEjSEacgqBPEPfXaVXQbIB0I p4UQCYWyIexrZRhlW+9z6msAZBo4RvPrOFzTqUpM= X-Virus-Scanned: amavisd-new at ietf.org 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiC6_P3hQupq for ; Sat, 25 Apr 2026 07:35:00 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 006D6E2FB5CD for ; Sat, 25 Apr 2026 07:34:59 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5a62a049c1fso6029408e87.3 for ; Sat, 25 Apr 2026 07:34:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777127699; cv=none; d=google.com; s=arc-20240605; b=U6JUeY4OAylBM41zRZDiAN0MqyV8L1Tf0PIn1D+4d7Q0zT0UuZavA/OrbfRHrq2HPJ /NgF3aaQa7HplpXL918fjr4svsFF2yM47rUpj1WfuZRocgGxo9UmOpzh5XjkvvpwRdtn Z92TKmVMZhvzQoYtchM0xAbBu/TC25xbDVr10eTkyMQuPH8lsPXow2rdY6PC+3owgYKd u/8F5xwZ5wRpcLpqBTN8Ol1GZC/GvnfdTqmmBabglVGgUpugpzMi68kk0h0pgNaxf2lr 18/y+Zn727nefqAISLSerz6vHm4tuOX0S1qHV+46LB14dDAPA1NELwvuKM9BHXhsuu5C caiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=njk1/oxrv4a79JVuDAJz5FE/paaH/xqch4uIb4jTtas=; fh=P+nKllo/JihWfgLYquSFzcJSo9gMon8bVKzsCG/4zIM=; b=dLDD8DJJphp7v8Nd7f3gVlL3p9TPmF5zdgTQr8tZZkW1dKOcGmsK7t/bBNlYIjzRT7 oNwfoiD97slM3OR/92dXiYbu1YfCAxsBvlMXXZ2WJl+eH7NwcHdEQpL+78h76xYFFKDW XjnkVfpc3cNtbwdLGZsXdhjKCafMD5GlJFWSn/wsginjcsElH4SjhUJtHeZwhYd8kVKF ZPuvsvAs31pmORxp3hNduC0l3805n7u6StHNLs7Mh+aHUcawZLV+w0nlhzk9cEVJ7vqk QoOLihj/XyUAKlol3ABp9TeI6M7lPIKHKh3276lBmh0geQDeK6FNp1SHf/ciEfSWtj9K wFlQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777127699; x=1777732499; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=njk1/oxrv4a79JVuDAJz5FE/paaH/xqch4uIb4jTtas=; b=OUs4FmjzRUS0I3jnjAlb+8hDWJqxv2V/m1OBpZnC1qsbfGLHslHuWGnr+93CctSghI loBfbnBQ02dfjsdoMJOYf9a+8NtrrZXWCNrqlkQ3zpYMP4cI5ig4SRvBXuiPLjsbsHzy FIpTCpJD2mBUjIszJE9i5zY0TogOCNYzAiQwd4HVx8fOW7IPdU6r26S7Dv0dLxDnDHOm aokgKzMT7R61abv+IdGdm2tc2dihD38KXo8oTrOrYJUYWeG4mNze29IPUK/vQNlNnE8g yLA6jOlG2kROPophAaqiwYv8zrM8MQEuIW1ErJRrfpuBveQsMONlBHpSDNPi9gO4sFyB PcFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777127699; x=1777732499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=njk1/oxrv4a79JVuDAJz5FE/paaH/xqch4uIb4jTtas=; b=r030mxmJCib6W+Jao/2GzjHey1vQ4dbQ282K+mfkb/H4SEfl/RpppWTAxNZHd1FabW AifxRtOgHEDy91G4JTaT/fDs9tXDzC3zbVRwfJ7hGQaAvoL/ER0OgCjTz9JYvekWYyD0 TMObBCdkqXPdK9FeleTLI5OboeijH8TsfFRBTV10ZP+JUcPsGSnXZyGnXMJC/33wM719 tW44Jz/4OMP71oly9KnRfkgH++usYwMtmmqENFgj48ngC96SSW+DHzEB2AYwciK3iOMw ZaaE3qSlH/BJeBFPBgeC5+3JvBZ3s3JzTYztW8SF3wojp0ma+SFel9J5RP57dEuJsO4g coQg== X-Forwarded-Encrypted: i=1; AFNElJ9EjdtIW6lsx1Q7fq0WeCdL/3AdW1cg22tX1FnXQ5ZboT0mz5YKHNhKg4rLgvk0oTYJ24ZXog==@ietf.org X-Gm-Message-State: AOJu0YyVwl9QZuSeqTzMGu4sZnTGxkhGb5fJvxfK1A3vSToKX6r0uwhe oM3eElNIezsnDcGOG8yUXatRd//6beGxyDyAuefGEFltlSK+IhIA17fDdKzGxRzi6s1yi1/FPyP /S6vWq3HCXH5+TrLEev9QS6UcE7xOha5+BquB X-Gm-Gg: AeBDieuI3O24fyrJW1LPKUfyH9OklgetJnbLpaVVRRm6PMQV7pfGhbGayVNz81HKD/X 1bPu5u3vZ140MsWMJ/7841AKFbfHcmoiecOLOe/QruAlvbWKwDFxb7o9c+d49tBB57DLcH7GJgC 3I/1RQ3cx/EgLySYJUD/RwYk7K8jz6SZAOBtnHueLZ4PkTKk9YxfiFh2rAo+GWuptetq3E302q8 xo5TgMMpto43/7AAjnVLmsLYNzByDuxv3+YtRROn5IauE0vwzYS+Dg3nhMzUvJnzDO2Uh80W06s FGkQiUe+WIE2E1UVg4B31+cGPi/OROrTXFwK8KLYUqgnAMc/QNYmm2zxjQbfiZN23R8kH1I/dTs 3Z6va0/hibwMskTF2gm92yafU/dJDuibFibrOXA== X-Received: by 2002:a05:6512:3510:b0:5a4:194f:5fff with SMTP id 2adb3069b0e04-5a4194f60edmr8792932e87.16.1777127698447; Sat, 25 Apr 2026 07:34:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sat, 25 Apr 2026 10:34:47 -0400 X-Gm-Features: AVHnY4LURBK8V9qdOISEQGLWKJ-7uwbHd4IKh38iJOFcq_9-bbY2V-KqYsPkadI Message-ID: To: Deb Cooley Content-Type: multipart/alternative; boundary="0000000000002fc2aa065049c9a2" Message-ID-Hash: 4NFN7OTG72M5DBQBUMU2C3YN4LSGB3LO X-Message-ID-Hash: 4NFN7OTG72M5DBQBUMU2C3YN4LSGB3LO X-MailFrom: rifaat.s.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-oauth-identity-chaining.authors@ietf.org, Web Authorization Protocol Working Group , oauth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_AD_comments_on_draft-ietf-oauth-identity-chai?= =?utf-8?q?ning?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002fc2aa065049c9a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 25, 2026 at 9:31=E2=80=AFAM Deb Cooley w= rote: > These all look good to me. I'm going to submit it to IETF Last Call. > > Adding Aaron as an author is fine as well. I will need Rifaat to update > the shepherd review to provide at least a little bit of rationale for 6 > authors. > Done Regards, Rifaat > > Other comments/confessions? in line with [DC] > > Deb > > On Fri, Apr 24, 2026 at 12:11=E2=80=AFPM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Thank you for the review and it's now my turn to apologize for the delay >> (can I blame IETF 125 at this point? probably not...). Some specific >> responses are inline below but I don't think you'll find anything >> surprising or controversial. This issue >> https://github.com/oauth-wg/oauth-identity-chaining/issues/182 and this >> PR https://github.com/oauth-wg/oauth-identity-chaining/pull/183 kinda >> show our work here and the responses below are taken from the issue and >> specific commits mentioned are part of that PR. A new draft incorporatin= g >> all this will be forthcoming soon. >> >> >> On Wed, Apr 8, 2026 at 6:57=E2=80=AFAM Deb Cooley = wrote: >> >>> Thank you for your work on this specification, here are my comments on >>> this draft. Apologies for the delay (IETF 125 and recovery from the sa= me >>> takes time). I don't think any of these comments are especially diffic= ult, >>> most are process related: >>> >>> Deb >>> Sec AD >>> >>> --------------------------------------- >>> General: Consider using *.*.example.org for example domains (currently >>> this draft uses as.*.org). See: >>> https://authors.ietf.org/example-addresses for more information. >>> >> >> Yup, will do in 3c777e3 >> >> and 886cbc6 >> >> > [DC] certainly the change results in a 'non-routable' domain, but conside= r > adding '.org' to the end. This can wait for later, and possibly for > someone else commenting on it. > >> >> >> >>> Long line: Line 416, is 75 characters long, according to idnits >>> (experimental). I did not go looking for this (which is why I've put i= t up >>> front). >>> >> >> will split the 1 instance of too long line >> >> >> >> >>> Section 2.1, Appendix B: Using steps (A), (B), (C) could be confusing >>> in light of the pre-existing domain enumerations of Domain A, Domain B. >>> I'd suggest using some other enumeration for the steps, maybe (1), (2),= (3) >>> to disambiguate. >>> >> >> Makes good sense 7a90229 >> >> >> >> Section 2.2: Since this 'MAY' does not enable/disable interoperability >>> (the goal of BCP 14), consider changing it to 'may' or even 'could'. >>> >> >> Happy to do that one cf9e53f >> >> >> >> >>> Section 2.3, bullet 1: 'MUST deny' or 'MUST NOT approve'? Which will >>> be more obvious to the implementer? >>> >> >> In bullet 1 or 2.3[.2?], deny seems more obvious to me and I was an >> implementer at one point long ago in this so called career. >> >> [DC] this is fine. > >> >> >>> >>> Section 2.4.3: There is an assumption here that the previous >>> rules/steps/checks have been validated without error. Perhaps consider >>> adding a phrase like, 'When the authorization grant has been validated, >>> the....' >>> >> >> Yup, added When the authorization grant has been validated, the... >> >> >> >> >>> Section 5: BCP14 language or not? Please see: >>> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying= -the-use-of-bcp-14-key-words/ >>> . While BCP 14 words in Security Considerations is completely appropria= te, >>> it should still be used sparingly. The word 'must' is just as normativ= e as >>> 'MUST', but carries less baggage. I would suggest going back through >>> Section 5, and consider which of the BCP 14 words are there for >>> 'interoperability' or to 'prevent harm'. Please pay special attention = to >>> section on 'SHOULD' and 'RECOMMENDED'. I'm making some comments within >>> Section 5 to emphasize my point of view. >>> >>> Section 5.1: Naked 'SHOULD's need to have a 'what are the consequences >>> of violating the should' that goes with it. An alternative is to state >>> under what reasonable circumstances the should isn't possible (maybe th= at >>> is the public client part of this section?). >>> >>> Section 5.4: I'm guessing that there was confusion at some point about >>> issuance of refresh tokens by AS domain A to clients in domain A? My >>> suggestion to make this a tiny bit clearer in para 1 is to add 'domain = A' >>> when you mention 'client' -> 'client in domain A'. It does make it wor= dier >>> and longer, but way more obvious that the refresh tokens across domains= are >>> the issue. >>> >>> Section 5.4: It is also not clear why one might choose to violate the >>> sequence of 'SHOULD NOT', 'SHOULD', 'SHOULD'... Why not 'MUST NOT', >>> 'MUST', 'MUST'? Sadly, RFC 7521 doesn't specify why/when 'SHOULD NOT' >>> could be ignored (unless I read it incorrectly). >>> >>> Section 5.5: Why not 'MUST'? Seems reasonable to say that one MUST >>> evaluate the risk and since there is no definition of 'appropriate', th= en >>> any mitigations will do, no? >>> >> >> All of this makes sense and I took a pass over sec 5 with it in mind Sec= urity >> Considerations: attempt improvements around normative language and other >> language too >> >> >> [DC] these all look good. > >> >> >>> >>> IANA Considerations: Add this, see: >>> https://authors.ietf.org/en/iana-considerations . It *might* be >>> possible to remove it prior to publication. IANA will know (and tell y= ou) >>> for sure. >>> >> >> This led me to look at and makes some small changes with Fiddling with >> IANA Considerations >> >> but otherwise I'm not sure what action or learning I was supposed to tak= e >> from that? >> >> > [DC] sigh.... it was the placement of this section that confused me. No > problem, I just didn't win the game of hide and seek the IANA Considerati= on > section game (this is me poking fun at myself, no changes required). > >> >> >>> Acknowledgements (Appendix C): I would remove the parenthetical and >>> just state a generic 'and others for their valuable input....'. Naming >>> everyone who had input is not actually required. [rationale: the () w= on't >>> age well] >>> >> >> The parenthetical was really meant as an invitation to people that we ma= y >> have overlooked to let us know so we could include them. But the time fo= r >> that has passed so we'll take it out. 2824b2e >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --0000000000002fc2aa065049c9a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Apr 25,= 2026 at 9:31=E2=80=AFAM Deb Cooley <debcooley1@gmail.com> wrote:
These all l= ook good to me.=C2=A0 I'm going to submit it to IETF Last Call.

Adding Aaron as an author is fine as well. I will need Ri= faat to update the shepherd review to provide at least a little bit of rati= onale for 6 authors.

Done=

Regards,
=C2=A0Rifaat
=C2=A0<= /div>

Other comments/confessions?=C2=A0 in line= with [DC]

Deb

On Fri, Apr 24, 2026 at 12:11= =E2=80=AFPM Brian Campbell <bcampbell@pingidentity.com> wrote:
Thank y= ou for the review and it's now my turn to apologize=C2=A0for the delay = (can I blame IETF 125 at this point? probably not...).=C2=A0 Some specific = responses are inline below but I don't think you'll find anything s= urprising or controversial.=C2=A0 This issue https://gith= ub.com/oauth-wg/oauth-identity-chaining/issues/182 and this PR https://github.com/oauth-wg/oauth-identity-chaining/pull/183 k= inda show our work here and the responses below are taken from the issue an= d specific commits mentioned are part of that PR. A new draft incorporating= all this will be forthcoming soon.=C2=A0

<= div>
On Wed, Apr 8, 2026 at 6:57=E2=80=AFAM Deb Cooley <debcooley1@gmail.com> wrote= :
Thank you for your work on this specification, here are my comments= on this draft.=C2=A0 Apologies for the delay (IETF 125 and recovery from t= he same takes time).=C2=A0 I don't think any of these comments are espe= cially difficult, most are process related:=C2=A0

= Deb
Sec AD

-----------------------------= ----------
General: =C2=A0Consider using *.*.example.org for example domains (currently= this draft uses as.*.org).=C2=A0 See: =C2=A0https://authors.ietf.org/example= -addresses =C2=A0for more information.

Yup, will do in 3c777e3 and 886cbc6
[D= C] certainly the change results in a 'non-routable' domain, but con= sider adding '.org' to the end.=C2=A0 This can wait for later, and = possibly for=C2=A0
someone else commenting on it.=C2=A0 =C2=A0
=C2=A0


Long line: =C2=A0Lin= e 416, is 75 characters long, according to idnits (experimental).=C2=A0 I d= id not go looking for this (which is why I've put it up front). =C2=A0<= br>

=C2=A0


Section 2.1, Appendix B: = =C2=A0Using steps (A), (B), (C) could be confusing in light of the pre-exis= ting domain enumerations of Domain A, Domain B.=C2=A0 I'd suggest using= some other enumeration for the steps, maybe (1), (2), (3) to disambiguate.=

Makes good sense 7a90229
= =C2=A0

Section 2.2: =C2=A0Since this 'MAY' does no= t enable/disable interoperability (the goal of BCP 14), consider changing i= t to 'may' or even 'could'.

Happy to do that one cf9e53f
=C2=A0

<= br>Section 2.3, bullet 1: =C2=A0'MUST deny' or 'MUST NOT approv= e'?=C2=A0 Which will be more obvious to the implementer?

In bullet 1 or 2.3[.2?], deny seems more = obvious to me and I was an implementer at one point long ago in this so cal= led career.

[DC] this is = fine.=C2=A0=C2=A0
=C2=A0

Sect= ion 2.4.3: =C2=A0There is an assumption here that the previous rules/steps/= checks have been validated without error.=C2=A0 Perhaps consider adding a p= hrase like, 'When the authorization grant has been validated, the....&#= 39;

=C2=A0

=
Section 5: =C2=A0BCP14 language or not?=C2=A0 Please see: =C2=A0https://datatracker.ietf.org/= doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/= . While BCP 14 words in Security Considerations is completely appropriate,= it should still be used sparingly.=C2=A0 The word 'must' is just a= s normative as 'MUST', but carries less baggage.=C2=A0 I would sugg= est going back through Section 5, and consider which of the BCP 14 words ar= e there for 'interoperability' or to 'prevent harm'.=C2=A0 = Please pay special attention to section on 'SHOULD' and 'RECOMM= ENDED'.=C2=A0 I'm making some comments within Section 5 to emphasiz= e my point of view.

Section 5.1: =C2=A0Naked 'SHOULD's need = to have a 'what are the consequences of violating the should' that = goes with it.=C2=A0 An alternative is to state under what reasonable circum= stances the should isn't possible (maybe that is the public client part= of this section?).

Section 5.4: =C2=A0I'm guessing that there w= as confusion at some point about issuance of refresh tokens by AS domain A = to clients in domain A?=C2=A0 My suggestion to make this a tiny bit clearer= in para 1 is to add 'domain A' when you mention 'client' -= > 'client in domain A'.=C2=A0 It does make it wordier and longer= , but way more obvious that the refresh tokens across domains are the issue= . =C2=A0

Section 5.4: It is also not clear why one might choose to v= iolate the sequence of 'SHOULD NOT', 'SHOULD', 'SHOULD&= #39;...=C2=A0 Why not 'MUST NOT', 'MUST', 'MUST'?= =C2=A0 Sadly, RFC 7521 doesn't specify why/when 'SHOULD NOT' co= uld be ignored (unless I read it incorrectly).

Section 5.5: =C2=A0Wh= y not 'MUST'?=C2=A0 Seems reasonable to say that one MUST evaluate = the risk and since there is no definition of 'appropriate', then an= y mitigations will do, no?

= All of this makes sense and I took a pass over sec 5 with it in mind Security Conside= rations: attempt improvements around normative language and other language = too

[DC] these all lo= ok good.=C2=A0=C2=A0
=C2=A0

I= ANA Considerations: =C2=A0Add this, see: https://authors.ietf.org/en/ian= a-considerations .=C2=A0 It *might* be possible to remove it prior to p= ublication.=C2=A0 IANA will know (and tell you) for sure.

This led me to look at and makes some small = changes with Fiddling with IANA Considerations but otherwise I'm not sure wha= t action or learning I was supposed to take from that?
=C2=A0
[DC] sigh.... it was the placement of this = section that confused me.=C2=A0 No problem, I just didn't win the game = of hide and seek the IANA Consideration section game (this is me poking fun= at myself, no changes required).=C2=A0


Acknowledgements (Appendix C): =C2=A0I would remove the parenthetical = and just state a generic 'and others for their valuable input....'.= =C2=A0 Naming everyone who had input is not actually required. =C2=A0[ratio= nale: =C2=A0the () won't age well]=C2=A0=C2=A0
=

The parenthetical was really meant as an invitation to = people that we=20 may have overlooked to let us know so we could include them. But the=20 time for that has passed so we'll take it out. 2824b2e=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002fc2aa065049c9a2--