[Openid-specs-fapi] Decoupled flows for OAuth 2

Mike Schwartz mike at gluu.org
Fri Mar 2 16:55:58 UTC 2018


Dave,

>>> In decoupled flows, this changes and the client has to pass some 
>>> identifier to
>>> the authorisation server. This is a potential privacy issue and could 
>>> allow clients
>>> to initiate an auth flow without the users consent, potentially 
>>> tricking a user
>>> into granting access.

1. If you could provide a sequence diagram, it would be more clear that 
we mean the same thing by "decoupled flows".

2. Is this out of scope of FAPI? For example, UMA allows "pushed claim 
tokens" to be sent to the token endpoint. If the AS does not have enough 
claims, it can provide the URL of a "Claims Gathering Endpoint" at the 
AS. This is a front-channel endpoint which enables the subject to 
provide additional information or consent. I don't see how your going to 
handle all this in a profile of OpenID Connect.

- Mike


--------------------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org
https://www.linkedin.com/in/nynymike/

On 2018-03-01 10:05, Dave Tonge via Openid-specs-fapi wrote:
> Hi all,
> 
> I would be interested in feedback from those on the list around 2
> issues that we have with decoupled flows such as CIBA:
> 
> 1. "Session binding", i.e. ensuring it is the same user on the
> authentication device and the consumption device
> 
> 2. Obtaining an identifier for the user
> 
> For more on issue no.1, please see the attached discussion paper that
> I've prepared for the OAuth Security Workshop in Italy in a couple of
> weeks time.
> 
> Issue no.2 is summarised as follows: in redirect-based flows the
> client doesn't need to know or pass any user identifier to the
> authorisation server. In decoupled flows, this changes and the client
> has to pass some identifier to the authorisation server. This is a
> potential privacy issue and could allow clients to initiate an auth
> flow without the users consent, potentially tricking a user into
> granting access.
> 
> I have received some suggestions around using QR codes to provide
> unique, single-use (possible time-based) identifiers but I would be
> interested in further discussion on the list about these ideas.
> 
> Thanks
> 
> --
> 
> Dave Tonge
> CTO
>  [1]
> 10 Temple Back, Bristol, BS1 6FLt: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Momentum Financial
> Technology Limited which is authorised and regulated by the Financial
> Conduct Authority ("FCA"). Momentum Financial Technology is entered on
> the Financial Services Register (FRN 561538) at fca.org.uk/register
> [2]. Momentum Financial Technology is registered in England & Wales,
> company registration number 06909772 © . Momentum Financial
> Technology Limited 2016. DISCLAIMER: This email (including any
> attachments) is subject to copyright, and the information in it is
> confidential. Use of this email or of any information in it other than
> by the addressee is unauthorised and unlawful. Whilst reasonable
> efforts are made to ensure that any attachments are virus-free, it is
> the recipient's sole responsibility to scan all attachments for
> viruses. All calls and emails to and from this company may be
> monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent
> the opinions of Momentum Financial Technology Limited or of any other
> group company.
> 
> Links:
> ------
> [1]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [2] http://fca.org.uk/register
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi


More information about the Openid-specs-fapi mailing list