[Openid-specs-fapi] FAPI - Open tickets [Anoop Saxena] update

Nat Sakimura nat at sakimura.org
Mon Aug 15 02:20:04 UTC 2016


Thanks Anoop.

It really helps. I would appreciate if you can add these to the tickets 
as well for the record.

Comments inline

On 2016-08-14 05:48, Saxena, Anoop wrote:
> Hello Nat,
> 
> These few comment and suggestion on ticket assigned to me
> 
> #2 - Pagination (Total Pages, Total and page)
> 
> · This features enables servers to send the response in parts
> (chunks).
> 
> · IF the account too many and the implementation of API that returns
> accounts and transactions. It might be daunting task for server to
> query & collect all data in one query result.
> 
> · None of the implementation so far has shown interest in this. But
> is an optional feature added.
> 
> · I am ok with removing if it is confusing.
> 
> · Total Pages - total Number pages resulted for query
> 
> · Total - Number of accounts records
> 
> · Page - Current page number returned.
> 
> · I will try to find if this can be represented in mock up example if
> we decide to add to FAPI.

Thanks. I will await your example.

> 
> #7 - Open data
> 
> · Once I get some samples from Henrik.

Henrik, and possible Dave, could you please follow up?

> 
> #17 - In line with FFIEC (Federal Financial Institutions Examination
> Council) guidance on Authentication to mitigate security risks
> 
> · I think - all this line was indicating that ... The DDA + OAUTH
> implementation is in line with FFIEC guidance of "Authentication" to
> mitigate security risks.

Thanks. Let's make turn it into a note with a full sentence.

> 
> · We could replace OPEN ID point of view or remove...This document is
> more about Data API and not about authentication methods which should
> be part of OPEN ID.

Right. BTW, it is OpenID and not "OPEN ID". We are a little picky on
this one since OpenID(R) is a registered trademark we need to defend to
keep it freely useable :-)

> 
> #20 - Meaning of the Surrogate Identifier Clause not clear
> 
> · Surrogate identifier is recommended to be sent in place of the PII
> (personal identifier information) such as bank real account number.
> 

The way I read it, we do not have to talk about the "surrogate 
identifier"
but just talk about "access token". It is even more true when we 
consider
the "user_id" which is talked about in issue #22.

Also, it seems to be constraining the Access Token and Refresh Token 
more than
RFCs does. Let's do the rewrite and see if it really does.

> #22 - Undefined OAuth response parameter "user_id" appears in the text
> 
> 
> · This is custom attribute added to OAUTH token response.
> 
> · The use case :
> 
>  o Since clients are taking customer to bank website.
> 
>  o The customer enters user name and password on bank website and
> clients app only gets a token without a user identity
> 
>  o If clients have to present back bank website during
> re-authentication flow. Customer may enter different set of user name
> and password which results in totally different set of accounts data.
> 
>  o This user-id is unique identity of customer that got authenticated
> within OAUTH flow to get token.

I see. So there probably is an authorization request parameter such as 
`user_id` as well.

I really wish if DDA WG used ID Token instead so that the processing
was same with other use cases, as well as being protected against code 
injection attack,
IdP mix-up attack etc.

As OIDF standard, we probably should replace user_id with ID Token and
put a NOTE that DDA uses `user_id` instead.


Best,

Nat

> 
> Thanks,
> 
> Anoop Saxena
> 
> Architect
>  INTUIT | SIMPLIFY THE BUSINESS OF LIFETM
>  o: 818-436-8524 m: 8182974282


More information about the Openid-specs-fapi mailing list