[OASIS Issue Tracker] (OSLCCORE-68) Extend access context to support notion of delegation

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/OSLCCORE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Crossley updated OSLCCORE-68:
----------------------------------

    Proposal: 
Proposal - Provide delegated access control
• Add a new property acc:type=acc:delegated to identify that the accessContext should be read from another resource, using the acc:accessContext value.

Clients SHOULD detect infinite delegation loops. To reduce the cost of client processing, servers SHOULD NOT use more than 5 levels of delegation for a given access context.

Example:

Some work items are assigned to iteration 30, which is being managed by team A. I want an easy way to be able to change that team assignment from team A to team B, so I do not want to embed the team access context in every work item.

<https://a.example.com/defect/2314> acc:accessContext <https://a.example.com/access/context12345> .
<https://a.example.com/defect/5678> acc:accessContext <https://a.example.com/access/context12345> .

<https://a.example.com/access/context12345>
   a acc:AccessContext ;
   dcterms:title "Iteration 30 access context" ;
   dcterms:description "This is the access context for work items for iteration 30; it delegates to the access context for the team currently responsible for that iteration." ;
   acc:type acc:delegated ;
   acc:accessContext <https://a.example.com/access/context56789> .

<https://a.example.com/access/context56789>
   a acc:AccessContext ;
   dcterms:title "Team B access context" ;
   dcterms:description "This is the access context for the team for team B; various iterations delegate to me." .


  was:
Proposal - Provide delegated access control
• Add a new property acc:type=acc:delegated to identify that the accessContext should be read from another resource, using the acc:accessContext value. 

Example:

Some work items are assigned to iteration 30, which is being managed by team A. I want an easy way to be able to change that team assignment from team A to team B, so I do not want to embed the team access context in every work item.

<https://a.example.com/defect/2314> acc:accessContext <https://a.example.com/access/category1/iteration30> .
<https://a.example.com/defect/5678> acc:accessContext <https://a.example.com/access/category1/iteration30> .

<https://a.example.com/access/category1/iteration30>
   a acc:AccessContext ;
   acc:type acc:delegated ;
   acc:accessContext <https://a.example.com/access/teams/teamA> .



> Extend access context to support notion of delegation
> -----------------------------------------------------
>
>                 Key: OSLCCORE-68
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-68
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Nick Crossley
>            Assignee: James Amsden
>
> There are examples of scenarios where the access context of a large number of resources is affected by an external change.  For example, in a task tracking system, you might need to update the access for a large number of tasks if the work is reassigned to a different release, or to a different team.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)