Access control chapter rewrite

[peterMelco]

So, one general comment/question is how we use capital letters within sentences ?

Ex: "In the Short term flow the Client must contact the AGS every time it needs a new Grant token"

I guess the purpose is to make emphasize on certain words ? I don't see why we need to define our own way of capitalization though.

[UlfBj]

The idea was to distinguish a Gen2 defined Client from a common client. But capitalizing on that concept may lead to confusion. i am fine with either way. br ulf

On Mon, Aug 10, 2020, 19:42 peterMelco notifications@github.com wrote:

So, one general comment/question is how we use capital letters within sentences ?

Ex: "In the Short term flow the Client must contact the AGS every time it needs a new Grant token"

I guess the purpose is to make emphasize on certain words ? I don't see why we need to define our own way of capitalization though.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/automotive/pull/334#issuecomment-671493220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJERQQIBZUXAL3PT35YNJGLSAAWO7ANCNFSM4PUJT62Q .

[tguild]

It might make more sense to have the 6.4 Actors section moved up to 6.2, following architecture. Somewhat repetitive parts in actor/protocol parts and details belong more in protocol part, suggest shortening actors descriptions.

Client Context, Proof and Purpose should perhaps be explained early on before referenced.

6.2 is it realistic to expect an application to be able to generate its own keys? If provided by the host environment, invoking commands and key storage may need an API itself. Consider instead a number of pre-issued pairs?

6.3.1 - Is VIN necessary? I can see apps permitted to run on a vehicle that would not need to know this potentially personal identifying information. VIN itself can be used to determine year, make, model, country built, potentially trim package, lookup outstanding recalls, crash history (carfax requests) etc. VIN may be a protected signal and not something known or given to all client applications.

This part is unclear or confusing, perhaps from reusing term proof. "If a public key is included in the request, the proof parameter shall also include of proof of possession for this key." I need further understanding of proof mechanisms.

6.3.2 "depending on the input in the request message" which supplied parameters indicate desired duration for tokem, part of context?

6.4.2 typo s/AG token create a prof of possession/AG token create a proof of possession/

6.4.3 "The expiry time must be later than the current system time of the AT server run-time. To allow for some time synchronization inaccuracy an error of tens of seconds may be allowed." These two statements are in contradiction 'must' be later but may be close enough within margin or error. A better second statement might be "To allow for some time synchronization inaccuracy and minor network latency, expiry times should be set to include potential modest margin of error, possibly as long as tens of seconds."

6.4.4 401 Unauthorized more appropriate than 404 for missing token, what response from http server gives repeatedly if given incorrect or missing credentials. After client gives up on a 401 'loop', 403 instead of 406 may be more appropriate.

6.4.5 should include mechanism for capturing consent is outside scope.

6.4.5 and 6.4.6 belong under actors?

Trying to understand Aud parameter's purpose.

[isaacagudo]

6.2 is it realistic to expect an application to be able to generate its own keys? If provided by the host environment, invoking commands and key storage may need an API itself. Consider instead a number of pre-issued pairs?

I don't think every application should use the long term tokens, but in any case the OS/host should provide a mechanisms to provision key pairs, I think this is outside of the scope.

6.3.1 - Is VIN necessary? I can see apps permitted to run on a vehicle that would not need to know this potentially personal identifying information. VIN itself can be used to determine year, make, model, country built, potentially trim package, lookup outstanding recalls, crash history (carfax requests) etc. VIN may be a protected signal and not something known or given to all client applications.

I think VIN could be a protected resource from a privacy by design perspective, if the application only needs speed why do we need to allow access to the VIN too. This is something we might need to revise.

This part is unclear or confusing, perhaps from reusing term proof. "If a public key is included in the request, the proof parameter shall also include of proof of possession for this key." I need further understanding of proof mechanisms.

Maybe if you read the previous comment you'll get a more clear picture of PoP

[tguild]

merging as agreed on WG call

https://www.w3.org/2020/09/08-auto-minutes.html