[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Issues in spec draft 08
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]