[OASIS Issue Tracker] (COEL-180) Provide a mechanism for SP to authorize forgetting consumer

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

    [ https://issues.oasis-open.org/browse/COEL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67841#comment-67841 ] 

Joss Langford commented on COEL-180:
------------------------------------

Current first paragrpah to 7.2.12:
Request that a Consumer associated with this Operator be forgotten by the Data Engine. This operation MAY not proceed synchronously, as the Data Engine MUST confirm the request with the Service Provider associated with the requesting Operator. The mechanism for confirmation is out of scope of the MMI, e.g. email confirmation. The Data Engine MAY either delete all data associated with the Consumer or render that data non-personal. 

Proposed new first paragraph to 7.2.12:
Request that all data for a Consumer associated with this Operator be forgotten by the Data Engine. The Data Engine MUST confirm requests with the Service Provider associated with the requesting Operator individually before proceeding as the initial request does not require authorisation. The mechanism for confirmation is out of scope of the MMI, e.g. email confirmation. The Data Engine MAY either delete all data associated with the Consumer or render that data non-personal. 

> Provide a mechanism for SP to authorize forgetting consumer
> -----------------------------------------------------------
>
>                 Key: COEL-180
>                 URL: https://issues.oasis-open.org/browse/COEL-180
>             Project: OASIS Classification of Everyday Living (COEL) TC
>          Issue Type: Bug
>            Reporter: David Snelling
>            Assignee: David Snelling
>
> We need to design a simple mechanism to allow SPs to control forgetting of Consumers. In the present implementation it always happens, which is spec compliant with the out of band channel being a SP/DE standing agreement to always forget a Consumer when requested by the Operator. Clearly not ideal.



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