2° Workshop com OpenID Foundation (24/05/2021)

the technical workshop with the openid
foundation
team so uh first of all i would like to
to for everyone to know that this
session will be recorded as well
like as well as the as the last one last
week
so we're gonna share this this recording
later on the
on the open bank brazil uh website and
bill candy foundation channels as well
so uh first of all i'd like to to thank
again don and now the openid foundation
team for
for for giving us this workshop and the
support
and and please don't uh i think you can
get started with the opening remarks
well
thank you very much excuse me
thank you very much and it's a pleasure
to be with all of you
my name is don tebow and i'm with the
open id foundation
and i'm part of the openid foundation a
team
that includes gail hodges our executive
director
and mike les our program manager they've
been working very closely with
the miro team and i think have produced
some important results that i'd just
like to mention very briefly
and most importantly is that since our
first conversation
our first workshop we quickly moved from
from conversation to action and what i
mean by that is
um the lifeblood of this kind of work
and the openid foundation
is the contribution of both human and
financial capital
and already through the efforts of the
monroe team
and many of you we now are securing
funding
to extend the id
certification test suite to incorporate
some of the
specifications and some of the needs and
the contributions
of the brazilian team just as important
as the financial contribution the
contribution of human capital
of your time is particularly important
in this regard
and i just wanted to compliment you for
your agility
and stepping up and making these
contributions
one of the benefits of being a early
adopter
as brazil is working on
uh the efforts of those that have come
before you in australia
in europe and in the uk is that
early adopters really have an early
awareness
of not only what the specifications are
what the underlying technology
is but also and importantly how
decisions made about the standard
have evolved and will continue to evolve
as we all agree on the necessity
for a globally interoperable security
standard
which we're calling the financial grade
api
that early awareness i think translates
importantly into early influence
so because the brazilian community
led by moreau and others have jumped
into the discussion
with in the fappy working group the
influence of the brazilian community
is already being felt in our work
together
so i just wanted to point that out and
plan to do so in a blog that i'll be
publishing
later this week on the open id
foundation website
two other things if i may add today
you're going to take a deep dive
into certification test suite
and it's been our experience at the
openid foundation
that the adoption of an open open
standard is good
but not great it's when we can have a
trustworthy a trust but verify
proposition around the technical
conformance to that standard
is when we really have a powerful
dynamic in the marketplace
so the openid foundation's fappy
certification test suite is meant to
help
ensure technical conformance to this
important
uh security standards again just to
review
the design theory of our
certification test suite at the very
basis
it's a very basis theme
is open to anyone at any time
at no cost and that's fundamental to our
proposition
because it allows organizations and
individuals
to take that test well before they seek
to publish their results
we found that many companies large and
small use the test suite as an
internal quality assurance tool and
quality control tool
to make sure that their solutions and
their technology is fully interoperable
with this wider global ecosystem
so we think that a low cost
in both in terms of of dollars
but also at low cost in terms of time
will greatly increase the integrity of
the ecosystem at large but importantly
make for a faster integration a less
friction
friction inducing uh work product as you
begin to build
with these standards in mind lastly
and importantly the results of the
test suite are posted on the open id
foundation website
our directory of the organization's
in conformance with the technical
standards
is growing on a daily basis both in
terms of its volume
the number of companies that have
self-certified their conformance
to open id connect to fappy and to other
standards
but most importantly it offers an
authoritative
neutral non-profit source
so that anyone can see who's
certified what implementation or what
deployment to be in conformance with the
financial grade api
the open id connect standard and others
so having this test suite having the
directory available to all
and having it a truly open toolkit i
think is one of the contributions
that we now are collectively making
and lastly when i talk about
contributions i have to
talk i have to call out a couple of
individuals who you'll be hearing more
from
today um dr torsten
lotterstadt will be providing some
important information not only about the
standard itself
but really the uh technical context that
it
uh it exists in with the jarm spec
and other questions that you may have
about
how the fappy and soon the ekyc and
identity assurance standards
will live in the real world that you
operate in today
joseph heenan also a member of the open
id foundation
will take you through a real live demo
to show you what we hope will be a
fairly straightforward process
where you can self-certify your
conformance
to this important open standard
so lastly i wanted to make sure that i
recognize those two individuals
companies like athlete who provided
um technical support for this workshop
and for many uh implementations
worldwide
it really is a collaboration that
stretches across borders
it's a collaboration where best idea
wins
and while the work group has its share
of debates
it really offers the people that attend
the work
group an opportunity to learn from some
of the world's leading experts
about how open banking is
not only being considered in different
parts of the world
but importantly made trustworthy
made verifiable and made interoperable
so once again my compliments to all of
you
and i have to say once again the agility
and the way that you stepped up and
invested
your time and treasure in this effort is
particularly appreciated
we understand that brazil has plenty of
distractions this day
these days and to see your thought
leadership continue and progress
is really a model for us all to to
applaud
so let me turn it back to our organizers
and thanks again
okay thank you very much don uh
are they chandra cicada if you wanna
give any any opening remark now
or from the security working group
we can't hear you sorry
story of my life let's see okay guys
just a brief one once again thank you
very very much for
each and every one of you for ending for
this meeting
i think not all of us had the
opportunity to join
uh the the last session we we had
uh last monday so welcome
uh john thimbo and uh
joseph hina and everyone from openieg
foundation
thank you thank you really really
appreciate
your efforts uh of providing us
not not just having our backs in this
in this path but also ensuring that we
are doing it right
and helping us get on track this is we
really appreciate your your efforts
uh guys uh we have a a
a complex full
session so i give you back
once again thank you everyone
thank you alexandre i think now we can
we can start with
uh barton please feel free to
just start
foreign
sorry thurston uh we can't hear you
hey can you hear me now yes
perfect okay
we're not hearing now we can't we can
hear now
can you hear me now yeah okay that's
that's going to be the story of my life
because i always have handling problems
with microsoft teams so
i'm sorry for that and with that i'm
going to share my
my screen again
so can you see my slides yes
okay great so um good afternoon
from my side my name is tostad i'm the
cto of yes.com and a
long-term member of both the openid
foundation and the oauth working co but
the internet engineering task force
it's a pleasure to be invited today here
um to talk about
the financial grade api and i
intend to give you a comprehensive
overview and
look forward to answer your questions um
after my presentation
so what is what is fappy what is the
financial grade api
so first of all it's a security and
endotrope
intra mobility profile for oauth one way
you can ask
why do we need a profile for that well
oauth as it is defined
in rfc 6749 and 67 450
is basically a framework so it gives you
a set of building blocks that you can
use
to implement api access control and
authorization
but in order to really come up with
interoperability
in a larger ecosystem where different
parties act as relying part or as client
or as authorization server
there is a need to to define which
pieces or which features need to be
implemented or must be implemented by
each and every authorization server
so that a client knows when i'm going to
contact or interact
with one of the authorization servers in
the ecosystem
it will speak the language that i'm
expecting to the authorization server to
speak
and it also gives us it gives us the
ability to test
because oauth2 itself cannot be tested
for conformance for the before mentioned
reasons now that we have a profile we
can also test and and with that ensure
bit level interoperability uh for our
implementations
and security-wise oauth was
designed more with the social social use
cases in mind and
fabpy elevates the security of oauth to
the level that is needed for
open banking and as a working group
we largely rely on existing oauth and
open id connect specifications
what we have in the past and we are
doing right now
introduce new specifications uh in order
to
to complement existing ones and as we
feel the need for that
there are two versions of fappy 31 and
fappy 2.
and fabi1 goes back to 2016 when open
banking
started in the uk and subsequently
indian
in the european union and at that time
it was apparent that oauth was not
secure enough for open banking use cases
and
security researchers had recently
discovered
um vulnerabilities namely
the a ability to replay codes so an
attacker could
if it got access to a to make it to an
authorization code
inject that authorization code on a
different device and
in that way impersonate a victim
and the the second attack that was
discovered was the mix-up attack
which is especially important for open
banking use cases
because the attack is mounted in
scenarios where
a client will interact with different
asses
and mixes mix up as the name suggests
lead to the client makes him up to what
as
is is gonna talk it it's gonna talking
to and that indeed
in turn can be used to for example steal
authorization codes
and in order to copy those challenges
and other challenges
the happy working group um decided to
define a profile
that utilizes existing open id connect
security mechanisms
to enforce or to um
make the security of oauth stronger
the security profile was developed
in in tight cooperation and close
cooperation with uk open banking where
that also
adopted a fappy one and fabi1 was also
adopted by
fdx in the uk the u.s and canada by cdr
in australia
and recently in brazil
um around 2018 2019
the working group did a survey of the
different open banking
initiatives mainly in the european union
and there are a couple of them
the last time accounted was more than 10
different open banking
initiatives with different apis
different security profiles
the common denominator was all used for
open id of
of some sort and we did a survey to find
out uh how we did and what was missing
and what we realized was that open
banking
uh requires two features that fappy one
initially
did not provide uh deployments with
first of all the ability to specify
um authorization details
the the permissions a client wants to
wants to ask for in a very fine-grained
way that was missing
and there was also no way and then no
interpretable way
to manage grants and all the initiatives
that we
we surveyed solve that problem a bit
differently
some use lodging intent some use json
query parameters and so on
so and we thought well in order to come
up with a really comprehensive
um security interpreter profile we need
to provide something we need to to
define something
that can be used on a global basis to
come up with truly
broad interability and that was was
basically one of the um impulses why we
started the work
on on fappy 2. the second
the second impulse came from the
overworking group because the
overworking group
started to work on new security
guidelines
also triggered by the revelations
of security researchers about the
security
threats the security tax that i had
mentioned before
and around 2018 19
the overworking group had settled around
those security guidelines
which for example led to the fact that
no
that now the security uh or the
overworking coup no longer
recommends the implicit grant
to be used in in the law setup and also
recommended for example
pixi as a mechanism against
code replay and we thought it would be a
good idea to align with
with those security guidelines coming
from the oak working group
and also to increase um the scope of
fappy
and also broaden its usability to other
to other communities because there were
communities from e-health
e-government and so on ask asking us
well could we use
could we use what you guys have done uh
for uh use cases
outside of of financial uh on the open
banking we said you where well yeah
let's do that and what's the reason that
we started uh fabi2 and then fabp2 is
the next evolutionary step which
which is a growlerscop scope and we also
tried to come up with a solution that
now uses native oauth mechanisms to
protect against the same threats
that we had used open id connect
mechanisms in fabi1
in the end resulting in a in a much
simpler programming model
fabp2 itself was adopted in in our
ecosystem in the s ecosystem and we are
really
really pleased with the results all
right let's step into fabi one in detail
so fabi1 versus or to understand fabi1
one one must compare that to plane o off
as it is defined in the in the before
mentioned rcs
so first of all what fabp1 brings to the
table is it patches over security issues
on with with open id connect
uh features and and that y allows to use
oaf
in open banking scenarios the former the
security of
fabi1 was formally analyzed
by uh the same security researchers
that previously had uh discovered um the
mix-up attacked
it that's a group at the university of
stuttgart in germany
and happy one also adds
the ability to for a decoupled
communication or interaction with the
with the user
whereas oauth typically relies on the on
the browser redirect
that we also have in fact one clearly we
also have cba now
that can be used to reach out to the
user
using out-of-band communication to an
app for example
and to authorize things cba
typically best used after the initial
connection was established between a
client and an an ais and a user
and it allows for a much much
sleeker user experience and we defined
an interoperability
profile and as i pointed out previously
of itself is a framework it can't be
instantiated
and tested so what we did is we defined
in the fappy profile
what an authorization server must
implement what a client must implement
and also
some flexibility around that and then
based on that profile
the conformance test team was able to to
implement
uh conformance tests and uh joseph is
going to talk about
in the next talk well let's let's
uh take a look under the different
security mechanisms that we did we used
in fact p1
first of all we used signed requests
which means
instead of the plain get request that we
have an oauth 2
where all the parameters are sent as
your iquery parameters
unprotected through the user agent and
fabi1
we use so-called signed request objects
on the right-hand side you see an
example
that i have taken from from the
brazilian
profile definition so you've got a a
json object
that contains all the different request
parameter
namely scope and response type and so on
then you take the json object and sign
it and you can
also encrypt that and as far as i'm
informed in brazil
you use that mechanism so you assign
them and encrypt them
and then put this signed and encrypted
object in in the authorization request
this that's the parameter here denoted
in red
so that's that's the mechanic that's
being used for the for the requests
and for the responses coming back from
the financial institution
to the client fabpy uses the id token as
a detached signature
the id token itself as the name suggests
was initially
designed to convey identity data from an
open id connect op
to a relying party but since the id
token also
has a signature fabp1 uses
the id token as detached signature
meaning
when the id token is sent back in the
front channel
from the as to the relying party the id
token also includes
hashes of the other request parameters
you can see that on the on the right
hand side
so this this
id token contains hashes of the code
and the state parameter that came with
that authentication response
and together with the nuns that binds
the request
and it responds to a certain user agent
one can make sure that if an attacker
has
made up a response that can be detected
because in that case either the nonce
does not
fit the nuns that was stored
in the user agent or the session or
one of the hashes in the id token do not
match
and that helps to prevent code replay uh
mix up
and craft attacks the downside however
is
that we use a artifact that is intended
to carry user information
as a as a means to implement
transport layer security so for example
the id token must always contain a
subject value which is the user id
and in in those implementations that
use fappy just for api authorization
typically
not revealing a user identity they use
for example ethereal user ids here
and if one wants to use that mechanism
for providing user claims
um user claims might be added
to this id token which means those go
through the front channel as well
which in turn requires implementations
to
encrypt those in order to to protect
those data in transit because when the
id token is revealed or
asserted to the relying party the
relying party is not authenticated yet
due to the um the way the oauth protocol
works
the the the relying party is
authenticated in the next step
and that's why the over the op and and
the step where the id token is being
generated
doesn't really know whether the
recipient of the of the response
is the real is the real relying party so
that's a bit bit tricky and makes
implementation more complex
and since we we wanted to disentangle
um fat beat 1
used for api authorization and open id
connect used for identity use cases
we we came up with a new specification
which is called
judge secured authorization response
mode
and this response mode is different from
the
usual response mode in that it does not
put
the response parameters in the url
or that encapsulates them into a chart
which means the whole response in the
same way as there is
as the m that the whole response in the
same way as a request
is the chart and we put all the response
parameter in that shot so that that's
that's nice and symmetric in comparison
to the way
the signed request works so signed
request a charm
more or less works along the same lines
and as you can see in this case and
that's that's that's the difference to
the id token as detached signature
here in the id token as a touch
signature we've got this extra
parameters in the response
that are tied to the id token using the
hashes in jam
we just put everything in one container
and sign it and
we can also encrypt it and if you use
open id for identity
provisioning in conjunction with charm
you do not
need to send the id token and identity
data
through the front channel because it's
no longer needed as a security mechanism
all right so that's fabi1
and as already pointed out when we were
done with the first version of happy one
we did that open banking survey
we realized well there are use cases
that we are unable to
to to support especially our
authorization
and open banking goes goes largely
beyond scope values
no one really uses only scope values to
ask for
for example transaction data or to move
to to to
be allowed to to initiate a payment and
uh
that's what we need a solution for and
we also needed current management
capabilities
um in the in the lower part of this of
the slide you see
um examples how how they were solved in
in different initiatives so for example
uk
ob and also next-gen pc2 using logic
intent for that so they create a
resource
uh put all the data that they want to
get approval from the user for
in this in this restful resource and
then link that resource to the
authorization process and i think you
you're going the same direction
and there is also it was a completely
different pattern and
used at the polish api that use the
scope value and just some json
that they throw into the authorization
request
well and that was what we used as an
inspiration for fabp2
and as i said we broaden the coverage by
including
rich authorization and content
management
and we also put emphasis on simplifying
the programming model
so for example as you will see we
introduced
something called pushed authorization
requests
that are simple requests http post
requests
from the reliability from the client to
the ais
that allow to lodge the authorization
request
with the aes which allows us to
avoid any kind of signature for sending
the requests
to the as clearly resulting in a much
simpler programming model
and we have a well-understood and
well-defined security
here in fappy too so what's the
difference to webby one because i i
mentioned that fabi1
was evaluated for security that's true
but it happened after the fact so the
analysis had
shown fabi1 fulfills all the security
requirements that's a secure protocol
and you can use that
in p2 we wanted to come up with a simple
yet
secure protocol so we first of all
defined the attacker model
and then designed fabp2 in a way that is
still simple
but can fully protect against this
attacker model
and that's why fabi baseline has the
same protection
level security wise as fabul
flappy one advanced and happy 2 is more
versatile because we added a
new mechanism that that that we're
emerging uh for example around center
constraint access token so in fact
one you can only use mutual tls for
oauth
now you can also use um depop
which is a mechanism that works on
application level which might be
beneficially
especially for deployments in in public
cloud
scenarios so let's let's take a look
under the specific part so push the
authorization request
you can see it on the right hand side is
is a super simple mechanism
so instead of sending the authorization
request as in redirect
you put the same data the same payload
in a post request and just send it to
the as
right just a tls connection so you've
got
all the all the advantages of tls and to
ntls
integrity protection authenticity
you can authenticate the server you can
authenticate the client so this is this
is really
uh a lot of buck for the bang a lot of
bang for the buck
um and what you get back from the from
the aes
is is an identifier of that request it's
called the request ui
and you just add this request ui to
redirect
and this mechanism can be used to
replace our signed authorization request
then we have rich authorization request
um
and on the right hand side you can see
what what that makes i mean
in the end what it does is in the same
way as a lodging intent is a json object
um describing the intention or the
the the privilege as a a client asks for
um reach authorization request allows
to to to use that json object and just
add it to the authorization request you
can also
you can even add multiple of them so you
can add a
json object asking for account
information access adjacent object
asking for payment initiation
and the third one asking for certain
identity data
in the same request so that's that's
really simple and
it does not need a lot of scaffolding to
to lodge that stuff or something like
that
it's best used in conjunction with power
because they then you can you can fet
the the
voluminous requests through a post
request to the aes
so rich authorization request in the end
is scopes
just made more more powerful because
instead of just using
simple strings you can use json objects
to describe
what you want and the structure of those
json objects
can be application specific deployment
specific
uh scheme specific jurisdiction specific
because we've got the type management so
the type element here in the
in the first in the first uh a line
um is what you what you would use to
denote the type so it could be for
example here i
i took the uh the liberty to copy one of
your examples
uh for a lodging intent and made it a hr
object
so you could for example use brazil open
banking standard data
to define your schema and then just
throw your data
in that in that original authorization
request it's pretty simple
and then we've got grant management and
the grant management
then is the facility that allows to
manage and make a transparent and
explicit
the grant that a is manages
on behalf of a user and a client so if
you're asking for
for privileges in a certain transaction
then you can get back
a reference to what is kept with the es
you can update that you can add new
privileges
you can query the current status of
those this grant that is kept with the
es
and you can kill it um that mechanism
can be used for example to
to create dashboards on the client side
or
to for example update existing grants or
consents
so we decided to go with the grant
management term instead of
consent because grant is the is the term
that's that's being used in oauth
for for for that for that topic and we
did not want to come
into the complex topic of delineating
the legal consent term from a technical
consent term so that's why we went with
the
with the um with the term grant
management and that's how it's
how it looks like so if a client
asks in in authorization for certain uh
privileges
can do so using a rich authorization
request that's seen in this line
it can also ask the as please give me
give me handle for the underlying grant
so the client does not need to do that
because if the client doesn't have a
need for inspecting the grant or
deleting the grant or having a dashboard
it does not
need to to worry about that but if it
wants to
it's it it sends the parameter grant
management action create
and the as will in the token response
provide
the client with a grant id and using
this client.grant id
the client can use the grant management
api to for example query the status
which is a simple grant get
on a certain url with that id or you can
also use a
http delete to revoke that grant which
means
the whole grant with all the privileges
attached goes away
and the ais is supposed to even provoke
all the
refresh and access tokens associated
with that grant
and a nice feature is also you can also
send the grant id
in a request to the authorization server
along with the grant management nation
update and tell the es
here's a grand idea i obtained that
grant previously and another transaction
and whatever i'm asking for right now
please
add it to this grant so if your
application for example had to ask for
access to the list of account and is now
asking for
the transaction details of two of the
accounts in that list the ais can merge
all those privileges together which
means in the end you will getting
access tokens that you can use for
occurring the account list again
and also accessing uh the transaction
list so that's
that's a nice feature to also control um
how the access tokens are being issued
by the ascent
to make sure that fits your programming
model
you can also use that that feature for
example to ensure
that the same user gives the uh gives
the privileges or authorizes the
privileges than before because
implicitly
there's always always a user associated
with a river grant
all right and then as a last mechanism
that that already existed before we
started with happy
is uh pxe and pixy basically is a
a mechanism where a transaction specific
nuns
is used to tie an authorization
transaction to a certain user agent
it's been invented to pro to prevent
impersonation for mobile apps but
now due to the of security pcp it's
recommended as
the default mechanism for countering
code replay and csrf so what the
application needs to do it creates a
random value
it sends the hash of that value in the
authorization request
you can see that here and it sends the
the
um the nuance itself in the token
request
to the authorization server and for
those of you that know
how the nuns works in open id connect
the nice advantage of pixi
over nuns is first of all
the clear value never goes through the
user agent because we use a
um we use a hash value and the security
check is implemented in the as on the
server side
which means the ais can make sure things
are implemented securely even
if the client developer didn't do so
right a quick feature comparison um
so in the second column you saw cfappy
one uh in the in the in the last happy
feb2
we've got all the different um security
attacks that
um uh protects from
and
what you what you what your main
takeaway should be
is that fappy mainly uses open id
connect mechanisms
involving signatures um application
level signatures to protect from those
different
attacks where sfp2 uses
simple mechanisms based on random values
nonsense and tls to protect from the
same
from the same attacks in a bit simpler
way
and richard authorization data and
constant management
is uh provided in fact ii using a
standard mechanism
whereas in fabi1 um yeah different
different um bodies employ different
different solutions for that and just as
a
quick view on how that look looks like
on the on the
execution level on the left hand side
you see how a
an authentication authorization is is
being
performed using a lodging intent and you
can see that
with the lodging intent the application
first requests an access token
using the client credential grant and
then
using that access token lodges
an intent at a certain api endpoint for
example
for the account access consent and
the consent id that is returned from
that from that api is then sent
in a signed authorization request
towards the financial institutions when
the response comes back
the application needs to check the id
token signature
the c hash the attach and the nonce
on the right hand side you see that the
creation of the intel of the lodging
intent
and the initiation of the authorization
request
collapse in a single step in fabp2
which means that the the client
application does not
need to use a client credential to get
an access token to create a resource
which also means the aes does not need
to support client credential
instead the client authentication method
is used to lodge
all the authorization data that are
needed with the authorization server
directly
and then the id of that of that
authorization request is sent
into the as and on the way back the
check
to be to be performed is is pretty
simple
you just use the the code verifier
and send that along with the code to the
authorization server on the
authorization so i will tell you
whether this code was injected or not
all right um let's take a look under the
milestone plan so we're heading for
that we already have finally published
therapy one uh in february of this year
and uh now we are aiming for final
publications for jam
jarm and c-bar and pushed authorization
requests by
mid of this year and we are working hard
on fanfappy2
um to uh come up with first
implementor's draft
for fappy baseline advanced uh mid this
year along with
a working group loss call for rich
authorization requests
in the oauth working group
um regarding adoption of fappy and the
ecosystems
um it's from a standardizations
expert's perspective i think it's quite
clear i would always recommend
to use the latest uh stuff because
it has the most innovative functions but
there are reasons to
to to adopt fappy ones so for example if
vendors already support that you want in
the ecosystem
and you want to use a mature existing
standard that already has all the
conformance testing and so on
um happy 2 is your choice
if you if you're looking for the easiest
to implement
security interval or interoperability
profile
that exists today for oauth and
if you're looking for a ban a bundle of
of ease of use and
feature richness for example including
authorization requests rich
authorization requests grant management
and so on
and flappy 2 in my experience also
works better together with openid for
identity use cases than fabi1
because of the of the um yeah
use of open id connect functions for
other than identity use cases so if you
want we can dig into that
later on but hey
there is no no no needs to really decide
whether you go for one
hello excuse me yeah
i think i think we hear you know
but there was a question from someone
whether
he could quickly jump in
so i assume someone wanted to ask a
question
coming releases we are going for p1 so
just to
to make everyone aware of the path that
we are following
okay that's that's my last slide so can
i kind of complete that and then we can
i think
absolutely and enter questions and
answers
um so
what we already have seen is that
ecosystems that
that previously had adapted for p1 also
incrementally adopt
um fabi2 features so for example
australia
adopted part with happy one and as far
as i
was informed you're also at least
considering to use par
in conjunction with happy one which
makes a lot of sense because it's easier
to use than
signed request objects and what also
comes into mind is to use fappy one in
conjunction
with rich authorization requests and
grant management because that way
one can replace lodging intent with a
more
solid-based approach and clearly both of
our protocols can be
run in parallel if that is needed
all right and with that i'm coming to
end
of my presentation and uh
we can take some questions if there if
time permits
him
people people are writing some questions
on the chat
uh ralph and mike and other people
are helping to to answer that i think
that maybe
we can we can go ahead with joseph
presentation and
at the end of the workshop we have 20
minutes for
for a q a session as well so
we i think we can we can proceed like
this
so it's joseph uh feel free to start a
presentation
all right thank you um so yeah uh the
aim of today's
presentation from me is really to uh
dive in and go in-depth demo
through actually running the conformance
suites are going right through all the
steps from
having absolutely linked to actually
running a test and
if we have time just quickly showing the
submission process as well
so first i'm just going to repeat a
slide from my presentation in the
previous workshops because
that may be people that weren't in the
first workshop
um so it before you start fappy
certification
it really is pretty important that
you're pretty confident you're fappy
compliant so
ideally using a fappy certified version
of your vendor's product
um if you're not using an existing fappy
certified solution
then you do need to look at making sure
you actually have all the bits
implemented so particularly the recent
standards like
mtls sender constrained access tokens
and the signed requests i will not be
supported in
older kind of oauth2 gateways that you
might already have deployed
um so just bear these things in mind
because
if you don't have support for some of
these things you're really not going to
get very far running the conformance
tests
so the instructions are all online
and we'll share these presentations
after i believe so you can
have the links the the list of
certified implementations is also
available
online and it looks something like this
although it's obviously
a lot longer than this so i've had to to
crop this to
hopefully so it's readable so there's
various different
fappy profiles depending on which type
of client
authentication you're using your mtls or
private key and whether you're using
pushed
authorization requests or not and then
there is also ecosystem pacific
variants of the test so there's one for
uk open banking
and one for australia cdr
and we'll be adding a brazil
pacific certification there in uh due
course
um so the certifications that exist
from various different
companies and vendors um but
one thing i'll draw attention to is that
we had our first certification from
brazil already last week
um which is obviously great um
and perhaps i believe we've got uh
danilo from uh
finishes tech on the call so i'm going
to put him on this the spot a little bit
and just ask
ask if you can quickly say how you found
the process danilo
thank you joseph good morning
foreign
i just said that what we done in the
last week
and also that i enjoyed the the open id
foundation
with the guys and say how how important
it is to do the
the confirmation the confirming test and
how it is important to be
compliant with sapi and i i sure that
everyone knows and
how we're going to work in the
portuguese language
so i i'm your arm here in brazil to to
help them
without any any
uh any types of contracts or something
like this
just help the people to get through
their confirmed steps and make them
work okay if you want to say something
please let me know
i'll be right here
great thank you very much danielle
so yep so uh without further ado we'll
go on to the demo
um so the first step is to create the
client
authentication jwks this obviously
assumes we're using
um
i'm sorry that sentence wasn't going
anywhere ignore that um so we're using
uh an online tool called make jwk.org to
do this
um various alternative tools your vendor
may have a
preferred client and i believe
encryption is
mandatory in brazil so we're going to be
creating two keys for
each client one for signing one for
encryption
so this is the jwk tool it's
just a case of selecting the key use you
want
selecting the algorithm to be used i
believe that's always ps256 in the
brazil security profile
just need to create a key id which is
basically a free form file
we generate it and then we just need to
copy the various generated keys ready to
use later
in configuring the client in
the authorization server and also in the
the conformance suite
and then we repeat this process twice
doing it again for an encryption
key exactly
the same
so next thing we need to do is create
mtls keys and certificates so
i'm just going to use openssl on the
command line to do that to create
self-signed certificates again
there's different ways to do this um i
believe in brazil you
you need um certificates signed by the
the central directory so
there will be extra instructions you
need to follow
uh generate certificates that it's happy
with
but here's the kind of open ssl command
we're going to run
again it's a pretty straightforward
process
it literally takes that long to generate
the key and then you just again need to
copy the
the private key and the public part
for later use
um so the next thing is to create and
configure the client in the
authorization server
um so for the purposes of
demoing i'm going to use a an
authorization server from
authlete which they provide
for the certification team in the open
id foundation
and we actually use that server to test
the tests as we
developed them because obviously are
compliant with all the fappy
and flappy seba specifications
so in this case again i'm just going to
manually configure using a client
management
console if you've actually got a fully
set up fappy
authorization server then you may well
find it easier
and i think in brazil it's also
mandatory to support the dynamic client
registration so
it maybe you may be able to use uh that
to register the client instead of doing
the manual steps
so again this is ortholite's console so
you just create a new
application put in a freeform client
name
um i should say i'm using the australian
variant for this but the brazil
uh setup is basically all the same steps
so
it's a confidential client we want
we need a web application
i need to fill in some of these files
like the logo url just depending what
you're doing
you need to enable tls certificate pound
access tokens
you need to select the the grant types
that are supported so
uh so you need authorization code
i think in brazil you need client
credentials to register the pre-lodged
intent id
you need to refresh tokens i think seba
is optional at the moment i believe
that's going to be required later in the
year
and then just support the required
response types as well
so for normal fappy it's only code id
token that you need to have supported
just register your redirect uri so the
interrupt instructions for the suite
tell you what form to put these
redirect uris in there's a
part here that's specific to your tests
that your tests don't conflict with
other people
which is called an alias in the
conformance suite
and we just select
the response signing algorithm
and client authentication method which
is private key jot in this case
again the sign-in mechanism to use for
the client
authentication
and then i've got request objects which
are mandatory and
mappy
select the the signature algorithm which
again is
ps256 always in brazil i believe
and you can also select your encryption
mechanism as well
configuring the id token signing method
which again is
ps256 you can hear that a lot
the id token signing as well
it's a bit of an involved process but we
did want to give you an idea of exactly
what you do doing this from
absolutely nothing so the next step is
configuring the jwk for the client so
this is the thing we created earlier the
public
key from mike jwk.org
and we need to put in the encryption key
as well and just
in this case we need to turn it into a
jwks so we're just
making it an array
within an object where it's in the keys
value
you'll get used to doing this kind of
quick json manipulation if you do much
in
the open id space
let me configure anything on that these
screens obviously you can
configure policy uris and things like
that if you need to
i'm not going to configure any sieber
this
demo
just to configure the scopes the
client's allowed to use
as well so in this case i'm just picking
open id
and i'm using a payment scope so again
sorry i'm using accounts and payments um
so there'll be
brazil pacific values for these uh i
would imagine i've not quite got
speed on the brazil security profile yet
just configure access token durations as
necessary as well
let me just create the client
works successfully and then just at the
bottom of the screen here you can see
it's assigned a client id so we just
need to remember that
uh because we'll need that for the
conformance suite configuration
later on and you actually need to run
through this whole process twice because
for the conformance testing you need to
validate the clients
which sometimes surprises and confuses
people but
that's because part of the certification
test test some of the security
properties which means we need to try
using valid objects from
one client with valid credentials from a
different client and make sure that they
are
rejected so things like access tokens
should only be
usable by the client they were issued to
so that's it so the next step is just to
create the conformance suite
configuration
so this is just a
form we need to fill in so this is what
the certification suite looks like once
you've logged into it
so you just select the test plan you
want to test
which in this demo i'm going to pick
fappy read write implementers draft 2.
um brazil is actually going to be using
fappy final which we'll be
launching the tests for pretty soon but
there's only minor differences
between the second implementers draft
and fappy final
and just select the client
authentication methods whether you're
using
par or not the profile
and then we get this form to fill in
which is a it's a dual form that has a
json representation and
form fields so um i've
filled in a few values using the json
and i'm gonna
edit a bit more using the interactive
form
every field has a help field you can
hover over which gives you clues as to
what you should be entering for each
field
so there's just a free form description
here that we can fill in with anything
we want
there's this alias value here which is
the thing that's unique in the redirect
urls to make sure that your tests don't
interfere with anyone else
then we need to fill in all the values
we got from the previous steps of the
client id
that we got from the authorly console
the scope values we want the conformance
suite to use
the private keys for the the client so
that the conformance suite is able to
to assign objects as the client and to
an encrypt object so again there's two
keys and we just need to
form them into a jwks by adding
a wrapping object with a keys
value and uh we need to make sure we've
got this use
encrypt field in one of the keys so that
conformance suite knows which key to use
for signing and which key to use for
encryption and we need to make sure we
have this
ps256 value as well so it knows what
algorithm to use for signing
just editing the json to make this a
valid jwks
and then we just add the tls
certificates that we generated in
openssl
as well so first the certificate and
then the private key
and then in some cases you'll need a
certificate authority field as well
just depending uh if the server needs it
to be passed or not
you can see i'd already added in the
second client here
and the last thing we need is a resource
url
which is just the end point we end up
testing on the server
and then we create the test plan and
this gives us a list of tests
ready to run so i'm just going to switch
into
a live demo now so i can do something a
little bit more interactive
just change my screen sharing options
i didn't want to fight too much by
trying to do the whole process live all
right so
this is the the home page for the
certification suite
log in with my google account
it's remembered the values i used before
writing the test plan and then we just
run tests by
pressing run new test
and it runs and the first test is a very
simple one that just
validates the discovery endpoint
and as we scroll through the test you
can see absolutely everything
the test does drill down into the detail
of what's going on
so you can see there was a http request
for the
server configuration you can see the
actual url it requested
http method the headers request body
and then the exact response we get from
the server
with the headers and the actual response
body
you can then see how the suite actually
passed it out
the exact values it believes it got in
the past form
and then it runs through doing checks on
each of the values
you can see exactly what was checked
if you've got a failure would show you
the detail of
what the values are that your server
returned
what the expected values are
so it's pretty straightforward and
obviously this test passed as we'd
expect
so then you just continue the plan which
will run
the next test which is it's a bit more
so
this test actually goes through and does
two different
authorizations with the service like a
proceed with
test button that's going to take me to
the the authorization endpoint url that
you can see here which
has a assigned request object various
other parameters that are necessary so
this takes me into australia's demo
authorization service
just log in obviously
if this was an actual bank server you'd
expect a more complex
login process probably involving a
second factor or something at some point
this is just a test service all i need
to do is
log in and press the authorization
button i get redirected
back to the conformance suite i can go
back to my
test log for this particular test i have
to do this process
twice let's go through and authorize
again
and you can see this test has passed and
again you've got
the full history of everything that
happens
it's quite a long process because it
really does
put every step but we can look and we
can see the exact
url we went to see that the exact
redirect we got back nothing in the url
query we've got the response in the url
fragment as expected
and then again you can just see the
details of all the tests that run
and just to show what a failure looks
like i'll run this test again but
do something wrong so just
instead of authorizing the request as
normal i'll deny it so again we get
redirected back to the conformance suite
but then you can see
i've failed the test there's a failure
summary here that says
the authorization was expected to
succeed but we got an error back
and if i click on that then it will show
me to jump
to the thing i can see what happens you
can see we got
an access denied error the end user
denied the authorization
response hopefully
at that point you realize you pressed
the wrong button you can just go back
and
re-run the test
and hopefully do it right the next time
then
you can go back to the full list of
tests and it's very much the same
process for these
some of the tests do require you to do
different things so this test requires
the user to reject the authorization
just follow exactly the same process but
make sure you do press the reject button
this time
again we do that twice
this comes a very repetitive demo now if
i carry on because
there's just various different requests
that
carry on um
one example of perhaps something that's
slightly different
is so we can see some failure so try
passing a request object without a
expiry parameter
when i go to the authorization server
here it doesn't ask me to
log in because it just directly
redirected back to the conformance suite
with an errors
there's nothing further to do in that
case
and another example you'll see will be
yeah if we look at a test that checks
the redirect uri is registered
what happens in that case is that you
actually get the authorization server
showing an error
so again this is a demo server so in a a
real bank server you'd probably expect a
rather more
friendly error message that just tells
the user something went wrong and they
should probably go and check with the
third-party provider
but when you're actually doing
conformance testing what you just need
to do is take a screenshot
of that error you go back to the
test and then there's just a upload
image button
and you just upload a
screenshot of the error
and the test goes into this review state
that shows that
there's a manual screenshot when you
submit your certification
request to screenshot is one of the
things that we just manually check
is correct so there's no automated way
to
check if you're showing exactly the
right thing
and the test just goes into the finish
status
and that is
essentially it says fair few tests
to run um but you can they're
they're all some variant of one of these
tests and
it's very much the same process
and again as as i mentioned i'm at least
for your
internal kind of pre-certification
testing you can
automate all this you can run this in
your ci um
so you're not having to do these manual
steps every time
but generally for your final
certification when you're running
against your production
authorization server you'll need to run
it manually usually just because you
can't automate
the login process on a production server
because it usually needs
a second factor to authenticate that
kind of thing
uh and that is the end of the demo
so i think we have uh 15 minutes
scheduled for
q a now if i recall correctly
exactly thank you joseph uh if
anyone can please
go through the questions uh we have
bernardo
good morning afternoon for you guys um
i have a question about this education
program
we've been running the without pv on the
floppy
profile and
it looks like we've passed all the the
items in the test
and the conformance test but we want to
know if it makes sense to pursue the
certification now because we know that
um at least from my point of view we're
not
uh not accomplishing anything because
the one that we have that we must search
certified still on development
and i also have another question but if
you want to answer that first
uh yeah i'm sure that saves me having to
remember too much
so yeah it's absolutely brilliant that
you're running the tests already
and passing them um i think
just on friday we published uh the kind
of first
beta version of the fappy final test so
you may want to try running those
because there's just a few changes in
fappy final versus
the second implementer's draft um i
believe the brazilian requirement is
that you
are complying with the final version of
the spec
but yes no point certificate they're
certifying until
uh the kind of the brazilian version of
the tests
are available which obviously go through
the the pre-lodged
intent and passing that intent in a
structured scope that
is necessary in the brazilian security
profile
um but we're hoping to have those tests
live in
uh i think it's about two and a half
weeks
as soon as we can hopefully i think the
security profile i think is still under
a little bit of flux but
i don't think that will cause us any
problems
um okay and my second question is part
about app trap i've
i think the uh the blog posts
you wrote that and i was viewing
the benefits of siba against uh app to
app integration
with redirect flow and one of your
points is that
it at least from your point of view it
doesn't make sense to use
cpa if the consumption device and the
um the authentication device is the same
um
can you elaborate more about that and is
this still your opinion
uh yes i certainly can
i also have a presentation i did
last year identifiers that i'll share
the link for in church
into a bit more detail on the subject as
well um
so
yeah if if the user is actually already
on a mobile device
and wants to link a third-party app to
their bank account
then app to app is really the most
efficient way
of achieving that you end up with the
user
going directly from the third-party app
or the third-party website directly into
the
the bank's app authorizing there and
then going directly back
if you compare that to the cba flow then
what you'd
see would typically be
the user starting on the third party
website
they'd kick off the process to actually
link the bank account
they then see a push notification come
in hopefully promptly
they'd hopefully click that push
notification it would
open the bank's app and obviously they'd
then do the same authorization
process there but then at the end of the
authorization process
they'll have to manually switch back to
the third party app or third-party
website
so you've added in a few extra steps
there compared to fappy sieber
sorry compared to comparing flappy seba
to app to app
so the user had to wait for the push
notification they had to
manually click the push notification
and at the end of the process they had
to manually navigate back to the third
party
whereas obviously in an app to our base
redirect flow
the user just gets automatically sent
from the bank's app back to the the
browser or the third party app
i think we have a question here in the
chat uh alex ascencio
has uh our detailation response errors
already defined for
european bank in brazil maybe
somebody from the working group the
security work group the
answer there
yeah i mean i would presume that the
errors are pretty much all using the
standard
oauth 2 errors um
certainly from the point of this
certification suite i don't think we're
expecting any new errors but yeah please
go ahead
exactly mr henan in fact this is a work
in progress
uh the the uh
the team is working on detail giving
details to the
brazilian open banking security profile
it is already
uh published in the open banking
developer portal sure it's a draft
and it is to comply with with the
the the current specifications of alpha
p
and fappy and the the layers that
we we think they're particularly true to
our implementation
are described in this doc so if it's not
specified
in the brazilian opinion banking profile
it it is
covered by the the default uh
specifications
thank you very much
any further questions guys
well if we don't have any more questions
i do have a couple more slides i can
just share a bit more detail about the
conformance suite if that's
okay i think i've showed the right
window there let me try that again
so again this just goes into a bit of
detail about some of the checks that
the conformance suite runs
some of which is based on experience in
the uk
obviously people struggle with some of
these things
one of the first checks it does is
checking that the the issuer
is correct so the issue is a value that
comes from
the authorization server metadata uh or
the
the got well known slash open id
configuration
um there's a strictly defined pattern in
the specs as to how that matches
between the location of the open id
configuration file and the issuer that
are specified in
id tokens just to make sure that
it's one of the security checks
basically that makes sure that
the relying party is getting id tokens
that match
the expected location and that stops
various phishing attacks
that's something that um some people
think that the open id configuration
file can just be kind of put anywhere
and that
the issuer is somehow related to the
host name of the server that runs the
authorization server and that's
not always the case it's just
the issuer is very much the value that's
in the id token
and the location of the open id
configuration file those two things have
to match
um yeah one thing that we
rather embarrassingly saw a bank in the
uk fail was that
so you have to publish your private keys
on your
uh in the jwks uri that you list in your
open id configuration and
it's only your public keys you should
list in there
the bank in this case had managed to put
their private key in that location
which is not really a good idea but
again it's
it's a good example of why it's
worthwhile running
the certification suite because these
kind of things that
it's kind of understandable that
somebody might make this mistake if they
didn't
entirely understand what was going on um
and the certification tool
will pick it up and stop it becoming an
embarrassing security problem
and then there's lots of checks around
the processing of the
request object so that the request
objects have to be signed
but for various reasons of backwards
compatibility you also have to
put pass the values outside the
authorization request as well so
the suite actually tries passing
different values inside and out
obviously expects that you only use the
value that's inside the signed request
object and ignore the one outside which
obviously could have been
tampered with
yeah a common error with jwts is to
accidentally end up accepting ones that
have alg
none which is basically an unsigned jwt
which obviously
conveys nothing at all about
preventing tampering so again
the sweet tries one of these and checks
it does get rejected and
that is a test that we've seen people
fail sometimes
just because depending on the different
jwt
libraries they present these things in
different ways and it's not always
obvious
and then there's a there's a whole bunch
of further checks like that
yeah it's the actual number of checks we
do is
really quite long
so again i thought that just might be
useful to give people a little bit more
insight into some of the checks you'd
see so we had the spare time
all right any further questions
i've got one last comment if i may
sure come on i wanted to
use this quick note to invite those of
you that are on this call
to to join this effort of course we'd
like you to join the openid foundation
as an individual
or organization and to do so requires
um
very little commitment but we hope an
investment
and the opportunity whether you're a
leader or a lurker
in these work groups and in this effort
is really first and foremost to learn
more about these important standards
and to contribute to educate yourself
and your team and your organization
so again please consider joining the
openid foundation
and we say help shape the technical
standards
that will shape the brazilian open
banking ecosystem
in the years to come so thank you for
your time and attention and
thank you again to our our presenters
um and to our many new colleagues on
this call and
the leadership of minnow and others
thanks all thank you very much don
joseph if you have any any comments here
um yeah so i guess the final word is
just if
if you have any issues running the
certification tools the open id
certification team is here to
help um the the best way to contact us
is via email i've just put
the email address into the chat but it's
also scattered all through the
the um instructions and so on as well
um so yes we're here to help if you have
any
problems with the tests
yeah i think that's it so i look forward
to
receiving lots of certification requests
from you all
okay thank you very much joseph don and
another plenty foundation team
uh alexander they know if you have any
any
clothes in the markets max here sure
sure just i'd like once again to thank
you guys
uh thank you thanks the openid
foundation
and the fappy working group for uh
helping us
and having our backs in this this
endeavor that we are taking uh we know
the time is short we know the hard work
everyone is putting to make
uh open banking brazil uh
a part of a part of our history so thank
you once again
for for helping us achieve this
this endeavor and thank you every single
one of you for
attending to this following meeting and
we see you around
thank you very much thank you very much
thank you bye bye