Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BACK-2165] [BACK-2164] [BACK-2163] Add app attestation and assertion api documentation. #58

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

lostlevels
Copy link

This adds attestation and assertion documentation. Attestation is the verifying an app is a valid instance of an iOS app and assertion is requesting a secret of some kind after attestation is verified.

I was debating whether to split this into its own reference/attestation.v1.yaml file or not as it's not technically auth I don't think but it is part of the auth service to avoid creating a new service, but decided for simplicity to define the routes in reference/auth.v1.yaml.

@@ -0,0 +1,4 @@
title: Base64
type: string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use the format value to indicate base64 encoding of the string type: https://swagger.io/docs/specification/data-models/data-types/ - but I like the explicit pattern

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use the format value to indicate base64 encoding of the string type: https://swagger.io/docs/specification/data-models/data-types/ - but I like the explicit pattern

I'm not against the explicit pattern at all, but I would like to see a $ref to his used in more places, so that I don't have to squint at the regexp in so many different places and try to double-check that there wasn't a cut and paste error made. :)

tjotala
tjotala previously approved these changes Feb 21, 2023
Copy link
Member

@tjotala tjotala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

This adds attestation and assertion documentation. Attestation is the verifying
an app is a valid instance of an iOS app and assertion is requesting a secret
of some kind after attestation is verified, in this case X.509 certificates
that can be used for client authentication.

Add response to successful assertion.
Copy link
Contributor

@ewollesen ewollesen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good, just a typo or two.

Most of my suggestions can be taken or left.

@@ -998,3 +1094,21 @@ components:
required:
- code
- reason
AppChallenge:
description: 'Challenge generated by server and which client should use in later operations.'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider a re-wording?

Suggested change
description: 'Challenge generated by server and which client should use in later operations.'
description: A server-generated challenge proving a client application's identity to Tidepool.

partner:
description: Code name of partner to retrieve certificate from.
type: string
minLength: 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is an enum, then minLength is not necessary, and can only confuse things, right? I suggest removing this.

Suggested change
minLength: 1

type: object
properties:
challenge:
description: The previously returned assertion challenge.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what a client receives after posting to /v1/(assertions|attestations)/challenges right?

The body of that call is a JSON object, but this property is defined as a string, so probably that means it's base64 encoded? If so, that should be called out here.

Or does the endpoint expect the original JSON object supplied, in which case this isn't a strong really at all, but rather an object as defined in ./auth/models/appchallenge.v1.yaml.

Or if it's a string, but not base64 encoded, well, that'd be bad, it should be base64 encoded, else you run into a lot of quote-escaping issues and things get really ugly.

$ref: './keyid.v1.yaml'
description: Base64 encoded key Id received from Apple App Attest API.
required:
- attestation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- attestation
- assertion

Based on the filename and line 5 of this file, I assume this was a typo?

pattern: '^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$'
description: Base64 encoded data received from Apple App Attest API. User must base64 encode the binary data received from Apple.
challenge:
type: string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment on the challenge field of assertionverify.v1.yaml.

@@ -0,0 +1,10 @@
title: New App Challenge
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I wouldn't bother putting "new" in the filename or title... It isn't important, and can only confuse people (was there an older one?)

Comment on lines +5 to +8
keyId:
type: string
pattern: '^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$'
description: Base64 encoded key Id received from Apple App Attest API.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
keyId:
type: string
pattern: '^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$'
description: Base64 encoded key Id received from Apple App Attest API.
keyId:
$ref: './keyid.v1.yaml'

type: object
properties:
csr:
description: Base64 encoded certificate signing request.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the details matter... The Coastal request data indicates that it is "base64 encoded DER certificates".

Here, it says only "Base64 encoded"... Is it like Coastal, in that it's base64 DER, or rather, is it PEM (which is also base64 encoded, but with a slightly alternative structure).

Not a big deal to call it out, but you could save someone a bit of head scratching.

properties:
body:
type: string
description: PEM encoded certificate.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In another comment, I mentioned a difference between "base64 encoded", "base64 encoded DER" and now it gets even weirder as we add "PEM" to mix.

So I urge you be consistent and exact in these terms to save people headaches later.

@@ -0,0 +1,4 @@
title: Base64
type: string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use the format value to indicate base64 encoding of the string type: https://swagger.io/docs/specification/data-models/data-types/ - but I like the explicit pattern

I'm not against the explicit pattern at all, but I would like to see a $ref to his used in more places, so that I don't have to squint at the regexp in so many different places and try to double-check that there wasn't a cut and paste error made. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants