WEBVTT

00:00.000 --> 00:19.000
Okay, can you guys hear me?

00:19.000 --> 00:20.000
Yeah.

00:20.000 --> 00:21.000
Okay.

00:21.000 --> 00:25.000
So Alona's next speaker is Milan Yackelby.

00:25.000 --> 00:29.000
We'll describe some experience on YDC.

00:29.000 --> 00:32.000
Here's some real use cases, right?

00:32.000 --> 00:33.000
Yeah.

00:33.000 --> 00:37.000
So, first of all, I'm really sorry for my French accent.

00:37.000 --> 00:39.000
I will do my best.

00:39.000 --> 00:40.000
Okay.

00:40.000 --> 00:48.000
So, the point is, so I work for like a trio for years on kick-look and the WSU2.

00:48.000 --> 00:53.000
And with the real issues and the understanding of the lighting protocols and stuff like that.

00:53.000 --> 00:59.000
So, it's kind of an eventorist of the possibilities offered by the protocols.

00:59.000 --> 01:01.000
This is the idea of all ID.

01:01.000 --> 01:02.000
So, there is no specific demos.

01:02.000 --> 01:13.000
I will explain in this as much as the time let me do what you can do with the OS2 and open ID connect.

01:13.000 --> 01:15.000
Okay.

01:15.000 --> 01:18.000
So, our pronunciation statement is very basic.

01:18.000 --> 01:24.000
So, our user wants to access this bank account to a management console.

01:24.000 --> 01:32.000
And you want to see to also display data from any kind of an older bank account data.

01:32.000 --> 01:34.000
So, also do so.

01:34.000 --> 01:45.000
But, the bank applications will delegate this authorization and authentication to specialize the authorization server.

01:46.000 --> 01:47.000
Very basic.

01:47.000 --> 01:56.000
And to do so, they will rely on a bus or reader OS2 and open ID connect.

01:56.000 --> 02:02.000
So, I want to go to deep on what are specific,

02:02.000 --> 02:04.000
on open ID connect or OS2.

02:04.000 --> 02:08.000
But, basically, it's based on a challenging design,

02:08.000 --> 02:17.000
sign the JSON object, Jots, and rely on a rest-a-a-a-a-a-a.

02:17.000 --> 02:22.000
So, above the concept, in a study there is a force rules.

02:22.000 --> 02:25.000
There is the resource owner, which is the end user.

02:25.000 --> 02:28.000
There is the authorization server.

02:28.000 --> 02:35.000
As you can see, there is the client's application that wants to retrieve data in the name of the end user.

02:36.000 --> 02:43.000
And finally, the resource server, the server, which actually hosts the data of client's own to access.

02:43.000 --> 02:50.000
So, please note that in open ID connect, there is no concept as a client's resource server.

02:50.000 --> 02:51.000
But, it's managed.

02:51.000 --> 02:52.000
I'm sorry.

02:52.000 --> 02:55.000
In to what you call the relaying party.

02:55.000 --> 03:03.000
And very large overview will be that the resource owner, through the client's,

03:03.000 --> 03:10.000
as far as you can, the authorization server delivers the token that will be then used by the client

03:10.000 --> 03:14.000
who access the resources, hosting the resource server.

03:14.000 --> 03:15.000
Very basic.

03:15.000 --> 03:22.000
So, before talking about authorization flows, the word about registration and token validation.

03:22.000 --> 03:25.000
So, the registration can be there manual.

03:25.000 --> 03:30.000
So, through the authorization, there is a operator behind the authorization server,

03:30.000 --> 03:36.000
that will register client and deliver the client ID or any method that has the client's need.

03:36.000 --> 03:39.000
And it can be, as well, it can be dynamic.

03:39.000 --> 03:44.000
The client's registration itself through a specific endpoint.

03:44.000 --> 03:49.000
And the token validation can be there local or remote.

03:49.000 --> 03:52.000
There is a specific endpoint.

03:52.000 --> 03:59.000
And the client's answer can submit tokens to validate and ensure that there are valid.

04:00.000 --> 04:02.000
It is valid.

