[Openid-specs-heart] Comments on the UMA+FHIR profile (and one additional profile comment)

[Eve Maler]

Great stuff!

UMA+FHIR profile:

   - User-Managed Access should have a hyphen throughout.
   - As you already noted, the "openid-heart-fhir-oauth2" needs to be
   changed.
   - Claim semantics: Make this their own section (keeping the positioning
   at Sec 3 is fine), and make sure to register them in the OIDC JWT claims
   registry. We could have a separate section (what is currently the
   introduction to Sec 3) discussing Claims Presentation, but I'm not sure
   this is warranted. Instead, the intro to discussing claim semantics could
   make clear that claims MAY be pushed or interactively gathered. (We haven't
   yet defined any claim profiles for pushed claims, but we should probably
   consider this: OIDC, I assume?)
   - src claim: I wasn't sure if this would keep the same name, but it
   should probably be "licensing" (or "accreditation") "*authority*"
   (rather than "board") to be a bit more generic.
   - Food for thought: For the same reason that "airplane mode" is an
   awkward name for turning off cell signal reception on your mobile device --
   it's too specific -- maybe the "er" claim should be called "btg" to match
   the scope name. But I also wonder if, in practice, there will be other true
   role-based claims that would supplant the er/btg claim in practice. In
   which case, Sec 4.1 could simply have a SHOULD or MUST around enabling the
   resource owner to audit the specific "btg"-related policies in place along
   with making any access ultimately granted auditable and available to the
   resource owner, etc.
   - In UMA2, we've learned that the RS should document its pattern of
   permission requests ("registrations"), and this may be relevant for
   profiling UMA1 as well. It would help the client know what sort of stuff it
   may be getting in its RPT.
   - in Section 4: s/implementors/implementers/


UMA profile:

   - TTL of the PAT: The advice given is generic, referring to the OAuth
   profile. But the PAT specifically needs to be used in an "offline"
   (asynchronous) way most of the time (on client access attempts) and for
   most use cases (when the requesting party isn't the same as the resource
   owner). Should we say something specific about this? The UMA Implementers'
   Guide does
   <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchronousResourceServerAccesstoanAuthorizationServer>
   .


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170227/f03031d7/attachment.html>