RE: [provision] Issues in spec draft 08

["Raepple, Martin" <martin.raepple@sap.com>]

Hi Gary,

I'm fine with that - for clarity of the example, I think
it is more important to have either Person or Account assigned
to the Password capability, but not both. But anyway, this issue
is really of (very) low priority.

Regards
Martin 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Dienstag, 24. Mai 2005 16:37
To: Raepple, Martin
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Issues in spec draft 08

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?

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php