04:02.000 --> 04:06.000
So, when we are talking about tokens, we are talking about juts.

04:06.000 --> 04:09.000
I don't know if I have really to detail it.

04:09.000 --> 04:17.000
So, basically sign a JSON object with a footer including his foot prints.

04:17.000 --> 04:22.000
And when we are talking about tokens, there are four kinds of tokens.

04:22.000 --> 04:27.000
So, there is access token, which is basically a very short time-lived token

04:28.000 --> 04:35.000
that enables the client to access a resource server in the name of the user.

04:35.000 --> 04:41.000
And there is the Refresh token, which is used to retrieve new access tokens without

04:41.000 --> 04:44.000
triggering the world scenario.

04:44.000 --> 04:49.000
So, I will go further later.

04:49.000 --> 04:56.000
And open IDConnect, basically, the new tokens, the ID tokens, which is carrying standard days

04:56.000 --> 05:03.000
the identity data about the user and the user info, which is none standard days.

05:03.000 --> 05:05.000
So, that is the difference, basically.

05:05.000 --> 05:09.000
So, you can ask by default, you get the ID token.

05:09.000 --> 05:14.000
And eventually, you can ask for user info, which is basically a dump about what the client

05:14.000 --> 05:18.000
has the right to know about the user.

05:18.000 --> 05:24.000
So, when we are talking about what contains the tokens, it is defined by the concept called

05:24.000 --> 05:25.000
Scopes.

05:25.000 --> 05:27.000
So, U.S. for given scope.

05:27.000 --> 05:33.000
And the authorization server configure what does this scope include,

05:33.000 --> 05:37.000
as in terms of claims in the tokens.

05:37.000 --> 05:41.000
So, very basic.

05:41.000 --> 05:44.000
So, it is the core of my talks.

05:45.000 --> 05:47.000
Basically, we are talking about token.

05:47.000 --> 05:50.000
The authorization server delivering tokens and stuff like that.

05:50.000 --> 05:56.000
But the question is, all the, on which conditions, the authorization server delivers

05:56.000 --> 06:03.000
the tokens to the client or any relaying parties that wants to access data in the name of the user.

06:03.000 --> 06:05.000
So, it is called the authorization flow.

06:05.000 --> 06:07.000
And there is many conditions.

06:08.000 --> 06:11.000
And many, it is very modular.

06:11.000 --> 06:20.000
And it determines the ways that the client and the authorization server establish trust between each other.

06:20.000 --> 06:28.000
So, the very basic, the original one, the most used is the authorization code flow.

06:28.000 --> 06:33.000
I guess anyone that used those two must know this one.

06:33.000 --> 06:38.000
Basically, it is all, I would like, I would say, I don't know,

06:38.000 --> 06:41.000
85% of the clients are registered.

06:41.000 --> 06:43.000
It is using the authorization code flow.

06:43.000 --> 06:47.000
So, basically, the scenario is that the authorization server tries to access data through the client.

06:47.000 --> 06:51.000
It is getting redirected to an authorization at point.

06:51.000 --> 06:55.000
It authenticated against the authorization server.

06:55.000 --> 06:57.000
The authorization server has several authentication,

06:57.000 --> 07:03.000
which can reduce the user back to the client with an authorization code in the HTTP errors.

07:03.000 --> 07:10.000
And the authorization code can be used by the client to retrieve tokens in the name of the end user.

07:10.000 --> 07:18.000
And what is important is that adding the layer of authorization code avoids the tokens to pass through the browser.

07:18.000 --> 07:23.000
So, it is a server to serve her exchange.

07:24.000 --> 07:29.000
And, basically, open IDConnect is just adding an ID token,

07:29.000 --> 07:32.000
and the user affluent points.

07:32.000 --> 07:38.000
So, the ID token is returned the same way that access token and refresh the client's return.

07:38.000 --> 07:40.000
So, that is open IDConnect.

07:40.000 --> 07:45.000
So, a technical point of view, not much differences.

07:46.000 --> 07:50.000
So, add a large scope.

07:50.000 --> 07:56.000
We have access, it is basically, so, as client, you would use a mode of open IDC.

