[Openid-specs-ab] Idea: client issue token themselves

Tom Jones thomasclinganjones at gmail.com
Fri Nov 16 22:11:16 UTC 2018


Thorsen was quite clear that he wanted (and implemented) account access
without proximate use consent.
Peace ..tom


On Thu, Nov 15, 2018 at 11:06 PM n-sakimura via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hmm. At least, in UK OB, RO consent is required for the data access and
> fund transfer.
>
> In the ROPC model that some organization in the continental Europe is
> promoting, you might be right.
>
>
>
> Nat
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of *Tom Jones via Openid-specs-ab
> *Sent:* Tuesday, November 06, 2018 7:03 AM
> *To:* Sascha.Preibisch at ca.com
> *Cc:* Tom Jones <thomasclinganjones at gmail.com>; Artifact Binding/Connect
> Working Group <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] Idea: client issue token themselves
>
>
>
> right, what bugs me about the UKOB & PSD2 is that the user (resource
> owner) consent is not even required.
>
> That is a major reason why i recommended that openid not approve the FAPI
> specs.
>
> allowing the OP to approve client access to my money is no way in my
> interest.
>
>
> Peace ..tom
>
>
>
>
>
> On Mon, Nov 5, 2018 at 1:19 PM Preibisch, Sascha H <
> Sascha.Preibisch at ca.com> wrote:
>
> Hi Tom!
>
>
>
> Thanks for your thoughts.
>
>
>
> The AS still authenticates the client and verifies the requested scopes as
> it does today. It also authenticates the resource_owner who authorizes the
> client access to resources (which is not really obvious in the diagram, I
> will update that).
>
>
>
> Details about the resource_owner may be included but maybe not. If they,
> the best way may be as an id_token. That id_token would include values such
> as ‘acr’.
>
>
>
> The client is trustworthy if the RS accepts the grant of the AS. And the
> grant can only be meant for that particular client since only that client
> can sign the JWT with a ‘cnf.x5t#S256’ matching value.
>
>
>
> I will collect more feedback and update my page accordingly.
>
>
>
> Thanks,
>
> Sascha
>
>
>
> *From: *Tom Jones <thomasclinganjones at gmail.com>
> *Date: *Monday, November 5, 2018 at 10:45 AM
> *To: *Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc: *"Preibisch, Sascha H" <Sascha.Preibisch at ca.com>
> *Subject: *Re: [Openid-specs-ab] Idea: client issue token themselves
>
>
>
> There seems to be a fundamental problem with even calling this an
> "authorization server". Authorization happens only at the resource server
> itself. The best the "AS" can do is issue a set of claims (some
> masquerading as scopes) - some of which it might also verify. The challenge
> with the jwt is that the validity of the entire jwt is what is asserted.
> What is needed by the resource server is the validity statement for each
> claim.  Including the claim that the client is trustworthy and (in openid)
> that the level of authentication and/or proof-of-presence and/or consent of
> the user was validated (or not).  Combining these various ideas might seem
> like a good idea, but if the resource server has different criteria for
> different claims, it might not be sufficient.
>
> Peace ..tom
>
>
>
>
>
> On Fri, Nov 2, 2018 at 9:53 AM Preibisch, Sascha H via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> Hi all!
>
>
>
> I would like to share the idea of oauth clients that issue token
> themselves with you.
>
>
>
> I wrote a blog post about it here:
>
>
> https://communities.ca.com/blogs/oauth/2018/11/01/oauth-20-serverless-token-issuance
>
>
>
> Thanks for any feedback,
>
> Sascha
>
>
>
> P.S.: today is the last day of CA, as of Monday its Broadcom. I am not
> sure if my blog post is available afterwards at that location!
>
>
>
> Sascha Preibisch
>
> Principal Software Architect
>
> CA Technologies
>
>
>
> CA Mobile API Gateway
>
> CA API Management OAuth Toolkit
>
>
>
> Email: sascha.preibisch at ca.com
>
> Blog: https://communities.ca.com/blogs/oauth
>
>
>
> *My book*: *API Development - A Practical Guide for Business
> Implementation Success
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.apress.com_de_book_9781484241394&d=DwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=whHzJG0H4_GWBEIB6Aixz-VM4jJp8nIActACrXMDfbw&s=dIgpaNQlJyLtp2AnI65CC2wCZSdArSftwoW0DaVSK_M&e=>*
>
>
>
> *Latest blog post: Azure AD integration
> <https://communities.ca.com/blogs/oauth/2018/09/12/azure-ad-integration>*
>
>
>
> *Previous blog post: OTK + IFTTT tutorial
> <https://communities.ca.com/blogs/oauth/2018/06/25/oauth-toolkit-otk-and-ifttt-tutorial>*
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=whHzJG0H4_GWBEIB6Aixz-VM4jJp8nIActACrXMDfbw&s=xMRzrb0tb7djuhR19fKJFgn0Ka84NWsGtIFiy-Wpp_Y&e=>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> 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/20181116/bbbab06f/attachment.html>


More information about the Openid-specs-ab mailing list