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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Re: [security-services] Groups - Change Notify Protocol 02(saml-2.0-notify-draft-02.zip) uploaded


After further reading, ManageNameIDRequest Terminate seems reasonably
equivalent to disable|suspend, and NewID to enable|resume. So, no,
enable/disable is not distinct from ManageNameIDRequest.

The RetireSubject definition states "... that the record is to be
retired or de-provisioned". I was looking for clarification as to what
action "retired" describes, as distinct from de-provisioning.

Tom

On Mon, Sep 20, 2010 at 4:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> Tom,
>
> I think it depends on whether the definition needs to change transaction by transaction. For example if parties want to signal "deactivate" and/or "delete" in different operations then an attribute to qualify the operation might be needed.  Otherwise, yes, the definition is defined in the SLA.
>
> Note also, there is still the original SAML ManageNameIDRequest which allows for de-federation and is distinct.  Would you see enable/disable as distinct from this operation?
>
> Phil
> phil.hunt@oracle.com
>
>
>
>
> On 2010-09-20, at 1:54 PM, Tom Zeller wrote:
>
>> Given that the RetireSubject action is defined by the Issuer/Target
>> SLA, what operation would be appropriate to reinstate (un-retire) a
>> subject ?
>>
>> In a NewSubject -> ModifySubject -> RetireSubject lifecycle, is
>> RetireSubject -> NewSubject the next step ?
>>
>> Perhaps "retirement" is similar to SPMLv2 disable|enable
>> (suspend|resume), which seems different than de-provisioning
>> (deleting).
>>
>> TomZ
>>
>> On Mon, Sep 20, 2010 at 3:13 PM,  <phil.hunt@oracle.com> wrote:
>>> Working Draft 02 of ChangeNotify Protocol. Incorporates feedback from Scott
>>> and others as well as edits to references etc.
>>>
>>> Some items (e.g. profiles) are still to be completed, after discussion of
>>> section 2 is finished.
>>>
>>> We will review this document at the Sept 21 weekly TC call.
>>>
>>>  -- Mr. Phil Hunt
>>>
>>> The document revision named Change Notify Protocol 02
>>> (saml-2.0-notify-draft-02.zip) has been submitted by Mr. Phil Hunt to the
>>> OASIS Security Services (SAML) TC document repository.  This document is
>>> revision #1 of saml-2.0-notify-draft-01.zip.
>>>
>>> Document Description:
>>> Working Draft 02 of Change Notify Protocol. This document specifies how
>>> SAML service providers can notify each other of changes to subjects and
>>> subject attributes and negotiate a protocol (e.g. SPML) for facilitating
>>> transfer of changes.
>>>
>>> This document is a potential replacement for the previous proposal
>>> &quot;Subject Management Protocol 03&quot;.
>>>
>>> View Document Details:
>>> http://www.oasis-open.org/committees/document.php?document_id=39438
>>>
>>> Download Document:
>>> http://www.oasis-open.org/committees/download.php/39438/saml-2.0-notify-draft-02.zip
>>>
>>> Revision:
>>> This document is revision #1 of saml-2.0-notify-draft-01.zip.  The document
>>> details page referenced above will show the complete revision history.
>>>
>>>
>>> PLEASE NOTE:  If the above links do not work for you, your email application
>>> may be breaking the link into two pieces.  You may be able to copy and paste
>>> the entire link address into the address field of your web browser.
>>>
>>> -OASIS Open Administration


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