07:56.000 --> 08:00.000
I don't know if you know this, but it is an appax to module.

08:00.000 --> 08:06.000
That acts as a open IDC client are used to play on, whatever you want.

08:06.000 --> 08:10.000
You will run dumb web app, would be the resource server.

08:10.000 --> 08:13.000
And, basically, the user would go through the mode of open IDC,

08:13.000 --> 08:22.000
which would act as a client, and would gather the access tokens and trigger the register exchange

08:22.000 --> 08:27.000
in the name of the web app, which is behind it.

08:27.000 --> 08:30.000
And, please note that you can, eventually,

08:30.000 --> 08:33.000
about authentication, the authentication.

08:33.000 --> 08:38.000
It is not necessarily based on the authorization server database,

08:38.000 --> 08:44.000
but can rely on a back-office LWP directory, or an external LWP provider,

08:44.000 --> 08:47.000
such as GitHub or whatever you want to share.

08:47.000 --> 08:52.000
And, the authorization server can retrieve data from those,

08:52.000 --> 08:55.000
and include it in the tokens.

08:55.000 --> 09:02.000
So, the issue is that when using native apps such as SPA,

09:02.000 --> 09:10.000
or mobile native apps, there is a well-known security issue.

09:10.000 --> 09:14.000
So, basically, you can enter set the authorization code.

09:14.000 --> 09:19.000
So, a malicious app could retrieve the authorization code at the same time of the client,

09:19.000 --> 09:22.000
and use it to retrieve tokens in the name of the user,

09:22.000 --> 09:26.000
and corrupt data or in the singular answer.

09:26.000 --> 09:33.000
So, the authorization code is an in-earth flow as an extended with PICC,

09:33.000 --> 09:35.000
for proof-of-key exchange.

09:35.000 --> 09:39.000
So, instead of only delivering a authorization code,

09:39.000 --> 09:43.000
instead of the client of only rejecting the user,

09:43.000 --> 09:47.000
and through the generated code identifier and a code challenge,

09:47.000 --> 09:51.000
we'll submit a code challenge during the redirecting,

09:51.000 --> 09:53.000
and when asking for tokens,

09:53.000 --> 09:58.000
it will prove that it is the same that the one we're redirected

09:58.000 --> 10:04.000
by forwarding the code identifier so you can ensure that that is the same client

10:04.000 --> 10:09.000
that redirected the user and that is asking for tokens.

10:09.000 --> 10:16.000
So, you are implementing, you are mitigating the risk of an authorization code flow steal.

10:16.000 --> 10:22.000
So, another security issue on the following layer

10:22.000 --> 10:25.000
is that the token can be intercepted itself,

10:25.000 --> 10:32.000
and there is more complex aditions to prevent this.

10:32.000 --> 10:36.000
So, one of them being the MCLS flow,

10:36.000 --> 10:41.000
in which the access token is bound to the SSL layer.

10:41.000 --> 10:45.000
So, firstly, it is mutual TLS.

10:45.000 --> 10:50.000
So, the client's verified server and the server's verified clients.

10:50.000 --> 10:56.000
This way, the client's certificate is included in the tokens,

10:56.000 --> 11:01.000
and when the client's and the resource server does the MCLS,

11:01.000 --> 11:05.000
the resource server can ensure that the client's certificate is the same

11:05.000 --> 11:07.000
as the one included in the tokens.

11:07.000 --> 11:13.000
So, you can ensure that the client's is the same that has asked for tokens

11:13.000 --> 11:16.000
and that submits the tokens.

11:17.000 --> 11:21.000
So, I want to talk about DIPOC because, which is another variant,

11:21.000 --> 11:24.000
because there was a digital, there is so there about it.

11:24.000 --> 11:30.000
But the idea is that it is not bound anymore to the SSL layer

11:30.000 --> 11:36.000
and there is a certificate used specifically for us to,

11:36.000 --> 11:44.000
that is the more unign to know about it.

11:45.000 --> 11:48.000
So, those are the basics.

11:48.000 --> 11:51.000
Those are the very basics, and there is so much density to this.

