Re: [provision] Issues in spec draft 08

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Thank you. Responses inline below. Not sure about the last issue.

Raepple, Martin wrote:

> 1. Another syntax error in the <listTargetsResponse> example:
> In targets 1 & 2 <capabilities> section (p. 35/36), all 
> referenceDefinition elements are closed just before any subelement is 
> listed.
>
> So the following lines should be changed:
>
>     * <referenceDefinition typeOfReference=”owner”/> to
>       <referenceDefinition typeOfReference=”owner”>
>     * <referenceDefinition typeOfReference=”memberOf”/> to
>       <referenceDefinition typeOfReference=”memberOf”>
>     * <referenceDefinition typeOfReference=”owns”/> to
>       <referenceDefinition typeOfReference=”owns”>
>
Spec issue #29. AGREED.

> 2. There is some confusion with the status code "success": In all the 
> examples, the status code for succeeded responses is set to "success". 
> But in the spec, there are several (normative) sections where the term 
> "succeeded" is used instead and should be replaced with "success". 
> These are:
>
>     * 3.1.3.3.1 Requestor specifies synchronous execution (normative),
>       Line 469: If the provider’s response specifies
>       “status=’succeeded’”, then the provider’s …
>     * 3.1.3.3.3 Provider chooses synchronous execution (normative),
>       Line 504: If the provider’s response specifies
>       “status=‘succeeded’”, then the provider’s response ..
>     * 3.5.1.1.2 Response (normative), Line 875: Target. A
>       <listTargetsResponse> that specifies “status=’succeeded’” MUST
>       contain …
>
Spec issue #30. AGREED.

> 3. Just a thought: In the listTargetsResponse example (p. 35/35), the 
> password capability is assigned to both Account and Person. But since 
> Person owns Account based on the reference definition, this doesn't 
> this really make sense in my opinion. Only Account should contain all 
> the elements related to authorization. So for a more realistic 
> scenario, the password capability should be removed for Person and 
> Account may have an additional element password.
>
Spec issue #31. NOT SURE.

I tend to agree with you (that it SHOULD be as you say), but in my 
experience most Identity Management Systems represent a Person as an 
object with a password. (In a way, you could say that most represent a 
Person as an Account that is not tied to any specific resource (or target)).

There's not a lot of clarity on this point--I think we intentionally 
muddy the water because there is not yet a notion of a universal 
namespace for identity. Instead we have "islands" of identity.

I believe that the examples would probably work either way, but I think 
it may be more straightforward and more commonplace to say that Person 
has a password.

How strongly do you feel about this issue?