search

ehealthsuisse / ch-epr-fhir

Repository for the swiss implementation guide for the FHIR based profiles
3 stars 5 forks source link

ITI-71: Varia #78

Closed unixoid closed 8 months ago

unixoid commented 1 year ago

  1. Section 3.1.4:

    • IUA authorization request has an optional parameter resource. In the IG, this parameter is not mentioned. Is it prohibited or does it remain optional?
    • Would it be possible to enrich the text in the column "Step" with arrow numbers from the UML diagram? For example, "[01] The mHealth App sends a HTTP GET request to the IUA Authorization Server endpoint."
    • In the table, "mHealth App" is used as actor name, which is not present on the UML diagram. Proposal: in the UML diagram, put "User Agent" and "Authorization Client" into the box "mHealth App".
    • The contents of the column "Step" for the third message are split into three pieces. For better readability, please join these pieces.
    • At the same place: "HTTP basic authorization header" -> "HTTP basic authentication header".
    • The contents of the column "Step" for the fourth message mention "HTML body". Probably, "HTTP body" was meant here.
    • The last row of the table references the issue #20 which is already closed and states "there is no token refreshment".

  2. Some parts of messages are described in section 3.1.4 "Messages", other parts -- in section 3.1.6 "Message Semantics". Would it make sense to combine these sections?

  3. There is an unwanted connotation between "extended access token" and "HCP/ASS/PAT/REP extensions" (sections 3.1.6.1.x) -- a reader may think that using those extensions will make an access token an extended one. Proposal: rename "HCP/ASS/PAT/REP extensions" to "HCP/ASS/PAT/REP flavors". (Another reason why they should not be called "extensions" is that it is not possible to avoid using them or to use more than one of them in the same request.)

  4. Section 3.1.6.1:

    • The scopes (claims) group and group_id do not correspond to EPR specifications. In EPR, an assistant can serve only individual healthcare practitioners and not groups.
    • The scope access_token_format supposes that the Authorization Server can produce tokens of different formats. But in the metadata (ITI-103), the server can specify only one format.

  5. In the example of token request, the Content-Type shall be application/x-www-form-urlencoded instead of application/x-www-form-encoded.

msmock commented 8 months ago

Split the ticket to individual issues #133 ... #139