11:51.000 --> 11:55.000
So, I don't have time to talk about everything and to go into details,

11:55.000 --> 11:59.000
about everything, but I will try to give you a panel of the possibilities

11:59.000 --> 12:02.000
and a blade by those.

12:02.000 --> 12:07.000
The device flow was to address the IoT world

12:07.000 --> 12:11.000
and was specifically sought for devices without keyboards.

12:11.000 --> 12:16.000
So, you can not direct and you can not type any kind of credentials

12:16.000 --> 12:17.000
on your device.

12:17.000 --> 12:19.000
So, the device here is the client's.

12:19.000 --> 12:23.000
For example, you can imagine that you have connectivity

12:23.000 --> 12:28.000
or anything and you want to retrieve your resource scenario

12:28.000 --> 12:32.000
from a web database or anything like that.

12:33.000 --> 12:38.000
In this scenario, at a very less-scale view,

12:38.000 --> 12:42.000
the idea is that the device, when trying to access resources,

12:42.000 --> 12:47.000
will display the way it can do,

12:47.000 --> 12:50.000
because it can be used by the camera or the blackouts,

12:50.000 --> 12:54.000
sometimes the device display can be,

12:54.000 --> 12:57.000
really tough to see, and will display what is called

12:57.000 --> 13:01.000
an user code and a verification you are in, you are in.

13:01.000 --> 13:04.000
But the verification you are in,

13:04.000 --> 13:08.000
is entered by the end user on another device,

13:08.000 --> 13:11.000
such as this phone or laptop,

13:11.000 --> 13:15.000
and the end user code and the black being done

13:15.000 --> 13:18.000
the device can now ask for the client

13:18.000 --> 13:21.000
to concentrate the content and the device can retrieve

13:21.000 --> 13:23.000
access token in the name of the end user.

13:23.000 --> 13:27.000
That's the idea.

13:28.000 --> 13:33.000
So, this is the way, when this is the initiated by the device,

13:33.000 --> 13:36.000
and Siba, so for client's initiative,

13:36.000 --> 13:40.000
the black channel authorization,

13:40.000 --> 13:43.000
is the riverway.

13:43.000 --> 13:46.000
So, in this scenario, the user,

13:46.000 --> 13:49.000
it's very like a free DS, so when you pay,

13:49.000 --> 13:54.000
you get a push notification on your smartphone

13:54.000 --> 13:56.000
to validate payment or anything like that.

13:57.000 --> 14:00.000
So, in this scenario,

14:00.000 --> 14:03.000
a user would be with a try to pay something

14:03.000 --> 14:07.000
on a linear e-commerce site, such as Amazon or whatever you want,

14:07.000 --> 14:11.000
through payment API as a thing as a resource server,

14:11.000 --> 14:14.000
and in this scenario, the MercantWadbap

14:14.000 --> 14:17.000
will then notify the authorization server,

14:17.000 --> 14:20.000
which will send a pre-registered device,

14:20.000 --> 14:22.000
a push notification,

14:22.000 --> 14:25.000
the user would consent, and then the access token

14:25.000 --> 14:28.000
will retrieve the load.

14:28.000 --> 14:30.000
So, there is three modes,

14:30.000 --> 14:35.000
I only have time to talk about the ping mode.

14:35.000 --> 14:42.000
So, the button pull and pull are more or less the same.

14:42.000 --> 14:45.000
So, there is a dedicated endpoint,

14:45.000 --> 14:47.000
specified in points,

14:47.000 --> 14:50.000
called Siba endpoint, I think that it is only

14:50.000 --> 14:53.000
Siba and kicker car, whatever.

14:53.000 --> 14:56.000
So, when rejecting the user,

14:56.000 --> 15:02.000
so I squeeze some part because the core of the staff is here.

15:02.000 --> 15:08.000
So, when the client is asked for,

15:08.000 --> 15:11.000
for allowing any operation,

15:11.000 --> 15:15.000
you would send the Siba endpoint,

15:15.000 --> 15:17.000
the authorization request,

15:17.000 --> 15:19.000
and a call back to RIA,

