[Openid-specs-ab] Best practices for native+server client

[Joseph Heenan]

Hi Tom,

I’m not sure I understand what ’sp’ stands for in this context?

I didn’t mention the UKOB spec at all, and I don’t believe it mentions anything in this area.

My statement was based on a native mobile app and a confidential client in the backend connecting to a FAPI part 2 authorization server. The mobile app needs a signed request object in order to present the authentication endpoint to the user; the native app can’t/mustn’t have the keys to create that request object so this can be obtained by the native app either directly from a backend API for the client, or (as Nat mentions) the browser can be sent to the confidential client which redirects to the AS.

I think we’re talking about having a document that describes what should be done, but not the exact details of how it is done. I don’t have a wrong feeling for whether it’s called a spec or a best practice.

Is the draft code of conduct document you mentioned publicly available?

Thanks

Joseph


> On 22 Jul 2019, at 18:53, Tom Jones <thomasclinganjones at gmail.com> wrote:
> 
> Are you saying that the ukob spec addresses the communication between a sp and the sp software running on the users phone?
> 
> That is the topic of a code of conduct currently under development in us health care. It would be good to compare notes.
> 
> Since this is regarded as internal messaging I am not sure it is an appropriate subject for standardization. Best practice perhaps.
> 
> thx ..Tom (mobile)
> 
> On Mon, Jul 22, 2019, 10:33 AM Joseph Heenan via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
> If this were under FAPI part 2 the native app would need to obtain [at a minimum] the signed request object from the backend, and I believe PKCE then doesn’t add a huge amount (except allowing the server to perform the checks rather than relying on the client).
> 
> There might be an argument that the native app should never possess the code verifier and should instead ask the backend to create a code_challenge for it? I’m not sure it makes a massive difference to the security model though.
> 
> A spec seems like a good idea to me.
> 
> Joseph
> 
> > On 22 Jul 2019, at 17:38, Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
> > 
> > So do you think it is a good idea to codify it in a short spec?
> > I have seen too many of bad patterns lately :-(
> > 
> > On Mon, Jul 22, 2019 at 10:10 AM Torsten Lodderstedt
> > <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
> >> 
> >> 
> >> 
> >>> On 20. Jul 2019, at 21:03, Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
> >>> 
> >>> 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.
> >> 
> >> I agree.
> >> 
> > 
> > 
> > -- 
> > Nat Sakimura (=nat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/ <http://nat.sakimura.org/>
> > @_nat_en
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190723/88b5e7cb/attachment.html>