Subject: [Jwt-reg-review] [IANA #1158948] Requested review for IANA registration in draft-ietf-ace-oauth-params (jwt - JSON Web Token Claim)

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Tue, 18 Feb 2020 21:03:19 +0000

Dear John, Michael, and Chuck,

Have you had a chance to review the registration in draft-ietf-ace-oauth-params?

https://tools.ietf.org/html/draft-ietf-ace-oauth-params

Thanks,

Sabrina Tanamal
Senior IANA Services Specialist

On Thu Jan 30 00:40:53 2020, sabrina.tanamal wrote:
> Dear John, Michael, and Chuck,
> 
> Have you had a chance to review the registration in draft-ietf-ace-
> oauth-params?
> 
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params
> 
> Thanks,
> 
> Sabrina Tanamal
> Senior IANA Services Specialist
> 
> > On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> > > Apologies, I forgot to reply-all at some earlier point and dropped
> > > the
> > > mailing lists and other cc's off the thread. Added back now.
> > >
> > > And also apologies because I think I need to recuse myself from the
> > > DE
> > > responsibility on the JWT registry request here. I've spent more
> > > time
> > > than
> > > I'd like to admit or really have to spare on it and am still
> > > struggling to
> > > understand.
> > >
> > > I appreciate you pointing out the authz-info endpoint in ACE but I
> > > still
> > > don't follow how "rs_cnf" in an access token would really work in
> > > practice.
> > > The client sends the token to the RS's authz-info endpoint on an
> > > insecure
> > > connection or one that has the server auth with potentially
> > > different
> > > key
> > > and the RS stores the access token for later use. Then on resource
> > > access
> > > the RS looks up the access token (with respect to the cnf key in
> > > it)
> > > based
> > > on the key the client used in establishing a new mutually
> > > authentication
> > > connection to the RS. For the RS to choose a key for server it will
> > > use
> > > during the handshake (and as far as I know the server key is the
> > > first in
> > > the authn process of the handshake) based on the "rs_cnf" in the
> > > access
> > > token, it needs to remember and associate that client and the
> > > access
> > > token
> > > with something else (IP address?) that will be available during the
> > > handshake. It doesn't fit together for me in a way that seems
> > > likely
> > > to
> > > work or be interoperable but, like I said, I'm really struggling to
> > > understand.
> > >
> > > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig
> > > <[email-masked]>
> > > wrote:
> > >
> > > > Hi Brian,
> > > >
> > > >
> > > >
> > > > Comments inline.
> > > >
> > > >
> > > >
> > > > /Ludwig
> > > >
> > > >
> > > >
> > > > *From:* Brian Campbell <[email-masked]>
> > > > *Sent:* den 13 januari 2020 21:22
> > > > *To:* Seitz Ludwig <[email-masked]>
> > > > *Subject:* Re: [Ace] Requested review for IANA registration in
> > > > draft-ietf-ace-oauth-params
> > > >
> > > >
> > > >
> > > > Thanks for the response and updates Ludwig,
> > > >
> > > >
> > > >
> > > > Please bear with me while I try to wrap my head around some
> > > > things.
> > > >
> > > >
> > > >
> > > > The JWT registration request for the "rs_cnf" claim points to Sec
> > > > 3.3
> > > > <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-
> > > > 08#section-3.3>
> > > > saying it is "a hint [in the access token] to the RS about which
> > > > key it
> > > > should use to authenticate towards the client".  But doesn't the
> > > > client
> > > > have to go through the DTLS/TLS handshake with the RS (which is
> > > > presumably
> > > > when it authenticates to the client) before it presents the
> > > > access
> > > > token?
> > > > I'm not seeing how this would work as seems the RS won't see the
> > > > hint until
> > > > after it needs it.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [LS] Not in the ACE flow. We use the access token to establish
> > > > keys
> > > > at the
> > > > RS both for the client and the RS. We have therefore defined a
> > > > new
> > > > ACE-OAuth endpoint (authz-info) at the RS. The client can POST
> > > > access
> > > > tokens to this endpoint without prior authentication.
> > > >
> > > > At that point, the RS only validates the signature/MAC by the AS.
> > > >
> > > >
> > > >
> > > > Later at the time of access, the corresponding token is linked to
> > > > the
> > > > access request via the pop-mechanism and the client/access
> > > > specific
> > > > parts
> > > > are validated (e.g. scope, subject).
> > > >
> > > >
> > > >
> > > > Hope that clarifies things a bit.
> > > >
> > > >
> > > >
> > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig
> > > > <[email-masked]>
> > > > wrote:
> > > >
> > > > Hello again Brian,
> > > >
> > > >
> > > >
> > > > Thank you for reviewing this! Indeed the handling of JWT/JSON
> > > > interactions
> > > > was handled sloppily here. I will soon issue a draft update that
> > > > specifies
> > > > that the JSON-based interactions should use the syntax from
> > > > RFC7800
> > > > while
> > > > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-
> > > > possession.
> > > >
> > > >
> > > >
> > > > This correction goes for all the use of “cnf”, “req_cnf” and
> > > > “rs_cnf”.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > Ludwig
> > > >
> > > >
> > > >
> > > > *From:* Ace <[email-masked]> *On Behalf Of *Brian Campbell
> > > > *Sent:* den 10 januari 2020 22:12
> > > > *To:* Ludwig Seitz <[email-masked]>
> > > > *Cc:* Roman Danyliw <[email-masked]>; [email-masked]; Jim
> > > > Schaad <
> > > > [email-masked]>; The IESG <[email-masked]>; [email-masked];
> > > > [email-masked]; Benjamin Kaduk <[email-masked]>
> > > > *Subject:* Re: [Ace] Requested review for IANA registration in
> > > > draft-ietf-ace-oauth-params
> > > >
> > > >
> > > >
> > > > That  "rs_cnf" claim registration request in 9.1 points to 3.3
> > > > which says
> > > > it has 'the same syntax and semantics as defined in for the
> > > > "rs_cnf"
> > > > parameter', which I think is in 4.1. And 4.1 says that the
> > > > "rs_cnf"
> > > > values
> > > > 'follow the syntax of the "cnf" claim from section 3.1 of
> > > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other
> > > > comments
> > > > I've
> > > > made today, I don't follow what that would mean for the value of
> > > > the claim
> > > > when it's a JWT. And that seems like something that's important
> > > > to
> > > > understand for the purpose of a JWT claims registry request.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz
> > > > <[email-masked]>
> > > > wrote:
> > > >
> > > > Hello JWT registry reviewers,
> > > >
> > > > the IESG-designated experts for the JWT claims registry have
> > > > asked
> > > > me to
> > > > send a review request to you about the "rs_cnf" claim registered
> > > > here:
> > > >
> > > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-
> > > > 07#section-
> > > > 9.1
> > > >
> > > > Thank you in advance for you review comments.
> > > >
> > > > Regards,
> > > >
> > > > Ludwig
> > > >
> > > > _______________________________________________
> > > > Ace mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/ace
> > > >
> > > >
> > > > *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
> > > > sender
> > > > immediately by e-mail and delete the message and any file
> > > > attachments from
> > > > your computer. Thank you.*
> > > >
> > > >
> > > > *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
> > > > sender
> > > > immediately by e-mail and delete the message and any file
> > > > attachments from
> > > > your computer. Thank you.*
> > > >
> > >
> > > --
> > > _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 sender
> > > immediately
> > > by e-mail and delete the message and any file attachments from your
> > > computer. Thank you._

---

From: Mike Jones <[email-masked]>
Date: Tue, 18 Feb 2020 22:35:35 +0000

I'm OK with these registrations, but I don't believe that John, Chuck, or I are designated experts for the applicable registries.  Hannes is the expert for the OAuth Parameters registry.  Justin is the expert for the OAuth Introspection registry.

And I don't believe that the OAuth Parameters CBOR Mappings registry has been created yet.

I hope this helps...

				-- Mike

-----Original Message-----
From: Jwt-reg-review <[email-masked]> On Behalf Of Sabrina Tanamal via RT
Sent: Tuesday, February 18, 2020 1:03 PM
Cc: [email-masked]
Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1158948] Requested review for IANA registration in draft-ietf-ace-oauth-params (jwt - JSON Web Token Claim)

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ce74ace3192cb4a52723608d7b4b60280%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176566130853320&amp;sdata=5pmASiRTPR%2B7Ve5R1u8myHo6qh%2BGDVjEhKhm6K8hPgc%3D&amp;reserved=0