15:19.000 --> 15:22.000
when the consent has been granted on the device,

15:22.000 --> 15:23.000
the authorization server,

15:23.000 --> 15:25.000
notifies the call back to RIA,

15:25.000 --> 15:27.000
that the client can now retrieve

15:27.000 --> 15:30.000
the token in the name of the user.

15:30.000 --> 15:32.000
So, and overall,

15:32.000 --> 15:35.000
that's exactly 3DS works,

15:35.000 --> 15:37.000
even though it's not the same protocol,

15:37.000 --> 15:40.000
that's exactly what it does work.

15:42.000 --> 15:47.000
So, when under use case,

15:47.000 --> 15:48.000
that needs to be addressed,

15:48.000 --> 15:50.000
the meaning of two is that

15:50.000 --> 15:53.000
the scope mechanism left a part.

15:53.000 --> 15:55.000
There is no, there is not,

15:55.000 --> 15:58.000
no really fine-grain authorization details,

15:58.000 --> 16:02.000
possible using pure orst,

16:02.000 --> 16:06.000
so it has been extended quite recently

16:06.000 --> 16:08.000
with what is called

16:08.000 --> 16:09.000
re-trotorization requests.

16:09.000 --> 16:12.000
So, you have a design object describing

16:12.000 --> 16:16.000
the operation, the client wants to do

16:16.000 --> 16:19.000
in the name of the user,

16:19.000 --> 16:22.000
and it will submit it to the authorization server,

16:22.000 --> 16:23.000
the authorization server,

16:23.000 --> 16:24.000
that the client eventually

16:24.000 --> 16:28.000
evaluates through any given policy.

16:28.000 --> 16:33.000
So, I will describe the mechanism.

16:33.000 --> 16:36.000
So, in the pure

16:36.000 --> 16:39.000
re-trotorization request workflow,

16:39.000 --> 16:41.000
basically, the design object that I showed you,

16:41.000 --> 16:44.000
is forwarded through HTTP errors

16:45.000 --> 16:47.000
at the same time the user is

16:47.000 --> 16:49.000
redirected to authorization.

16:49.000 --> 16:51.000
So, you can imagine that it makes

16:51.000 --> 16:53.000
a very big error.

16:53.000 --> 16:56.000
And then the policy is evaluated

16:56.000 --> 16:59.000
before granting the client the right

16:59.000 --> 17:02.000
to retrieve access to the client's name of the client.

17:02.000 --> 17:04.000
And the token's carries itself

17:04.000 --> 17:06.000
the authorization details,

17:06.000 --> 17:08.000
so the resource server can eventually

17:08.000 --> 17:10.000
evaluate another policy,

17:10.000 --> 17:12.000
possibly the same.

17:13.000 --> 17:15.000
So, I explained

17:15.000 --> 17:18.000
a third-party policy in the gene,

17:18.000 --> 17:22.000
because in my experience,

17:22.000 --> 17:25.000
you are really used

17:25.000 --> 17:27.000
the native policy in

17:27.000 --> 17:30.000
your authorization server,

17:30.000 --> 17:32.000
and you define your

17:32.000 --> 17:33.000
access policies,

17:33.000 --> 17:35.000
an given component,

17:35.000 --> 17:37.000
such as a document,

17:37.000 --> 17:40.000
or OPA, or anything like that.

17:41.000 --> 17:43.000
So, as I said,

17:43.000 --> 17:45.000
since the authorization

17:45.000 --> 17:46.000
details are forwarded

17:46.000 --> 17:49.000
in HTTP errors,

17:49.000 --> 17:51.000
disposes,

17:51.000 --> 17:54.000
with the resource,

17:54.000 --> 17:55.000
with the

17:55.000 --> 17:56.000
Compatibility,

17:56.000 --> 17:58.000
and there is a privacy

17:58.000 --> 17:59.000
and security issues,

17:59.000 --> 18:01.000
because there is a

18:01.000 --> 18:02.000
I mean,

18:02.000 --> 18:03.000
I mean, I should remove

18:03.000 --> 18:07.000
the authorization details

