RE: Comments from J.Durand

[Mike Jones <Michael.Jones@microsoft.com>]

Hi Jacques,

 

Your comments are tracked as issue IMI-40.  The committee’s resolutions to your comments are as follows:

 

1. The specification does not provide a means for exchanging supported claim type encoding.  This occurs out of band.  No change was made to the specification.

2. Conforming parties are either IPs or RPs.  Any assertions they produce must conform to these specifications. We do not believe there is a need for a third conformance target.  No change was made to the specification.

3. The TC believes the specification is consistent as written and no change is necessary.  No change was made to the specification.

[ Show » ]

Marc Goodner added a comment - 10/Jun/10 11:43 AM 1. Specification does not provide a means for exchanging supported claim type encoding, occurs out of band 2. Conforming parties are either IPs or RPs, any assertions they produce must conform to these specifications. We do not believe there is a need for a third conformance target. 3. The TC believes the specification is consistent as written and no change is necessary.

 

Thanks for your participation.

 

                                                                -- Mike

 

From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
Sent: Friday, June 04, 2010 7:42 PM
To: imi-comment@lists.oasis-open.org
Subject: [imi-comment] Comments from J.Durand

 

 

Review of specification:

SAML V1.1 Information Card Token Profile V1.0

SAML V2.0 Information Card Token Profile V1.0

 

------------- comments apply to both specs:

 

1- Is there any way to notify the behavior of Relying Party w/r to what is accepted / not accepted, e.g.

"Implementations MAY accept claim types encoded using the convention where..."

How is the implementation supposed to communicate that it does not accept these (any error or warning to be generated?)

 

2- Reading the conformance clause, it sounds like there are 3 conformance targets, not just 2:

(a) Identity Provider implementation

(b) Relying Party implementation

(c) assertions

Since the concept of consistent (or conforming) assertion is so important to

"implementations" (a and b) as these are actually evaluated on their ability to handle such assertions

shouldn't the conf clause also define what a conforming assertion is and more explicitly refer

to the related normative text (which I feel are not just restricted to section 2.3.3. ?)

 

3- Conformance Clause editorial:

- " A Relying Party implementation conforms to this profile if it can accept assertions consistent with the

normative text of Section 2.4. "

Not only I believe: because the assertions it is supposed to accept are also to be consistent with 2.3.3.

Might be resolved by addressing comment #2.

- Given the very concise wording of the conformance clause, it might be helpful to

clarify that being "consistent with the normative text" actually means that the implementation

only needs to behave consistently with normative statements using MUST / MUST NOT

(as readers might wonder what does it mean to be consistent with a SHOULD statement...).

 

Regards,

Jacques D.

Fujitsu America, Inc.