1. Entity Management. The requestor should be able to request
life-cycle control over an entire entity
<element
name="ManageSubjectRequest" type="samlp:ManageSubjectRequestType"
/>
<complexType name="ManageSubjectRequestType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<choice>
<element name="AddSubject"
type="samlp:AddSubjectType"/>
<element name="ModifySubject"
type="samlp:ModifySubjectType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
You will notice that there is no "DeleteSubjectType". Reading the original
2.0 spec, the delete could be handled by ManageNameIDRequest - Terminate.
I'm not sure this is the current intended use. Would it be appropriate
to modify the use for this purpose here?
2. Managing attributes would be part of the "ModifySubject" operation.
<complexType name="ChangeValueType">
<sequence>
<choice>
<element ref="saml:Attribute"/>
<element ref="saml:EncryptedAttribute"/>
</choice>
</sequence>
</complexType>
<complexType name="ModifySubjectType">
<sequence>
<choice>
<element ref="saml:NameID"/>
<element ref="saml:EncryptedID"/>
</choice>
<sequence>
<choice>
<element name="AddAttributeValue"
type="samlp:ChangeValueType"/>
<element name="DeleteAttributeValue"
type="samlp:ChangeValueType"/>
<element name="ReplaceAttributeValue"
type="samlp:ChangeValueType"/>
</choice>
</sequence>
</sequence>
</complexType>
The big change here is that in addition to simply adding an attribute,
requestors can request delete or replace operations.
I also agree, there are things to be sorted out such as namespace and
signing (what is signed and who is signing). IMHO at minimum the requesting
service needs to sign the transaction somehow. In the ideal world, a token
representing the requesting end-user would also make sense though it may not
be needed in all cases. The requirements for signing would have to be
dictated by the site receiving the modify request (e.g. IDP).
Finally, one other item that will need to be solved. In the use cases
described, it is quite reasonable that the requestor may only be able to make
these operations as "suggestions" and that the IDP receiving the operation is
not obligated to process them or interpret them exactly as specified. The key
requirement as I see it, is to have enough semantics in the SAML request to
make it clear to the IDP what the requesting service provider is asking for.
More request "context" for the IDP means more data to base a decision
on.
There will also be other metadata requirements such as governance, privacy,
and assurance that may have to fit within these requests.
Finally, I have a feeling, there is some information we can learn from
SPML2 as applied to messaging that may be of use in these
discussions.