< Return to Calendar

* XSPA TC Call (Conference Call)
Name * XSPA TC Call (Conference Call)
Time Monday, 23 April 2018, 09:30am to 10:00am PDT
(Monday, 23 April 2018, 04:30pm to 05:00pm UTC)
Description

Dial-in Number (US): (563) 999-2090
Access Code: 108403
International Dial-in Numbers: https://fccdl.in/i/mohammad_jafari

Join the Online Meeting: https://join.freeconferencecall.com/mohammad_jafari

Agenda

**Administrivia: 

- Approval of the draft minutes from the last meeting on 04/02/2018: 

https://lists.oasis-open.org/archives/xspa/201804/msg00000.html

**XSPA SAML Profile:

- Following the discussion in the previous TC call, the XSPA SAML profile is back to working draft status. Working Draft 11 was posted; only the Principal's ID and Purpose of Use are normative now and the rest of the attributes are non-normative.

https://www.oasis-open.org/apps/org/workgroup/xspa/download.php/62887/saml-xspa-v2.0-wd12-20180416.docx

- Query-based exchange:

Does resource-id attribute need to exist or be normative? 
It is often specified outside of the SAML assertion as part of the overarching protocol. 
The assertion vouches for the identity of the requester and its purpose of use, so, the requester should technically be able to re-use the same assertion when requesting a different resource.
Considering the case of query-based exchange, there may not be a specific resource id involved in the transaction and the identifier of the resources fitting in the query may not even be known until after the Service Provider processes the query and identifies the resources that would be included in the response.
- Considering the profile includs a non-normative on JSON formatting, it can technically can be used in modelling claims in OpenID Connect.

**XSPA XACML Profile:

- Do we want to move update the XSPA XACML profile.

There doesn't seem to be any known implementation.
But the profile has been cited in a number of references.
- If we choose to work on the XSPA XACML profile, we need to make decisions about the following issues:

Do we want to keep the attributes which model the content of the patient's consent directive, considering that there are several other standard ways to model them. It seems appropriate to just have an attribute to keep a link to the consent directive and its type.
Do we want to have a profile of obligations or just leave it to the implementers to decide how to model them, considering that some implementations do not use the XACML policies to model labeling obligations and rely on other rules engines?



Submitter Mohammad Jafari
GroupOASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
Access This event is visible to OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC and shared with
  • OASIS Open (General Membership)
  • General Public