[Openid-specs-native-apps] IIW discussions

[Paul Madsen]

We had overview NAPPS sessions at the OIDF day & IIW last week.

Additionally, we had a small WG session at IIW, during which we focused 
on how to enable 3rd party ASs within NAPPS, specifically

1) how the native app client would obtain an access token from such a 
3rd party AS and
2) how, if relevant, the TA would facilitate a 3rd party AS obtaining 
user consent

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

The model we came up with is

1) TA obtains its own RT & AT from Home AS (HAS)
sometime later
2) App1 asks TA for a token
3) TA uses RT to obtain an id_token from HAS. id_token is targeted at 
Remote AS (RAS)
4) TA passes id_token to App1
5) App1 sends id_token to RAS
6a) if consent not required, RAS returns AT to App1
6b) if consent required, RAS faults back to TA with link to consent endpoint
7) after consent, App1 sends id_token to RAS
8) RAS returns AT to App1
9) App1 uses AT to call API

Compare the above to the previous model, where it was the TA that 
interacted with the Remote AS to obtain the ultimate access token

the above is captured in the enclosed graphic

paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140513/635b7fb5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-05-13 at 10.18.37 AM.png
Type: image/png
Size: 125659 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140513/635b7fb5/attachment-0001.png>