Subject: [Txauth] XYZ vs XAuth: Discovery

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Mar 2020 16:05:32 -0700

*Discovery*
XYZ
 - Client always starts at the tx endpoint, all other information is
dispatched from responses from the endpoint
 - Clients sends capabilities list in transaction request, AS selects and
returns which capabilities are supported

XYZ Rationale: client needs a single URL to start talking to an AS, giving
developers multiple ways to get information is confusing and can lead to
serious errors (see OAuth2’s mix-up attack caused by OIDC’s discovery
approach)

XAuth
 - Client sends an OPTIONS call to the GS URI, Grant URI, or Authorization
URI

XAuth Rationale: Client can make unauthenticated call to GS URI to learn
what GS supports, such as authentication mechanisms. Authenticated calls
return what a specific Client can do.

ᐧ

---

From: David Skaife <[email-masked]>
Date: Wed, 18 Mar 2020 19:44:08 +0000

Hi,

My thoughts on these different approaches are:

1. For XYZ, it feels a bit strange and unnecessary to require the client to
have to state it's full set of capabilities to the AS. It feels like it
should be the other way around - i.e. the client is able to probe what the
AS supports. In my view it's more natural for the AS to be "advertising"
its capabilities rather than the client.

2. I prefer the XYZ approach of having a single URL that the client knows
it needs to interact to start the transaction, vs the more complex
approach provided by XAuth.

3. Hopefully there is a middle ground between the two approaches that
addresses the two points above.

Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <[email-masked]> wrote:

> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Stephen Moore <[email-masked]>
Date: Wed, 18 Mar 2020 15:56:36 -0400

For your thought #1, it seems that it is just who does the filtering. Since
I'm looking at this for running on small devices potentially, anything I
don't have to process myself is better and I don't mind the AS doing that
set math for my client. I think whoever is going to have the larger set
(Which I would think would be the AS) should have to do the filtering in my
mind because whoever that is will probably be the bigger processor/memory.

Furthermore, it does reduce the network traffic since the client doesn't
have to probe for that information first.

I realize I have a slightly biased viewpoint though.

I very much agree on point 2 though. Only having a single URL will simplify
configuration and setup.

On Wed, Mar 18, 2020 at 3:44 PM David Skaife <
[email-masked]> wrote:

> 1. For XYZ, it feels a bit strange and unnecessary to require the client
> to have to state it's full set of capabilities to the AS. It feels like it
>> XYZ Rationale: client needs a single URL to start talking to an AS,
>> giving developers multiple ways to get information is confusing and can
>> lead to serious errors (see OAuth2’s mix-up attack caused by OIDC’s
>> discovery approach)
>>
>> XAuth
>>  - Client sends an OPTIONS call to the GS URI, Grant URI, or
>> Authorization URI
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Mar 2020 16:22:25 -0400

OAuth 2 has taught us that wherever possible, you should push the complexity to the server, not the client. That’s the idea behind the kind of publication/negotiation here where the client can do something simple and the AS needs to make the actual comparison and decision, whatever that is. Clients need to stay simple because, for the most part, the focus of the client is on calling whatever API and implementing whatever functionality it is doing, not on the security layer. The AS is a dedicated security component, so it’s got the mandate to figure this stuff out. This mindset is one of OAuth 2’s biggest strengths. 

So how would this work in XYZ? I’ll say that we haven’t really :used: this feature beyond making sure the protocol can be passed back and forth, since there’s not a lot of optionality that really needs to be negotiated here.

So let’s say the client can do A, B, and C. The AS can do B, D, and X. If the client doesn’t know anything at all about the AS, the client sends:

[A, B, C]

And the server looks at that, compares with what it can do, and returns:

[B]

The server doesn’t send D, or X, because the client wouldn’t have any clue what to do about that. The client can remember that if it wants to cache that part of the response.

So the question is, what if the client knew that only B would be successful for this server? That’s pretty common because a lot of clients get written and configured with a static set of capabilities for a server. And with the negotiation above, the client just needs to remember after the first call. So in both cases, the client would only send [B], or leave it off entirely because it doesn’t need to negotiate, and you’re done. 

