Name of W

[gselander]

Michael commented on the overlap in terminology with ACE: We may want to rename Authorization Server.

If so, wIth what? We are not using BRSKI terminology for the other entities, so would probably not use MASA as in Manufacturer Authorized Signing Authority either, and in our case there is no signing being performed.

802.1X uses Authenticator and Authentication Server, although the operation is more like authorization.

RFC 8366 describes the purpose of the voucher as:

• "to securely assign a pledge to an owner"
• "informs the pledge which entity it should consider to be its owner"
• "indicates to a pledge the cryptographic identity of the domain it should trust"

I couldn't derive a good name for the entity performing the action leading to that.

Perhaps we should not try to characterize the purpose of W, but rather describe its function, what about Voucher Issuer?

[gselander]

Or just simply "Authorization Service" for disambiguation

[geonnave]

I think "Authorization Service" is good.

I have also thought of "Join Server", but that is already used by LoRaWAN.

[malishav]

Agreed on "Authorization Service" as a workaround.

[mcr]

Göran Selander @.***> wrote:

If so, wIth what? We are not using BRSKI terminology for the other entities, so would probably not use MASA as in Manufacturer Authorized Signing Authority either, and in our case there is no signing being performed.

Why aren't you using BRSKI terminology? We worked very hard to make the terminology clear, non-overlapping with other uses, and rather specific.

As for signing: there definitely is signing occuring at W.

> 802.1X uses Authenticator and **Authentication Server**, although the
> operation is more like authorization.

They use supplicant, authenticator and authentication server (AS), but their "AS" is not the same as the OAUTH/ACE "AS", and that's why we didn't use that term in BRSKI.

> Perhaps we should not try to characterize the purpose of W, but rather
> describe its function, what about **Voucher Issuer**?

Thumbs down.

[mcr]

I strongly object to anything that has a acronym "AS"

[gselander]

With all respect for the work done on BRSKI, I think we should not be bound to choose the same terminology, since this draft may be useful outside that context. We are using the term "device", not "pledge", and that seems fine to everyone, so the same should go for not using the term MASA. The role of W need not be associated to a manufacturer and there is no signature on the voucher in case static DH keys are used. So let's think of something else.

We should not spend much more time on this. Let's make a last attempt to find something all can agree on, or else we just make a simple vote what to put in the next version of the draft. If we go for consensus then we have ruled out:

Authorization Server Authentication Service Authentication Server MASA Voucher Issuer

(These remains candidates if we go for a vote.)

I have one additional proposal. All over the draft we describe the purpose of the protocol as enrollment of a device into a domain. So the third party could have a name which includes the term "enrollment", such as Enrollment Server/Service etc. This would also make the abbreviation different from "AS".

[geonnave]

I am fine with Enrollment Server / Service.

[gselander]

PR #22

[gselander]

Closing this as #22 is merged