<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 2:32 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">The requesting party token (RPT) does indeed have associated with it one or more "permissions", which are data structures that look similar to resource set descriptions. The relevant section is <a href="https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#uma-bearer-token-profile" target="_blank">UMA Core Sec 3.4.2, RPT Profile: Bearer</a>.<div><br></div><div>So to correct the syntax a bit, it would look like this:</div><div><br></div><div><div><font face="monospace, monospace">   {<br></font></div><div><font face="monospace, monospace">    "active": true,</font></div><div><font face="monospace, monospace">    "exp": 1256953732,</font></div><div><font face="monospace, monospace">    "iat": 1256912345,</font></div><div><font face="monospace, monospace">    "permissions": [</font></div><div><font face="monospace, monospace">      {</font></div><div><font face="monospace, monospace">        "resource_set_id": "112210f47de98100",</font></div><div><font face="monospace, monospace">        "scopes": [</font></div><div><font face="monospace, monospace">          "...",</font></div><div><font face="monospace, monospace">          "...",</font></div><div><font face="monospace, monospace">          "...",</font></div><div><font face="monospace, monospace">          "..."</font></div><div><font face="monospace, monospace">         ],</font></div><div><font face="monospace, monospace">        "exp" : 1256953732</font></div><div><font face="monospace, monospace">      }</font></div><div><font face="monospace, monospace">    ]</font></div><div><font face="monospace, monospace">   }</font></div></div><div><br></div><div>Instead of mentioning the resource set name or any such details, it just calls out the relevant resource set ID as registered at the AS, and then explicitly mentions the particular scopes that are granted. (So the resource set with this ID might be of the "virtual clipboard" kind.)</div></div></blockquote><div><br></div><div>OK that makes sense!   Understood RS registers RSsets but miss the ID piece on response</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div><br></div><div>The RPT would have gotten populated this way based on the original availability of a registered resource set, as outlined in the previous couple of messages (a CREATE of the structure with the fields I described), and a requesting party passing muster, such that their client got this RPT.</div><div><br></div><div>Clearly, designing a resource set of a "virtual clipboard" kind would be coming from an "Alice shares data before/at a first visit" use case. Note that giving a resource set like this scopes such as "<span style="font-size:12.8px">patient/MedicationDispense*.</span><span style="font-size:12.8px">read</span>" would be a way to enable "positive filtering" of content. (I still don't readily understand the FHIR OAuth scope syntax -- need to look up how to parse this! What's the English for it, again?)  </div></div></blockquote><div><br></div><div>I don't know about the English but I was just looking at the FHIR doc and OAUTH scope doc to figure out what the syntax information.</div><div><br></div><div>Still doesn't answer my question of how to provide additional "claims" info we may want the RS to be aware of.   Trying to understand John's suggestion that we use confidentiality codes as a start instead of consent  - where is sensitivity determined?  Seems that may be on the RS server side.  Is he suggestion that a consumer/patient could suggest confidentiality settings for the scopes/resources suggested?   Alternatively - how would consent be expressed?   Is that outside the RPT?    I understand there may be separate services but could/should that information be included in the token.</div><div><br></div><div> </div></div></div></div>