<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1"><font face="Arial">We had overview NAPPS sessions at
the OIDF day & IIW last week.<br>
<br>
Additionally, we had a small WG session at IIW, during which we
focused on how to enable 3rd party ASs within NAPPS,
specifically<br>
<br>
1) how the native app client would obtain an access token from
such a 3rd party AS and<br>
2) how, if relevant, the TA would facilitate a 3rd party AS
obtaining user consent<br>
<br>
In the discussions, the group came up with a not insignificant
change to the architecture - namely just what the TA passes to a
native app<br>
<br>
The model we came up with is <br>
<br>
1) TA obtains its own RT & AT from Home AS (HAS)<br>
sometime later<br>
2) App1 asks TA for a token<br>
3) TA uses RT to obtain an id_token from HAS. id_token is targeted
at Remote AS (RAS)<br>
4) TA passes id_token to App1<br>
5) App1 sends id_token to RAS<br>
6a) if consent not required, RAS returns AT to App1<br>
6b) if consent required, RAS faults back to TA with link to
consent endpoint<br>
7) after consent, </font></font><font size="+1"><font
face="Arial">App1 sends id_token to RAS<br>
8) </font></font><font size="+1"><font face="Arial">RAS returns
AT to App1<br>
9) App1 uses AT to call API<br>
<br>
Compare the above to the previous model, where it was the TA
that interacted with the Remote AS to obtain the ultimate access
token<br>
<br>
the above is captured in the enclosed graphic<br>
<br>
paul<br>
</font></font>
</body>
</html>