From c71a8b6e002bac99e3d3508e3851200fa0ca1df0 Mon Sep 17 00:00:00 2001 From: Xavier Lin Date: Tue, 16 Jul 2024 10:03:39 -0400 Subject: [PATCH 1/5] feat: apkam key naming conventions ADR --- decisions/2024-07-apkam-key-conventions.md | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 decisions/2024-07-apkam-key-conventions.md diff --git a/decisions/2024-07-apkam-key-conventions.md b/decisions/2024-07-apkam-key-conventions.md new file mode 100644 index 0000000..bd7c036 --- /dev/null +++ b/decisions/2024-07-apkam-key-conventions.md @@ -0,0 +1,62 @@ +# Platform SDKs + +* **Status:** Not Approved +* **Last Updated:** 2024-07-16 +* **Objective:** Normalize the approach to creating APKAM keys for the user. + +## Context & Problem Statement + +Right now, we have no clear guidelines on how to name APKAM keys for the user. + +If the keys are not named consistently, it will be difficult for users and apps to understand which keys are available and how to use them. + +Introducing our `-k` flag in `at_activate enroll`. + +Currently, we have the -k flag which allows the user to specify the key name they want to use. This is useful for users who want to use a specific key name, however for apps that read the keys is it not clear which is apkam and which is a manager key. + +## Goals + +Create a consistent naming convention for APKAM keys. + +### Non-goals + +Specifying the key conventions as defaults in our documentation. + +## Considered Options + +* ### Remove the -k flag as a mandatory flag in at_activate enroll + +Come up with default key name for APKAM keys. The user will still be able to see which keys are for what using the `at_activate list` command + +Such as: +- `@soccer0_{enrollment_id}_key.atKeys` +- `@soccer0_{hashed_namespace}_key.atKeys` + + +* ### Create a naming convention for APKAM keys in the documentation + +Create a naming convention for APKAM keys in the documentation. + +Right now the default is `@soccer0_key.atKeys`. Which is the same as the manager key. However we are completely riding on the fact that the user will get the prompt to NOT overwrite the key. + +Leaving these decisions up to the user is not ideal. When a more advanced user wishes to use a specific key name, they can use the `-k` flag. + + +## Proposal Summary + +Remove the `-k` flag as a mandatory flag in `at_activate enroll` and come up with a default naming convention for APKAM keys in code. + +## Proposal in Detail + +I'm leaning towards the hashed namespace key name, we would be hashing using the enrollment_id. This would allow the user to see which keys are for what using the `at_activate list` command. + +If we want we could instead include the hash inside of the json of the file. + +### Expected Consequences + +Rewriting the code to include the hashed namespace key name. + +Which include: +* at_activate +* noports +* any other app that would use apkam keys \ No newline at end of file From b35fc90f7e984584d26e835fc0ce0a2afc7706e1 Mon Sep 17 00:00:00 2001 From: Xavier Lin Date: Tue, 16 Jul 2024 10:17:36 -0400 Subject: [PATCH 2/5] chore: lint --- decisions/2024-07-apkam-key-conventions.md | 132 +++++++++++---------- 1 file changed, 70 insertions(+), 62 deletions(-) diff --git a/decisions/2024-07-apkam-key-conventions.md b/decisions/2024-07-apkam-key-conventions.md index bd7c036..007b5ee 100644 --- a/decisions/2024-07-apkam-key-conventions.md +++ b/decisions/2024-07-apkam-key-conventions.md @@ -1,62 +1,70 @@ -# Platform SDKs - -* **Status:** Not Approved -* **Last Updated:** 2024-07-16 -* **Objective:** Normalize the approach to creating APKAM keys for the user. - -## Context & Problem Statement - -Right now, we have no clear guidelines on how to name APKAM keys for the user. - -If the keys are not named consistently, it will be difficult for users and apps to understand which keys are available and how to use them. - -Introducing our `-k` flag in `at_activate enroll`. - -Currently, we have the -k flag which allows the user to specify the key name they want to use. This is useful for users who want to use a specific key name, however for apps that read the keys is it not clear which is apkam and which is a manager key. - -## Goals - -Create a consistent naming convention for APKAM keys. - -### Non-goals - -Specifying the key conventions as defaults in our documentation. - -## Considered Options - -* ### Remove the -k flag as a mandatory flag in at_activate enroll - -Come up with default key name for APKAM keys. The user will still be able to see which keys are for what using the `at_activate list` command - -Such as: -- `@soccer0_{enrollment_id}_key.atKeys` -- `@soccer0_{hashed_namespace}_key.atKeys` - - -* ### Create a naming convention for APKAM keys in the documentation - -Create a naming convention for APKAM keys in the documentation. - -Right now the default is `@soccer0_key.atKeys`. Which is the same as the manager key. However we are completely riding on the fact that the user will get the prompt to NOT overwrite the key. - -Leaving these decisions up to the user is not ideal. When a more advanced user wishes to use a specific key name, they can use the `-k` flag. - - -## Proposal Summary - -Remove the `-k` flag as a mandatory flag in `at_activate enroll` and come up with a default naming convention for APKAM keys in code. - -## Proposal in Detail - -I'm leaning towards the hashed namespace key name, we would be hashing using the enrollment_id. This would allow the user to see which keys are for what using the `at_activate list` command. - -If we want we could instead include the hash inside of the json of the file. - -### Expected Consequences - -Rewriting the code to include the hashed namespace key name. - -Which include: -* at_activate -* noports -* any other app that would use apkam keys \ No newline at end of file +# Platform SDKs + +* **Status:** Not Approved +* **Last Updated:** 2024-07-16 +* **Objective:** Normalize the approach to creating APKAM keys for the user. + +## Context & Problem Statement + +Right now, we have no clear guidelines on how to name APKAM keys for the user. + +If the keys are not named consistently, it will be difficult for users + and apps to understand which keys are available and how to use them. + +Introducing our `-k` flag in `at_activate enroll`. + +Currently, we have the -k flag which allows the user to specify the key name +they want to use. This is useful for users who want to use a specific key +name, however for apps that read the keys is it not clear which is apkam +and which is a manager key. + +## Goals + +Create a consistent naming convention for APKAM keys. + +### Non-goals + +Specifying the key conventions as defaults in our documentation. + +## Considered Options + +* ### Remove the -k flag as a mandatory flag in at_activate enroll + +Come up with default key name for APKAM keys. The user will still be able +to see which keys are for what using the `at_activate list` command + +Such as: +* `@soccer0_{enrollment_id}_key.atKeys` +* `@soccer0_{hashed_namespace}_key.atKeys` + + +* ### Create a naming convention for APKAM keys in the documentation + +Create a naming convention for APKAM keys in the documentation. + +Right now the default is `@soccer0_key.atKeys`. Which is the same as +the manager key. However we are completely riding on the fact that +the user will get the prompt to NOT overwrite the key. + +Leaving these decisions up to the user is not ideal. When a more +advanced user wishes to use a specific key name, they can use the `-k` flag. + +## Proposal Summary + +Remove the `-k` flag as a mandatory flag in `at_activate enroll` and come up + with a default naming convention for APKAM keys in code. + +## Proposal in Detail + +I'm leaning towards the hashed namespace key name, we would be hashing using the enrollment_id. This would allow the user to see which keys are for what using the `at_activate list` command. + +If we want we could instead include the hash inside of the json of the file. + +### Expected Consequences + +Rewriting the code to include the hashed namespace key name. + +Which include: +* at_activate +* noports +* any other app that would use apkam keys From 7d71c130e35621331386efe65563675b72ad8792 Mon Sep 17 00:00:00 2001 From: Xlin123 Date: Tue, 23 Jul 2024 11:07:38 -0400 Subject: [PATCH 3/5] fix: linter doubleline --- decisions/2024-07-apkam-key-conventions.md | 1 - 1 file changed, 1 deletion(-) diff --git a/decisions/2024-07-apkam-key-conventions.md b/decisions/2024-07-apkam-key-conventions.md index 007b5ee..dc08d17 100644 --- a/decisions/2024-07-apkam-key-conventions.md +++ b/decisions/2024-07-apkam-key-conventions.md @@ -37,7 +37,6 @@ Such as: * `@soccer0_{enrollment_id}_key.atKeys` * `@soccer0_{hashed_namespace}_key.atKeys` - * ### Create a naming convention for APKAM keys in the documentation Create a naming convention for APKAM keys in the documentation. From 1604e6419426752f0eeeed4e39c44e54f033ccd3 Mon Sep 17 00:00:00 2001 From: Xlin123 Date: Tue, 23 Jul 2024 11:11:33 -0400 Subject: [PATCH 4/5] chore: ( --- decisions/2024-07-apkam-key-conventions.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/decisions/2024-07-apkam-key-conventions.md b/decisions/2024-07-apkam-key-conventions.md index dc08d17..72cb601 100644 --- a/decisions/2024-07-apkam-key-conventions.md +++ b/decisions/2024-07-apkam-key-conventions.md @@ -55,7 +55,9 @@ Remove the `-k` flag as a mandatory flag in `at_activate enroll` and come up ## Proposal in Detail -I'm leaning towards the hashed namespace key name, we would be hashing using the enrollment_id. This would allow the user to see which keys are for what using the `at_activate list` command. +I'm leaning towards the hashed namespace key name, we would be hashing using +the enrollment_id. This would allow the user to see which keys are for what +using the `at_activate list` command. If we want we could instead include the hash inside of the json of the file. From 148df6e9fe94d91849fd6a7f453d3856bb28f63b Mon Sep 17 00:00:00 2001 From: Xlin123 Date: Tue, 23 Jul 2024 11:15:14 -0400 Subject: [PATCH 5/5] chore: :(( --- decisions/2024-07-apkam-key-conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/decisions/2024-07-apkam-key-conventions.md b/decisions/2024-07-apkam-key-conventions.md index 72cb601..6a0a85c 100644 --- a/decisions/2024-07-apkam-key-conventions.md +++ b/decisions/2024-07-apkam-key-conventions.md @@ -56,7 +56,7 @@ Remove the `-k` flag as a mandatory flag in `at_activate enroll` and come up ## Proposal in Detail I'm leaning towards the hashed namespace key name, we would be hashing using -the enrollment_id. This would allow the user to see which keys are for what +the enrollment_id. This would allow the user to see which keys are for what using the `at_activate list` command. If we want we could instead include the hash inside of the json of the file.