18:07.000 --> 18:08.000
are in clear.

18:08.000 --> 18:10.000
So, here comes the push

18:10.000 --> 18:12.000
authorization requests,

18:12.000 --> 18:15.000
in which the client

18:15.000 --> 18:17.000
will firstly push

18:17.000 --> 18:18.000
the authorization details

18:18.000 --> 18:20.000
on the given endpoints,

18:20.000 --> 18:21.000
will be returned

18:21.000 --> 18:22.000
and you are high,

18:22.000 --> 18:24.000
and when asking

18:24.000 --> 18:26.000
when redirecting the user

18:26.000 --> 18:28.000
will refer to the

18:28.000 --> 18:30.000
authorization server,

18:30.000 --> 18:33.000
can bind the authorization request

18:33.000 --> 18:35.000
with the authorization details

18:35.000 --> 18:37.000
that were pre-pushed.

18:37.000 --> 18:39.000
Yeah.

18:39.000 --> 18:42.000
And finally,

18:42.000 --> 18:44.000
so,

18:44.000 --> 18:45.000
there are a lot of

18:45.000 --> 18:47.000
slides about you,

18:47.000 --> 18:49.000
but it's a

18:49.000 --> 18:51.000
quite fast.

18:51.000 --> 18:52.000
So, I can

18:52.000 --> 18:54.000
maybe talk more in detail

18:54.000 --> 18:55.000
about it.

18:55.000 --> 18:56.000
But, yeah,

18:56.000 --> 18:57.000
so,

18:57.000 --> 18:58.000
OSTU is always

18:58.000 --> 18:59.000
an open entity,

18:59.000 --> 19:00.000
finally,

19:00.000 --> 19:01.000
is always about

19:01.000 --> 19:03.000
giving the right

19:03.000 --> 19:04.000
to relaying parties

19:04.000 --> 19:05.000
to acts

19:05.000 --> 19:06.000
in the name of the

19:06.000 --> 19:07.000
resource owner.

19:07.000 --> 19:08.000
And,

19:08.000 --> 19:09.000
you might as a

19:09.000 --> 19:11.000
new paradigm,

19:11.000 --> 19:12.000
so,

19:12.000 --> 19:14.000
is the idea that

19:14.000 --> 19:16.000
it will give

19:16.000 --> 19:17.000
the access to a

19:17.000 --> 19:18.000
requesting party

19:18.000 --> 19:19.000
to the

19:19.000 --> 19:20.000
resource owner's data.

19:20.000 --> 19:21.000
And,

19:21.000 --> 19:22.000
it goes with a

19:22.000 --> 19:24.000
very complex protocol,

19:24.000 --> 19:25.000
but the idea

19:25.000 --> 19:26.000
that, instead of

19:26.000 --> 19:27.000
your user

19:27.000 --> 19:29.000
trying to access data

19:29.000 --> 19:30.000
from two web apps,

19:30.000 --> 19:32.000
from a single one,

19:33.000 --> 19:34.000
there will be another

19:34.000 --> 19:35.000
user

19:35.000 --> 19:36.000
that can access

19:36.000 --> 19:37.000
your users

19:37.000 --> 19:38.000
data.

19:38.000 --> 19:39.000
And it does

19:39.000 --> 19:40.000
rely on

19:40.000 --> 19:41.000
OSTU

19:41.000 --> 19:42.000
through a mechanism

19:42.000 --> 19:43.000
of permission

19:43.000 --> 19:44.000
tickets and

19:44.000 --> 19:45.000
some specific

19:45.000 --> 19:46.000
sent points.

19:46.000 --> 19:47.000
And, as much

19:47.000 --> 19:48.000
as I know,

19:48.000 --> 19:49.000
it has been implemented

19:49.000 --> 19:50.000
in T-Clock.

19:50.000 --> 19:51.000
And,

19:51.000 --> 19:52.000
it is present

19:52.000 --> 19:53.000
as well,

19:53.000 --> 19:54.000
on the

19:54.000 --> 19:55.000
AWS

19:55.000 --> 19:56.000
OSTU.