But the thing is, you could do both styles with one simple twist. If you want to do the discovery portion in a pre-flight request, I think it’s a good idea to allow OPTIONS on the tx endpoint. It doesn’t make any sense to me to allow it on any other endpoints, especially because some of those are going to be user-facing (so the client is not going to be talking to the URL itself). The client makes this call and gets back:

[B, D, X]

And now the client has to put together its possible capabilities from that list and what it knows it can do. By putting OPTIONS on the endpoint then we can stick with the same mantra of the client having one piece of info to get started — the tx endpoint’s URL — and learning everything else from that. I think that part is simple enough to potentially work, and XYZ doesn’t have other endpoints or aspects that need to be discovered out of band, unlike OAuth 2.

 — Justin

> On Mar 18, 2020, at 3:44 PM, David Skaife <[email-masked]> wrote:
> 
> Hi,
> 
> 1. For XYZ, it feels a bit strange and unnecessary to require the client to have to state it's full set of capabilities to the AS. It feels like it should be the other way around - i.e. the client is able to probe what the AS supports. In my view it's more natural for the AS to be "advertising" its capabilities rather than the client.
> 
> 2. I prefer the XYZ approach of having a single URL that the client knows it needs to interact to start the transaction, vs the more complex approach provided by XAuth.
> 
> 3. Hopefully there is a middle ground between the two approaches that addresses the two points above.
> 
> 
> Many thanks,
> David Skaife
> 
> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Discovery
> 
> XYZ
>  - Client always starts at the tx endpoint, all other information is dispatched from responses from the endpoint
>  - Clients sends capabilities list in transaction request, AS selects and returns which capabilities are supported
> 
> XYZ Rationale: client needs a single URL to start talking to an AS, giving developers multiple ways to get information is confusing and can lead to serious errors (see OAuth2’s mix-up attack caused by OIDC’s discovery approach)
> 
> XAuth
>  - Client sends an OPTIONS call to the GS URI, Grant URI, or Authorization URI
> 
> XAuth Rationale: Client can make unauthenticated call to GS URI to learn what GS supports, such as authentication mechanisms. Authenticated calls return what a specific Client can do.
> 
> 
> ᐧ
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: David Skaife <[email-masked]>
Date: Wed, 18 Mar 2020 20:53:04 +0000

Thanks Stephen and Justin for your responses.

