<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tele-GroteskHal;}
@font-face
{font-family:Tele-GroteskFet;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:735510651;
mso-list-type:hybrid;
mso-list-template-ids:1313234136 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1294017862;
mso-list-type:hybrid;
mso-list-template-ids:1088343956 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:1451120124;
mso-list-template-ids:-905906972;}
@list l3
{mso-list-id:1470320257;
mso-list-template-ids:-82905468;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-AU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US">Hi Michael,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US">The current account porting spec involves a single port token, not a port token per RP. The port token itself is not RP-specific. When the New OP uses authenticated encryption to include
the port token in an id-token for a specific RP, the RP’s sector_id is part of the authenticated data. That binds the port token to the RP-specific detail necessary for the Old OP to know the correct pairwise subject id (sub) to return (the RP is also authenticated
when calling the Old OP).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US">More comments inline.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#C00000">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">James Manger<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Engan, Michael [mailto:Michael.Engan1@T-Mobile.com]
<br>
<b>Sent:</b> Wednesday, 18 July 2018 3:39 AM<br>
<b>To:</b> Manger, James <James.H.Manger@team.telstra.com>; Openid-specs-mobile-profile <openid-specs-mobile-profile@lists.openid.net><br>
<b>Cc:</b> Latham, James <James.Latham5@T-Mobile.com><br>
<b>Subject:</b> RE: Moderna Feedback from T-Mobile: AKA for porting<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Good morning, Sorry for my delayed response, I was out on vacation.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I have added some comments inline with yours with my initials [me]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Manger, James [mailto:James.H.Manger@team.telstra.com]
<br>
<b>Sent:</b> Tuesday, July 10, 2018 7:54 AM<br>
<b>To:</b> Engan, Michael <Michael.Engan1@T-Mobile.com>; Openid-specs-mobile-profile <openid-specs-mobile-profile@lists.openid.net><br>
<b>Subject:</b> RE: Moderna Feedback from T-Mobile: AKA for porting<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi Michael,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">“The assertion from the old MNO” actually needs to be many assertions — one per RP — since it carries “the old MNO’s pairwise subject” (ie a RP-specific “sub”).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So if a user has accessed 100 RPs, then during porting the old MNO need to generate, sign and send 100 JWTs, and the new MNO need to store these. Would we need limits?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[me] this is already the case.<span style="color:#1F497D"> </span>
If the user ports under the current moderna suggestion, then the old mno needs to generate a PORT token. In order for that PORT token to return the correct pairwise subject identified the old MNO needs to track which RP it was issued to, and therefore issue
a different PORT token for each RP the user already visited. Likewise this means the New MNO also has to know which previous RP’s the user had approved (we want this anyways so the consents port), and store an AKA value to use for each. So the suggestion
to make the PORT token a JWT does not shift the underlying needs there to track per RP. NOTE: all this would be easier IF the MNO’s don’t use pairwise Subject identifiers. In which case a single AKA value for OLD sub would work. (still signed by some method).
But our business teams have reiterated that they want MNO’s to use pairwise identifiers for each sector_url.
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] This is not how the current spec works, where a port token is not RP-specific. See above.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] Transferring consents is not part of the current spec. That would require extra data in a porting exchange, probably per-RP (unless there was a fancy probabilistic approach with, say, a bloom filter).<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">An old MNO might not know all the RPs a user has visited. It isn’t strictly necessary to record this if the per-RP pairwise sub is
<i>derived</i> whenever a login to that RP occurs. That would make it basically impossible to generate all the assertions at the porting time.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[me] the old MNO must capture consents. Even if the MNO generates the pairwise subject identifier with each login, the MNO has to still have a record to confirm if the user has already granted this RP access to the requested scopes. Otherwise
the user will be asked with every login/access … “user do you agree this RP can access your xxx”. Note: to support porting I know T-Mobile will need to convert our realtime generation of the pairwise subject. But this is needed because we will also
now need to support a pairwise subject login Hint. We don’t want RP’s using the phone number so if the RP is told to use the subject as the reference. Then the RP needs to be able to use the subject as the login hint, and therefore We have to have a recorded
version of each pairwise subject so we can lookup which internal user it is referencing.
<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] It does seem likely that most IdPs will keep per-user-per-RP details. So perhaps we could bake that assumption into a porting spec. But it is far from clear to me that such a restriction plus its implications
for needing to calculate/transfer/reveal/store lots more data is a good trade-off to avoid an extra RP-to-Old-OP call.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Another disadvantage of generating all the per-RP assertions up front (at port time) is the privacy issue. The new MNO learns the user’s entire history, even if the user never intends to visit some of the old
RPs ever again.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[me] ok, yes I agree.. but this is 1) a biz call.. when a user ports a phone number from one carrier to another carrier will the user be able to Port their identity.. (when mno’s use pairwise that means porting all your RP’s, consents
you granted each, and the subject/token/porttoken you were known as for that RP. 2) this is also user controlled. When a new MNO wants to pull/port you they will make an authentication request to the old MNO with the “Port_data” scope. This means
the User can be shown and explicitly consent to the porting of all their data from the old carrier to the new carrier. If the user chooses they can decline consent for the port_data scope, while approving other scopes like “profile”. This would let a user
simplify onboarding to the new MNO, but RP’s will see a new Subject. (possibly with existing attributes like phone number, and email). This may cause security problems where we tell RP’s to use the subject as the reference, and the other fields as simple
data attributes.<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] A biz call indeed. Though a New OP only learning the RPs you use when (and if) you login to those RPs via the New OP seems like a much more privacy-friendly default behaviour.</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Assertions that are generated at port time, but not consumed by an RP until the user next signs in to that RP (perhaps months later), means we need longer-term keys and revocation support. In contrast to the
current scheme that can operate with frequently-rotated short-term no-revocation-needed keys.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[me] correct. Totally agree. Which is why I suggest that an MNO generate two key pairs. One for JWT -> ID_Tokens which can be rotated frequently. And then a second Key pair JUST for signing/encrypting the PORT token(jwt/jwe) which would
rotate slowly. It could be possible that the old MNO still allows an interface that a RP could use for Port token validation in the event the port token siging key has rotated out of the jwks file. (in which case the old mno needs to keep it internally listed
for longer). But even if we don’t make the port_token a JWT, the old MNO still needs to keep in memory for a long period the method of validating that token and the data it represents, which is still the same challenge.
<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] 3<sup>rd</sup> parties (RPs) being able to verify long-term tokens is not really the same challenge as being able to verify your own tokens. The former needs a public revocation infrastructure (and relies
on the 3<sup>rd</sup> parties actually checking for revocations, which has been notoriously poorly implemented in web PKI in practice). The latter just needs a local process.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#C00000">[james] A 2<sup>nd</sup> key pair is an extra complexity. Plus the OpenID Connect mechanism of publishing a JWK key set doesn’t have a clean way of marking 1 key for id-tokens and a separate key for port tokens.
Publish both keys and RPs will accept id-tokens and port tokens signed by either, which seems to undermine the use of short-term keys.</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">James Manger<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Openid-specs-mobile-profile [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Engan, Michael<br>
<b>Sent:</b> Tuesday, 3 July 2018 8:52 AM<br>
<b>To:</b> Openid-specs-mobile-profile <<a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a>><br>
<b>Subject:</b> [Openid-specs-mobile-profile] Moderna Feedback from T-Mobile<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Good Morning, I would like to offer up some feedback conversations to the working group on the following:
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">…</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo3">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">AKA for Porting<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The US carriers have been discussing the AKA parameter for account porting. Ideally an ID_Token can be validated by an RP with only a cached public key for the carrier. Under the current suggestions the RP would now need
to make a request to the original carrier with any port_token to complete the validation. To go back to completely validated by the RP, we would like to see the AKA port token be something like a JWT, or JWE from the original carrier. This way the RP can
validate the id_token, and the port_token with cached jwk public keys from both the new and original MNO.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The assertion from the old MNO needs to carry at least<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="mso-list:l1 level1 lfo6"><span lang="EN-US">Acknowledgment from the old mno that the user has ported Out of the old MNO<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo6"><span lang="EN-US">Acknowledgement from the old mno that the user has ported TO the new mno.
<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo6"><span lang="EN-US">Confirmation what the old MNO’s pairwise subject was.
<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo6"><span lang="EN-US">Possibly a date of the PORT for use in anti-fraud detection.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span lang="EN-US">It will remain up to the RP to update their subject from the old mno Sub to the new mno’s sub once AKA port_token validation is complete.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:Tele-GroteskFet;color:#1F497D">Michael Engan <br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">Principal Systems Architect,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">Authentication, Authorization, & API security</span><span lang="EN-US" style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">12920 SE 38<sup>th</sup> Street | Bellevue, WA 98006<br>
Direct 425-383-2268 | Mobile 425-443-3463</span><span lang="EN-US" style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</body>
</html>