19:56.000 --> 19:57.000
So,

19:57.000 --> 19:58.000
and,

19:58.000 --> 19:59.000
but,

19:59.000 --> 20:01.000
it will need

20:01.000 --> 20:03.000
the business

20:03.000 --> 20:04.000
that it does exist.

20:04.000 --> 20:05.000
Yeah.

20:05.000 --> 20:06.000
So,

20:06.000 --> 20:07.000
and,

20:07.000 --> 20:08.000
if you have any

20:08.000 --> 20:09.000
questions,

20:09.000 --> 20:10.000
are you,

20:10.000 --> 20:12.000
feel free to do so?

20:12.000 --> 20:16.000
Thank you very much.

20:16.000 --> 20:19.000
Any questions?

20:19.000 --> 20:20.000
We haven't finished here.

20:20.000 --> 20:21.000
Yeah.

20:21.000 --> 20:22.000
I'm sorry.

20:22.000 --> 20:24.000
I'm sorry.

20:24.000 --> 20:25.000
I'm sorry.

20:25.000 --> 20:26.000
I'm sorry.

20:26.000 --> 20:27.000
I'm sorry.

20:27.000 --> 20:28.000
I'm sorry.

20:28.000 --> 20:29.000
I'm sorry.

20:29.000 --> 20:31.000
I'm sorry.

20:31.000 --> 20:33.000
I can't show any thing!

20:33.000 --> 20:36.000
Or I can't show anyhost in the

20:36.000 --> 20:37.000
thing.

20:37.000 --> 20:38.000
I can't show anyhost in there.

20:38.000 --> 20:39.040
You're weighing

20:39.040 --> 20:41.040
...

20:41.040 --> 20:42.000
Sure, I'm sorry.

20:42.000 --> 20:43.960
It's just

20:45.000 --> 20:47.000
quite,

20:47.000 --> 20:49.000
eight months out of this information

20:49.000 --> 20:50.000
...

20:50.000 --> 20:52.000
really good.

20:52.000 --> 20:52.160
The

20:52.160 --> 20:54.000
B-M-T stock

20:54.000 --> 20:55.000
B-R-R M-T stock

20:55.000 --> 20:56.000
B-M-T stock

20:56.000 --> 21:03.000
We have ten minutes before the next stop starts.

21:26.000 --> 21:33.000
We have ten minutes before the next stop starts.

21:56.000 --> 22:03.000
We have ten minutes before the next stop starts.

22:26.000 --> 22:33.000
We have ten minutes before the next stop starts.

22:56.000 --> 23:03.000
We have ten minutes before the next stop starts.

23:26.000 --> 23:33.000
We have ten minutes before the next stop starts.

23:56.000 --> 24:03.000
We have ten minutes before the next stop starts.

24:26.000 --> 24:33.000
We have ten minutes before the next stop starts.

24:33.000 --> 24:40.000
We have ten minutes before the next stop starts.

24:40.000 --> 24:47.000
We have ten minutes before the next stop starts.

24:47.000 --> 24:54.000
We have ten minutes before the next stop starts.

24:54.000 --> 25:01.000
We have ten minutes before the next stop starts.

25:24.000 --> 25:31.000
We have ten minutes before the next stop starts.

25:31.000 --> 25:41.000
We have ten minutes before the next stop starts.

26:01.000 --> 26:11.000
We have ten minutes before the next stop starts.

26:31.000 --> 26:41.000
We have ten minutes before the next stop starts.

27:01.000 --> 27:11.000
We have ten minutes before the next stop starts.

27:31.000 --> 27:41.000
We have ten minutes before the next stop starts.

28:01.000 --> 28:11.000
We have ten minutes before the next stop starts.

28:31.000 --> 28:41.000
We have ten minutes before the next stop starts.

29:01.000 --> 29:27.000
We have ten minutes before the next stop starts.

29:27.000 --> 29:42.000
We have ten minutes before the next stop starts.

29:42.000 --> 30:05.000
We have ten minutes before the next stop starts.

30:05.000 --> 30:27.000
We have ten minutes before the next stop starts.