I certainly accept some of the points you've raised here. One thing I'd
like to add though is that the examples you've provided only show the
happy-path scenario (from a client's perspective) - where the AS
conveniently supports only one of the capabilities provided by the client.
What about if we consider the following scenario:

- Client can do A, B, C and D. The AS can do A, B, C, D and E.
- The client sends [A, B, C, D].
- Does the AS now send back [A, B, C, D], and then force the client to make
a decision (i.e. complexity on the client)? Or instead, does the AS make a
decision itself and then only send one result back? If the latter, then how
would the AS make this decision, and could this potentially result in an
undesirable outcome from a client's perspective?

As you've mentioned, in reality the client would likely "remember" the
capabilities that the AS supports. So if the AS were instead probed by the
client to retrieve the list of its capabilities, this additional complexity
needed on the client side would not be something that is present in every
interaction - as the client would simply need to pass it's preferred
(supported) method on each interaction, rather than having to keep probing
and filtering on each request. Additionally, this concept of the client
remembering what the AS supports would negate the argument about there
being an increase in network traffic raised by Stephen.

I don't think it's as clear-cut as you've presented in your responses, but
I do accept that there are merits to trying to push complexity to the
server.

Many thanks,
David Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <[email-masked]> wrote:

> OAuth 2 has taught us that wherever possible, you should push the
> complexity to the server, not the client. That’s the idea behind the kind
> of publication/negotiation here where the client can do something simple
> and the AS needs to make the actual comparison and decision, whatever that
> is. Clients need to stay simple because, for the most part, the focus of
> the client is on calling whatever API and implementing whatever
> functionality it is doing, not on the security layer. The AS is a dedicated
> security component, so it’s got the mandate to figure this stuff out. This
> mindset is one of OAuth 2’s biggest strengths.
>
> So how would this work in XYZ? I’ll say that we haven’t really :used: this
> feature beyond making sure the protocol can be passed back and forth, since
> there’s not a lot of optionality that really needs to be negotiated here.
>
> So let’s say the client can do A, B, and C. The AS can do B, D, and X. If
> the client doesn’t know anything at all about the AS, the client sends:
>
> [A, B, C]
>
> The server doesn’t send D, or X, because the client wouldn’t have any clue
> what to do about that. The client can remember that if it wants to cache
> that part of the response.
>
> So the question is, what if the client knew that only B would be
> successful for this server? That’s pretty common because a lot of clients
> get written and configured with a static set of capabilities for a server.
> And with the negotiation above, the client just needs to remember after the
> first call. So in both cases, the client would only send [B], or leave it
> off entirely because it doesn’t need to negotiate, and you’re done.
>
> But the thing is, you could do both styles with one simple twist. If you
> want to do the discovery portion in a pre-flight request, I think it’s a
> good idea to allow OPTIONS on the tx endpoint. It doesn’t make any sense to
> me to allow it on any other endpoints, especially because some of those are
> going to be user-facing (so the client is not going to be talking to the
> URL itself). The client makes this call and gets back:
>
> [B, D, X]
>
> And now the client has to put together its possible capabilities from that
> list and what it knows it can do. By putting OPTIONS on the endpoint then
> we can stick with the same mantra of the client having one piece of info to
> get started — the tx endpoint’s URL — and learning everything else from
> that. I think that part is simple enough to potentially work, and XYZ
> doesn’t have other endpoints or aspects that need to be discovered out of
> band, unlike OAuth 2.
>
>  — Justin
>
>
>
> On Mar 18, 2020, at 3:44 PM, David Skaife <

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Mar 2020 17:04:53 -0400

I wasn’t showing just the happy path, but I think my example might have been too simple. Also, I think we've got a different model for what’s in the capabilities. It’s not about a set of mutually exclusive options that the client has to choose from.

> I certainly accept some of the points you've raised here. One thing I'd like to add though is that the examples you've provided only show the happy-path scenario (from a client's perspective) - where the AS conveniently supports only one of the capabilities provided by the client. What about if we consider the following scenario:
> 
> - Does the AS now send back [A, B, C, D]

Yes, the AS sends back [A, B, C, D] because that’s the subset of the client’s capabilities. 

> , and then force the client to make a decision (i.e. complexity on the client)? Or instead, does the AS make a decision itself and then only send one result back? If the latter, then how would the AS make this decision, and could this potentially result in an undesirable outcome from a client's perspective?

The client is already declaring that it can do all of those, and so it needs to figure out which of those it’s going to use and how they work together. My intent wasn’t to say that the client could only do one of those at a time, but rather that these were different things that the client could support that were optional at the AS, and the AS is telling the client which bits that it knows about and can handle. Maybe this is a list of extensions, maybe it’s a list of optional features, but it’s on top of the “core” portions of the protocol. 

I’ll also say that this is completely separate from the discussion on how to handle interaction — I think the information patterns on that (which are in a different thread) are much clearer. 

> 
> As you've mentioned, in reality the client would likely "remember" the capabilities that the AS supports. So if the AS were instead probed by the client to retrieve the list of its capabilities, this additional complexity needed on the client side would not be something that is present in every interaction - as the client would simply need to pass it's preferred (supported) method on each interaction, rather than having to keep probing and filtering on each request. Additionally, this concept of the client remembering what the AS supports would negate the argument about there being an increase in network traffic raised by Stephen.

The reality is that most clients aren’t really going to discover and declare things, especially if the client can start the whole protocol with just one bit of information. XYZ originally started with zero discovery, because all of the important parts are revealed during the protocol. 

