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

n-sakimura n-sakimura at nri.co.jp
Mon Nov 19 06:08:00 UTC 2018


I believe that was for Berlin Group and not for UK OB.

From: Tom Jones <thomasclinganjones at gmail.com>
Sent: Saturday, November 17, 2018 7:11 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Nat Sakimura <n-sakimura at nri.co.jp>
Subject: Re: [Openid-specs-ab] Idea: client issue token themselves

******************************************************************
本メールはフリーメールから届いています。標的型攻撃メールはフリーメ
ールから届くことがありますのでご注意ください。身に覚えのないメール
であれば添付ファイルやURLを開かず、以下に掲載されている手順に従っ
て対応をお願いします。

共有情報>情報セキュリティトピックス>怪しいメールが届いたら
または、
NRI Group Security Portal>情報セキュリティトピックス
>怪しいメールが届いたら
******************************************************************
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<mailto: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<mailto: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<mailto:Sascha.Preibisch at ca.com>
Cc: Tom Jones <thomasclinganjones at gmail.com<mailto:thomasclinganjones at gmail.com>>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net<mailto: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<mailto: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<mailto: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<mailto:openid-specs-ab at lists.openid.net>>
Cc: "Preibisch, Sascha H" <Sascha.Preibisch at ca.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20181119/e7f49ecf/attachment-0001.html>


More information about the Openid-specs-ab mailing list