Skip to content

Commit

Permalink
Changes from 0.9.6
Browse files Browse the repository at this point in the history
  • Loading branch information
kirky61 committed Sep 24, 2019
1 parent 1c83bc8 commit f22d5d2
Show file tree
Hide file tree
Showing 18 changed files with 836 additions and 464 deletions.
8 changes: 2 additions & 6 deletions slate/source/includes/_security.md.erb
Original file line number Diff line number Diff line change
Expand Up @@ -328,8 +328,7 @@ In order to achieve this:
## Identifiers and Subject Types
The identifier for an authenticated end-user (subject) MUST be passed in the `sub` claim of an [ID Token](https://openid.net/specs/openid-cocnnect-core-1_0.html#IDToken) and [UserInfo response](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse) as defined by **[OIDC]**.

The Data Holder MUST generate the `sub` value as a Pairwise Pseudonymous Identifier (PPID)
as described in [section 8](https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes) of **[OIDC]**. Furthermore, the identifier SHOULD also be unique relative to the scenario in which the end-user has authenticated. For example, the identifier generated for the same person when they are using a business account SHOULD be different to the identifier that is generated when that same individual is authorising as an individual.
The Data Holder MUST generate the `sub` value as a Pairwise Pseudonymous Identifier (PPID) as described in [section 8](https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes) of **[OIDC]**. Furthermore, the identifier MUST be unique per customer as per the definition of customer in the CDR Federation section of this profile.

It is RECOMMENDED that the `sub` value is generated as a version 4 Universally Unique
Identifier (UUID) **[RFC4122]**.
Expand Down Expand Up @@ -414,15 +413,14 @@ Only the following cipher suites SHALL be permitted in accordance with [section
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"claims": {
"sharing_duration": "7776000",
"id_token": {
"sharing_duration": "7776000",
"acr": {
"essential": true,
"values": ["urn:cds.au:cdr:3"]
}
},
"userinfo": {
"sharing_duration": "7776000",
"given_name": null,
"family_name": null
}
Expand All @@ -436,8 +434,6 @@ Request Objects MUST be signed by Data Recipients as specified in [section 8.6](

Request Object references SHALL NOT be supported.

The `iss` claim SHALL NOT be supported as it duplicates the role of the `client_id` claim.

## Requesting Sharing Duration
To facilitate the specification of the duration for consent to share CDR data that is approved by the consumer, a mechanism for the Data Recipient to specify a sharing duration to the Data Holder is required.

Expand Down
2 changes: 1 addition & 1 deletion slate/source/includes/_standards.md.erb
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Standards

These standards represent **version 0.9.6** of the high level standards which will support the creation of version 1. See the [versioning section](#versioning) for more information on how versions are managed in the standard.
These standards represent **version 1.0.0** of the high level standards which will support the creation of version 1. See the [versioning section](#versioning) for more information on how versions are managed in the standard.

Note that, in this proposal, the key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in [RFC2119](http://tools.ietf.org/html/rfc2119).

Expand Down
21 changes: 16 additions & 5 deletions slate/source/includes/cds_admin.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,11 @@ Indicate that a critical update to the metadata for Accredited Data Recipients h
}
```

###Endpoint Version
| | |
|---|--|
|Version|**1**

<h3 id="metadata-update-parameters">Parameters</h3>

|Name|In|Type|Required|Description|
Expand All @@ -73,7 +78,7 @@ Indicate that a critical update to the metadata for Accredited Data Recipients h
|200|x-v|string||The [version](##response-headers) of the API end point that the data holder has responded with.|

<aside class="success">
This operation may only be call by the CDR Register
This operation may only be called by the CDR Register
</aside>

## Get Metrics
Expand Down Expand Up @@ -113,21 +118,26 @@ $.ajax({

`GET /admin/metrics`

This end point allows the ACCC to obtain operational statistics from the Data Holder on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.<br/><br/>Note that for all applicable requests currentDay is defined as the current day beginning at midnight AEST.
This end point allows the ACCC to obtain operational statistics from the Data Holder on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.

###Endpoint Version
| | |
|---|--|
|Version|**1**

<h3 id="get-metrics-parameters">Parameters</h3>

|Name|In|Type|Required|Description|
|---|---|---|---|---|
|period|query|string|optional|The period of metrics to be requested. Values can be CURRENT_DAY (meaning metrics for current day), HISTORIC (meaning metrics for previous days or months) or ALL. If absent the default is ALL.|
|period|query|string|optional|The period of metrics to be requested. Values can be CURRENT (meaning metrics for current day), HISTORIC (meaning metrics for previous days or months) or ALL. If absent the default is ALL.|
|x-v|header|string|mandatory|Version of the API end point requested by the client. Must be set to a positive integer. The data holder should respond with the highest supported version between [x-min-v](#request-headers) and [x-v](#request-headers). If the value of [x-min-v](#request-headers) is equal to or higher than the value of [x-v](#request-headers) then the [x-min-v](#request-headers) header should be treated as absent. If all versions requested are not supported then the data holder should respond with a 406 Not Acceptable. See [HTTP Headers](#request-headers)|
|x-min-v|header|string|optional|Minimum version of the API end point requested by the client. Must be set to a positive integer if provided. The data holder should respond with the highest supported version between [x-min-v](##request-headers) and [x-v](##request-headers). If all versions requested are not supported then the data holder should respond with a 406 Not Acceptable.|

#### Enumerated Values

|Parameter|Value|
|---|---|
|period|CURRENT_DAY|
|period|CURRENT|
|period|HISTORIC|
|period|ALL|

Expand Down Expand Up @@ -268,7 +278,7 @@ This end point allows the ACCC to obtain operational statistics from the Data Ho
|200|x-v|string||The [version](##response-headers) of the API end point that the data holder has responded with.|

<aside class="success">
This operation may only be call by the CDR Register
This operation may only be called by the CDR Register
</aside>

## Schemas
Expand Down Expand Up @@ -760,3 +770,4 @@ This operation may only be call by the CDR Register
### Properties

*None*

Loading

0 comments on commit f22d5d2

Please sign in to comment.