> 
> I don't think it's as clear-cut as you've presented in your responses, but I do accept that there are merits to trying to push complexity to the server.
> 

I agree that it’s not that clear cut yet — but that’s largely because there aren’t a lot of concrete things that would go in this “discovery” document yet. At least with XYZ, we deliberately minimized what the client would need to know going in, for both simplicity and security. When you make the core protocol such that you don’t need a lot of extra bits in order for things to function, then you aren’t creating problems that you need solutions for.

Thanks for raising the discussion!

> 
> Many thanks,
> David Skaife
> 
> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 18, 2020, at 3:44 PM, David Skaife <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>

---

From: Stephen Moore <[email-masked]>
Date: Wed, 18 Mar 2020 17:10:25 -0400

I think I'd be happy in either case,
I have a feeling though, in like 99% of the case it'll pick the first one.
So a question there is, does order matter? If you enforce order, I'd say
the client sends what it can do in order of preference, and the AS responds
in kind. (As in the AS could switch the order to what it wants, or just
leaves the order as the client sent it. That way the client picks the first
one and runs with it.

As for the remembering bit... again on a dead small micro that can speak
wifi, you can't count on it remembering anything... space is at a premium
too. Caching is a client side option... not a requirement as I see it.
-steve

On Wed, Mar 18, 2020 at 4:53 PM David Skaife <
[email-masked]> wrote:

> - Does the AS now send back [A, B, C, D], and then force the client to
> make a decision (i.e. complexity on the client)? Or instead, does the AS
> make a decision itself and then only send one result back? If the latter,
> then how would the AS make this decision, and could this potentially result
> in an undesirable outcome from a client's perspective?
>
>> So how would this work in XYZ? I’ll say that we haven’t really :used:
>> this feature beyond making sure the protocol can be passed back and forth,
>> since there’s not a lot of optionality that really needs to be negotiated
>> here.
>>
>> The server doesn’t send D, or X, because the client wouldn’t have any
>> clue what to do about that. The client can remember that if it wants to
>> cache that part of the response.
>>
>> And now the client has to put together its possible capabilities from
>> that list and what it knows it can do. By putting OPTIONS on the endpoint
>> then we can stick with the same mantra of the client having one piece of
>> info to get started — the tx endpoint’s URL — and learning everything else
>> from that. I think that part is simple enough to potentially work, and XYZ
>>>  - Clients sends capabilities list in transaction request, AS selects
>>> and returns which capabilities are supported
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Mar 2020 17:18:32 -0400

Speaking with someone on another channel, let me explain it this way.

This isn’t like “I will send this to you in JSON or CBOR, which do you want?” It’s more like “I can take a signed ID token” and “I speak French”. So there isn’t an order or a preference or an exclusivity. If you can do either of them, or both of them, you just do them.

Doing the OPTIONS call would let the client fetch from the server all of that at once, if it wanted too. Allowing it inline lets the client do all of that without making a second network call or remembering anything. But it always has the option to do so.

 — Justin

> On Mar 18, 2020, at 5:04 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Stephen Moore <[email-masked]>
Date: Wed, 18 Mar 2020 17:24:02 -0400

That makes more sense to me now. Thanks Justin!
I also like that particular solution, rather basically relying on caching
or re-discovery before the transaction begins since, I think, that allows
for more flexible client 'requirements'.
-steve

On Wed, Mar 18, 2020 at 5:18 PM Justin Richer <[email-masked]> wrote:

> This isn’t like “I will send this to you in JSON or CBOR, which do you
> want?” It’s more like “I can take a signed ID token” and “I speak French”.
> So there isn’t an order or a preference or an exclusivity. If you can do
> either of them, or both of them, you just do them.
>
> Doing the OPTIONS call would let the client fetch from the server all of
> that at once, if it wanted too. Allowing it inline lets the client do all
> of that without making a second network call or remembering anything. But
> it always has the option to do so.
>
>  — Justin
>
> I wasn’t showing just the happy path, but I think my example might have
> been too simple. Also, I think we've got a different model for what’s in
> the capabilities. It’s not about a set of mutually exclusive options that
> the client has to choose from.
>
> , and then force the client to make a decision (i.e. complexity on the
> client)? Or instead, does the AS make a decision itself and then only send
> one result back? If the latter, then how would the AS make this decision,
> and could this potentially result in an undesirable outcome from a client's
> perspective?
>
>
> The client is already declaring that it can do all of those, and so it
> needs to figure out which of those it’s going to use and how they work
> together. My intent wasn’t to say that the client could only do one of
> those at a time, but rather that these were different things that the
> client could support that were optional at the AS, and the AS is telling
> the client which bits that it knows about and can handle. Maybe this is a
> list of extensions, maybe it’s a list of optional features, but it’s on top
> of the “core” portions of the protocol.
>
> I’ll also say that this is completely separate from the discussion on how
> to handle interaction — I think the information patterns on that (which are
> in a different thread) are much clearer.
>
>
> The reality is that most clients aren’t really going to discover and
> declare things, especially if the client can start the whole protocol with
> just one bit of information. XYZ originally started with zero discovery,
> because all of the important parts are revealed during the protocol.
>
>
> I agree that it’s not that clear cut yet — but that’s largely because
> there aren’t a lot of concrete things that would go in this “discovery”
> document yet. At least with XYZ, we deliberately minimized what the client
> would need to know going in, for both simplicity and security. When you
> make the core protocol such that you don’t need a lot of extra bits in
> order for things to function, then you aren’t creating problems that you
> need solutions for.
>

---

From: David Skaife <[email-masked]>
Date: Wed, 18 Mar 2020 22:12:04 +0000

Thanks for explaining further Justin - that makes more sense now.

I think the confusion was that the topic here is simply "Discovery" and
also the XAuth rationale section in the original email says "Client can
make unauthenticated call to GS URI to learn what GS supports, *such as
authentication mechanisms*" - which sounds like an example where the
options would potentially be mutually exclusive. So certainly in my mind I
was focusing on the mutually exclusive scenarios, which I now appreciate
isn't what you intended for the XYZ capabilities feature.

Was a useful discussion, thanks.

David Skaife

On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore <[email-masked]> wrote:

>> I don't think it's as clear-cut as you've presented in your responses,
>> but I do accept that there are merits to trying to push complexity to the
>> server.
>>
>>
>>> So let’s say the client can do A, B, and C. The AS can do B, D, and X.
>>> If the client doesn’t know anything at all about the AS, the client sends:
>>>
>>> [A, B, C]
>>>
>>> 2. I prefer the XYZ approach of having a single URL that the client
>>> knows it needs to interact to start the transaction, vs the more complex
>>>> XAuth Rationale: Client can make unauthenticated call to GS URI to
>>>> learn what GS supports, such as authentication mechanisms. Authenticated
>>>> calls return what a specific Client can do.
>>>>
>>>>
>>>> ᐧ
>>>> --
>>>> Txauth mailing list
>>>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 08:36:10 -0400

I think one of the reasons that we’re failing on really nailing down this discussion is that we don’t have concrete examples or implementations of what we mean by “discovery”. Even in the XYZ implementations, we aren’t :using: the capabilities component in a dynamic way. 

I think what’s going to drive discovery is whatever information needs to be discovered. I’ve tried to design XYZ such that this kind of information is minimized, and I believe that’s a valuable design principle that we should carry in to TxAuth.

 — Justin

> On Mar 18, 2020, at 6:12 PM, David Skaife <[email-masked]> wrote:
> 
> I think the confusion was that the topic here is simply "Discovery" and also the XAuth rationale section in the original email says "Client can make unauthenticated call to GS URI to learn what GS supports, such as authentication mechanisms" - which sounds like an example where the options would potentially be mutually exclusive. So certainly in my mind I was focusing on the mutually exclusive scenarios, which I now appreciate isn't what you intended for the XYZ capabilities feature.
> 
> On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore <[email-masked] <mailto:[email-masked]>> wrote:
> I also like that particular solution, rather basically relying on caching or re-discovery before the transaction begins since, I think, that allows for more flexible client 'requirements'.
> -steve
> 
> On Wed, Mar 18, 2020 at 5:18 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 18, 2020, at 5:04 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 13:09:54 -0700

Let me clarify the reference to "authentication mechanisms" in the XAuth
rationale. It is how the Client can authenticate to the GS. It might be
JOSE, MTLS, or ...

Most clients today are bespoke in that they know a priori how they will
interact with the user and the AS. In XAuth, the use cases that discovery
enables are:

- a client to interact with an arbitrary GS that provides a standardized
set of capabilities, but may have different mechanisms for doing them.

- a developer to use a library that encapsulates different mechanisms in
different GS without the developer having to .

- a GS can add new mechanisms without the Client having to change code.

While some types of features can be easily negotiated, some features are
difficult to negotiate, and a discovery mechanism is simpler.

When I was discussing the differences with Justin, he contended that the
capability negotiation in XYZ was discovery. I think that is only a subset
of the problem.

It is a somewhat different topic wrt. interaction capabilities. The Client
knows it can do a redirect or not. Negotiation is not needed. For security
reasons, I think the GS should always support a redirect. The GS can also
decide if it will support Clients that don't support a redirect. Discovery
allows the client to determine if the GS will allow not using a redirect
before the Client puts together a request that will fail -- BUT this is
only needed where the GS is not known by the Client a priori.

/Dick

On Wed, Mar 18, 2020 at 3:12 PM David Skaife <
[email-masked]> wrote:

>>> I’ll also say that this is completely separate from the discussion on
>>> how to handle interaction — I think the information patterns on that (which
>>> are in a different thread) are much clearer.
>>>
>>>
>>>> But the thing is, you could do both styles with one simple twist. If
>>>> you want to do the discovery portion in a pre-flight request, I think it’s
>>>> a good idea to allow OPTIONS on the tx endpoint. It doesn’t make any sense
>>>> to me to allow it on any other endpoints, especially because some of those
>>>> are going to be user-facing (so the client is not going to be talking to
>>>> the URL itself). The client makes this call and gets back:
>>>>
>>>> [B, D, X]
>>>>
>>>> 1. For XYZ, it feels a bit strange and unnecessary to require the
>>>> client to have to state it's full set of capabilities to the AS. It feels
>>>> like it should be the other way around - i.e. the client is able to probe
>>>> what the AS supports. In my view it's more natural for the AS to be
>>>> "advertising" its capabilities rather than the client.
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 13:23:31 -0700

To clarify on point 2 made below about XAuth being more complex:

XAuth has a single URI to interact with to start, the GS URI.

The Grant URL is the GS URL + identifier which seems equivalent to the
TxAurh endpoint and transaction handle.

An advantage of the Grant URI, is the Client knows which GS it belongs to.

David: would you clarify what you think is more complex in XAuth?

/Dick

---

From: David Skaife <[email-masked]>
Date: Fri, 20 Mar 2020 21:32:06 +0000

Hi Dick,

It might be a misunderstanding on my part, but the extra complexity I was
referring to is that XAuth provides multiple different URIs to communicate
with the GS. Depending on the nature of the interaction, the client needs
to work out whether to use the GS URI, the Grant URI or the Authorization
URI - from a "discovery" perspective, this seems to me more complex than
having a single URI.

Happy to be corrected if I've misunderstood.

David Skaife

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 15:02:36 -0700

Thanks for the clarification!

All GS information would be discovered off the GS URI with an OPTIONS call.
The results may be different if the client has authenticated.

In case it was useful, the GS could support an OPTIONS call for each Grant
URI that was issued to allow the Client to discovery what could be done
with a given Grant.

Similarly if it was useful to allow discovery on a specific Authorization.