<div dir="ltr">I don't think that applies to health care. (altho it could if the authn were IAL2 certified - i just don't see that happening.)<div>So the model i have in mind is that the user visits a csp and gets a credential that is stored on their machine.</div><div>From that time on the user just authenticates to their phone and that act (gesture, whatever) releases the cred to the site.</div><div>The CSP is not involved in authentication, just the access to the local TEE.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 21, 2019 at 7:59 AM Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes. I am talking about the combination of the site supplied mobile<br>
app + web backend.<br>
Also, the user authentication is handled by an external IdP.<br>
<br>
I will have a look at the link you gave.<br>
<br>
Thanks. Regards<br>
<br>
Nat<br>
<br>
On Sat, Jul 20, 2019 at 5:02 PM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>> wrote:<br>
><br>
> I have been trying to get my head around this problem to solve the US Health care requirements as specfied here  <a href="https://hl7.org/fhir/smart-app-launch/index.html" rel="noreferrer" target="_blank">https://hl7.org/fhir/smart-app-launch/index.html</a>  Note that the focus here is on IAL2 AAL2 authn which requires some sort of TEE.<br>
> You should also note that they have separated the problem into quadrants, native apps and web apps on one axis and site supplied versus trusted third party on the other.<br>
> I have been focused on the trusted third party app. I sounds like you are asking about site supplied, but both need to be addressed to assure that the right criteria an placed on the right  problem.<br>
> A good approach would to address all four at once to give architects the ability to make the right choices, but a third axis would be assurance level. That would be 8 use cases (or 12 if you wanted to address IAL3 as well).<br>
> ..tom<br>
> Peace ..tom<br>
><br>
><br>
> On Sat, Jul 20, 2019 at 12:11 PM Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>><br>
>> So, what is the best practices for native app + server based client? There can be several patterns but I don't think we have actually documented them.<br>
>><br>
>> An app getting ID token using PKCE and sending it over to the server does not feel right as the binding between the App and the server component is pretty weak.<br>
>><br>
>> An app sending a PKCE request and getting back the code that is being sent to the server with the code verifier that are used by the server component to obtain ID Token feels a bit better.<br>
>><br>
>> Any suggestions?<br>
>><br>
>> Nat Sakimura<br>
>> Chairman, OpenID Foundation<br>
>> <a href="https://nat.sakimura.org" rel="noreferrer" target="_blank">https://nat.sakimura.org</a><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
<br>
-- <br>
Nat Sakimura (=nat)<br>
Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" rel="noreferrer" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<br>
</blockquote></div>