ga4gh / data-security Goto Github PK

Conformance for Embedded Token Signatories section:
...the Embedded Token Signatory could set the exp to 14 days into the future in order to force a user authentication flow to be redone if a downstream Claim Clearinghouse is still interested in using such a claim after this period elapses

Claim Source Revokes Claim section:
Expiry timestamps would require users to log in occasionally via an Broker in order to refresh claims.

I don't think a new log in is necessarily needed if an (access) token expires. For expired access token, a refresh token can be used (by the client). For expired document token, whatever means supported by the Embedded Token Signatory can be used (this spec imposes no requirement for the the user to ever log in to an Embedded Token Signatory).

We want an FAQ with suggestions and examples that don't fit into the main spec. Some ideas so far:

• Discussion on how to use SPAs (with a backend for token exchange)
• Sequence diagrams showing examples of using token exchange

"Infrastructure security – security features and processes provided as part of the data or application service offering GA4GH service providers and user organizations should assure that their networks, operating systems, applications, and database management systems isolate software processes and datasets to prevent interference and side-channel attacks. A "least privileges" approach should be used to harden execution environments."

We should maybe add "Code security" which is different. Things like (maybe under Operations security?):

• Forced Pull Request Review (protected branches)
• Source code analysis for downstream library vulnerabilities (snyk/sourceclear)
• Preventing secrets from being in code (git-secrets/trufflehog)
• Static code analysis

If using CI/CD platforms like Travis, make sure there is security if allowing PRs from outside of your organization. PRs are essentially running arbitrary code so make sure things like secrets can't be compromised.

GA4GH JWT Format section:
The access token and JWT with full claims use the same format, though the JWT with the full claims will have extended claims.

Terms full claims and extended claims are not used elsewhere in the document. Can you add descriptive text or a well define term?

Claim Polling: Clients MAY use access tokens, including Embedded Tokens,...

Can this be renamed to "access token polling" just to indicate (and avoid a misconception) that this is for using an (embedded) access token to poll claims in userinfo but there is no mechanism defined for polling embedded document tokens.

Conformance for Claim Clearinghouses section item 2.i.a.b:
This includes checking the signature of Embedded Tokens that the Claim Clearinghouse may wish to use

This requirement is valid per se but in a weird place. This section defined the checks a claim clearinghouse must do to access tokens, not to embedded tokens.

There is also a wider question if access token validity check (item 2.i.a) is necessary at all before the /userinfo request as the /userinfo will reject invalid access tokens anyway.

We currently have duplicated the Jekyll publish workflow into one pipeline for drafts and one for main (with minor differences).

We could refactor the common workflow bits into a shared workflow that is callable from the two workflows.

The current 4.2.2 Jekyll used for building the spec has a minor but annoying issue in its Docker build - so we are pinned to the previous release.

When the next Jekyll is released - it will have a fix - so that will allow us to get all sorts of jekyll improvments over the last two releases..

jekyll/jekyll#9095

Access authorization through application programming interfaces (APIs) should be implemented using the OAuth 2.0 Authorization Framework (RFC 6749) [11].

As the AAI spec comes online, it is likely to bump up against the specifics of this alittle. Authorization in the AAI spec is TECHNICALLY Oauth but it's more accurate to say that that it's evaluation of OIDC Claims than it is OAuth scopes. We should make sure that these two docs match in their accuracy.

Make visibly consistent links and cross reference when appropriate

Embedded Access Token Format section:
4. The payload claims MUST contain at least one GA4GH Claim ()

Do we still keep this requirement, given the size of embedded claims?

N.B. This requirement is not present in Access_token issued by Broker section , disabling a broker from placing an access token given by an upstream broker to a downstream embedded token.

See for example FHIR

http://hl7.org/fhir/directory.html

(Proposed prior to 2022-05-20 call.)

remove doubles

Remove double definitions like “Claim Source/Passport Visa Assertion Source” by moving definitions to AAI spec and referencing them from the Passport spec.

in AAI spec:

Claim Source -> Visa Assertion Source
Claim Repository -> Visa Assertion Repository
Claim Clearinghouse -> Passport Clearinghouse
in definition of Visa Issuer - replace "GA4GH Claims" with “Visa Assertions”
move definition of Visa from Passport Spec to AAI spec, not "A GA4GH Claim value or entry within a list or object of a GA4GH Claim that contains a JWT"

in Passport Spec:

Passport Bearer Token -> Passport-Scoped Access Token (reference to AAI spec)
Passport Visa -> Visa (reference to AAI spec)
Passport Visa Assertion Source -> Visa Assertion Source (reference to AAI spec)
Passport Visa Assertion Repository -> Visa Assertion Repository (reference to AAI spec)

Section "Conformance for Brokers" of the AAI spec says

"Access tokens do not contain GA4GH Claims directly in the access token."

However, section "Embedded Access Token Format" says

"The payload claims MAY contain at least one GA4GH Claim ()."

I understand that the intention is that a Broker may decide to embed an upstream broker's access token to a downstream passport. Therefore, the spec would be more consistent if claims would be excluded from embedded access tokens, too.

Embedded Document Token Format section:

jti: RECOMMENDED. A unique identifier for the token as per RFC7519 Section 4.1.7 is RECOMMENDED.
However, jti is not present in the example.