Thanks,

Sabrina Tanamal

On Thu Jan 30 00:40:53 2020, sabrina.tanamal wrote:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params&amp;data=02%7C01%7CMic
> hael.Jones%40microsoft.com%7Ce74ace3192cb4a52723608d7b4b60280%7C72f988
> bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176566130863324&amp;sdata=85Yy
> 8GkBoL92w09RdviHOCrUY%2BvNF0Pqe8hJQxZ3Ps0%3D&amp;reserved=0
> 
> Thanks,
> 
> Sabrina Tanamal
> > > the mailing lists and other cc's off the thread. Added back now.
> > >
> > > And also apologies because I think I need to recuse myself from 
> > > the DE responsibility on the JWT registry request here. I've spent 
> > > more time than I'd like to admit or really have to spare on it and 
> > > am still struggling to understand.
> > >
> > > still don't follow how "rs_cnf" in an access token would really 
> > > work in practice.
> > > insecure connection or one that has the server auth with 
> > > potentially different key and the RS stores the access token for 
> > > later use. Then on resource access the RS looks up the access 
> > > token (with respect to the cnf key in
> > > it)
> > > based
> > > authentication connection to the RS. For the RS to choose a key 
> > > for server it will use during the handshake (and as far as I know 
> > > the server key is the first in the authn process of the handshake) 
> > > based on the "rs_cnf" in the access token, it needs to remember 
> > > and associate that client and the access token with something else 
> > > (IP address?) that will be available during the handshake. It 
> > > doesn't fit together for me in a way that seems likely to work or 
> > > be interoperable but, like I said, I'm really struggling to 
> > > understand.
> > >
> > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F
> > > > %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-&amp;data
> > > > =02%7C01%7CMichael.Jones%40microsoft.com%7Ce74ace3192cb4a5272360
> > > > 8d7b4b60280%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371765
> > > > 66130863324&amp;sdata=0wG8HJXLxcR4YKWlF%2FFGZSB49uZ0u4bg89S2dhyz
> > > > 5Ok%3D&amp;reserved=0
> > > > 08#section-3.3>
> > > > key it should use to authenticate towards the client".  But 
> > > > doesn't the client have to go through the DTLS/TLS handshake 
> > > > with the RS (which is presumably when it authenticates to the 
> > > > client) before it presents the access token?
> > > > hint until after it needs it.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > keys at the RS both for the client and the RS. We have therefore 
> > > > defined a new ACE-OAuth endpoint (authz-info) at the RS. The 
> > > > client can POST access tokens to this endpoint without prior 
> > > > authentication.
> > > >
> > > > Later at the time of access, the corresponding token is linked 
> > > > to the access request via the pop-mechanism and the 
> > > > client/access specific parts are validated (e.g. scope, 
> > > > subject).
> > > >
> > > >
> > > >
> > > > interactions was handled sloppily here. I will soon issue a 
> > > > draft update that specifies that the JSON-based interactions 
> > > > should use the syntax from
> > > > RFC7800
> > > > while
> > > > Schaad < [email-masked]>; The IESG <[email-masked]>; 
> > > > [email-masked]; [email-masked]; Benjamin Kaduk 
> > > > <[email-masked]>
> > > > which says it has 'the same syntax and semantics as defined in 
> > > > for the "rs_cnf"
> > > > comments I've made today, I don't follow what that would mean 
> > > > for the value of the claim when it's a JWT. And that seems like 
> > > > something that's important to understand for the purpose of a 
> > > > JWT claims registry request.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > asked me to send a review request to you about the "rs_cnf" 
> > > > claim registered
> > > > here:
> > > >
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-&amp;data=
> > > > 02%7C01%7CMichael.Jones%40microsoft.com%7Ce74ace3192cb4a52723608
> > > > d7b4b60280%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717656
> > > > 6130863324&amp;sdata=0wG8HJXLxcR4YKWlF%2FFGZSB49uZ0u4bg89S2dhyz5
> > > > Ok%3D&amp;reserved=0
> > > > 07#section-
> > > > 9.1
> > > >
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=02%7C01%7CMic
> > > > hael.Jones%40microsoft.com%7Ce74ace3192cb4a52723608d7b4b60280%7C
> > > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176566130863324&am
> > > > p;sdata=PmTfR3Vpg60L%2BF4Bp9lTFrh%2FpDHhff2b%2B%2FnvUxOXoFw%3D&a
> > > > mp;reserved=0
> > > >
> > > >
> > > > the sender immediately by e-mail and delete the message and any 
> > > > file attachments from your computer. Thank you.*
> > > >
> > > >
> > > > the sender immediately by e-mail and delete the message and any 
> > > > file attachments from your computer. Thank you.*
> > > >
> > >
> > > --
> > > 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 sender immediately by e-mail and delete the 
> > > message and any file attachments from your computer. Thank you._

_______________________________________________
Jwt-reg-review mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjwt-reg-review&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ce74ace3192cb4a52723608d7b4b60280%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176566130863324&amp;sdata=9tgjsYDiXnBnToIQm6rOerAMj%2BqhFvur%2BdlDAySu618%3D&amp;reserved=0

---

From: Mike Jones <[email-masked]>
Date: Tue, 18 Feb 2020 22:48:23 +0000

This draft is not making any JWT Claims registration requests, so I'm not sure why this expert review request is being made.

				-- Mike

-----Original Message-----
From: Jwt-reg-review <[email-masked]> On Behalf Of Sabrina Tanamal via RT
Sent: Wednesday, January 29, 2020 4:41 PM
Cc: [email-masked]
Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=KyQE29ZaEQ5%2FX7i6pjzkicORKhDtawDFVjMsNk63%2FuE%3D&amp;reserved=0

Thanks,

Sabrina Tanamal

> > DE responsibility on the JWT registry request here. I've spent more 
> > time than I'd like to admit or really have to spare on it and am 
> > still struggling to understand.
> >
> > still don't follow how "rs_cnf" in an access token would really work 
> > in practice.
> > insecure connection or one that has the server auth with potentially 
> > different key and the RS stores the access token for later use. Then 
> > on resource access the RS looks up the access token (with respect to 
> > the cnf key in it) based on the key the client used in establishing 
> > a new mutually authentication connection to the RS. For the RS to 
> > choose a key for server it will use during the handshake (and as far 
> > as I know the server key is the first in the authn process of the 
> > handshake) based on the "rs_cnf" in the access token, it needs to 
> > remember and associate that client and the access token with 
> > something else (IP address?) that will be available during the 
> > handshake. It doesn't fit together for me in a way that seems likely 
> > to work or be interoperable but, like I said, I'm really struggling 
> > to understand.
> >
> > > Please bear with me while I try to wrap my head around some things.
> > >
> > >
> > >
> > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-&amp;data=02%
> > > 7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51
> > > d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322
> > > 478&amp;sdata=eGiV%2BpjnegXqzjrDbRKEFd2PLJbt9jFh3cTLQQHJCX8%3D&amp
> > > ;reserved=0
> > > 08#section-3.3>
> > > doesn't the client have to go through the DTLS/TLS handshake with 
> > > the RS (which is presumably when it authenticates to the client) 
> > > before it presents the access token?
> > > the access request via the pop-mechanism and the client/access 
> > > specific parts are validated (e.g. scope, subject).
> > >
> > >
> > >
> > > interactions was handled sloppily here. I will soon issue a draft 
> > > update that specifies that the JSON-based interactions should use 
> > > the syntax from RFC7800 while the CBOR-based ones should use 
> > > ID.ietf-ace-cwt-proof-of-possession.
> > >
> > >
> > >
> > > which says it has 'the same syntax and semantics as defined in for 
> > > the "rs_cnf"
> > > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf"
> > > values
> > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments 
> > > I've made today, I don't follow what that would mean for the value 
> > > of the claim when it's a JWT. And that seems like something that's 
> > > important to understand for the purpose of a JWT claims registry 
> > > request.
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz <[email-masked]>
> > > wrote:
> > >
> > > the IESG-designated experts for the JWT claims registry have asked 
> > > me to send a review request to you about the "rs_cnf" claim 
> > > registered
> > > here:
> > >
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > tools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-07%23section-&
> > > amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aa
> > > b17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
> > > 159416642322478&amp;sdata=HUDQlv7KRIJiV2AAFcK9H1jXVcglVisiCFP8lYQ8
> > > 4tc%3D&amp;reserved=0
> > > 9.1
> > >
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=02%7C01%7CMichael
> > > .Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988
> > > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=
> > > QoMEDPhQNPpLz8mv02OMYVOKKd3DfusKD%2Ftz%2B%2B11Q6I%3D&amp;reserved=
> > > 0
> > >
> > >

_______________________________________________
Jwt-reg-review mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjwt-reg-review&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=pTjdeVzoUJftCq0fdasxSzEByik0PsrbHc9x8d9%2FfeM%3D&amp;reserved=0

---

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Wed, 19 Feb 2020 16:41:14 +0000

Hi Mike, 

Thanks for checking. It looks like the JWT claim was removed in version -12. Sorry, we aren't notified of version changes. 

Thanks,
Sabrina

On Tue Feb 18 22:49:03 2020, [email-masked] wrote:
> This draft is not making any JWT Claims registration requests, so I'm
> not sure why this expert review request is being made.
> 
> -- Mike
> 
> Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace]
> Requested review for IANA registration in draft-ietf-ace-oauth-params
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-
> ietf-ace-oauth-
> params&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=KyQE29ZaEQ5%2FX7i6pjzkicORKhDtawDFVjMsNk63%2FuE%3D&amp;reserved=0
> 
> Thanks,
> 
> Sabrina Tanamal
> > > work
> > > potentially
> > > > with
> > > > for
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjwt-
> reg-
> review&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=pTjdeVzoUJftCq0fdasxSzEByik0PsrbHc9x8d9%2FfeM%3D&amp;reserved=0