OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xspa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XSPA TC Call


Event Title: XSPA TC Call

Date: Monday, 23 April 2018, 09:30am to 10:00am PDT
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


RSVP
This meeting counts towards voter eligibility.

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?



Owner: Mohammad Jafari
Group: OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
  • Learn more about subscribing here.
  • View the OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC calendar here.
  • You may receive future notifications with updates to this event. Update the event on your calendar by accepting the changes.

Attachment: ical_47243.ics
Description: application/ics

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:REQUEST
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
BEGIN:STANDARD
DTSTART:20001029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T090000Z
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000402T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T100000Z
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
STATUS:CONFIRMED
TRANSP:OPAQUE
DTSTAMP:20180415T220712Z
DTSTART;VALUE=DATE-TIME;TZID=America/Los_Angeles:20180423T093000
DTEND;VALUE=DATE-TIME;TZID=America/Los_Angeles:20180423T100000
SEQUENCE:0
SUMMARY:XSPA TC Call
LAST-MODIFIED:20180415T220712Z
ORGANIZER:workgroup_mailer@lists.oasis-open.org
ATTENDEE;CUTYPE=GROUP:MAILTO:xspa@lists.oasis-open.org
DESCRIPTION:Dial-in Number (US): (563) 999-2090\nAccess Code: 108403\nIn
 ternational Dial-in Numbers: https://fccdl.in/i/mohammad_jaf
 ari\n\nJoin the Online Meeting: https://join.freeconferencec
 all.com/mohammad_jafari\n\nAgenda: **Administrivia: \n\n- Ap
 proval of the draft minutes from the last meeting on 04/02/2
 018: \n\nhttps://lists.oasis-open.org/archives/xspa/201804/m
 sg00000.html\n\n**XSPA SAML Profile:\n\n- Following the disc
 ussion in the previous TC call\, the XSPA SAML profile is ba
 ck to working draft status. Working Draft 11 was posted\; on
 ly the Principal&#39\;s ID and Purpose of Use are normative 
 now and the rest of the attributes are non-normative.\n\nhtt
 ps://www.oasis-open.org/apps/org/workgroup/xspa/download.php
 /62887/saml-xspa-v2.0-wd12-20180416.docx\n\n- Query-based ex
 change:\n\nDoes resource-id attribute need to exist or be no
 rmative? \nIt is often specified outside of the SAML asserti
 on as part of the overarching protocol. \nThe assertion vouc
 hes for the identity of the requester and its purpose of use
 \, so\, the requester should technically be able to re-use t
 he same assertion when requesting a different resource.\nCon
 sidering 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 eve
 n be known until after the Service Provider processes the qu
 ery and identifies the resources that would be included in t
 he response.\n- Considering the profile includs a non-normat
 ive on JSON formatting\, it can technically can be used in m
 odelling claims in OpenID Connect.\n\n**XSPA XACML Profile:\
 n\n- Do we want to move update the XSPA XACML profile.\n\nTh
 ere doesn&#39\;t seem to be any known implementation.\nBut t
 he profile has been cited in a number of references.\n- If w
 e choose to work on the XSPA XACML profile\, we need to make
  decisions about the following issues:\n\nDo we want to keep
  the attributes which model the content of the patient&#39\;
 s consent directive\, considering that there are several oth
 er standard ways to model them. It seems appropriate to just
  have an attribute to keep a link to the consent directive a
 nd its type.\nDo we want to have a profile of obligations or
  just leave it to the implementers to decide how to model th
 em\, considering that some implementations do not use the XA
 CML policies to model labeling obligations and rely on other
  rules engines?\nGroup: OASIS Cross-Enterprise Security and 
 Privacy Authorization (XSPA) TC\nCreator: Mohammad Jafari
URL:https://www.oasis-open.org/apps/org/workgroup/xspa/event.php?event_id=47243
UID:https://www.oasis-open.org/apps/org/workgroup/xspa/event.php?event_id=47243
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]