OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded


Given points 2 and 4 below, along with a premise that (at least so far as I’m aware) there’s no one widely-implemented candidate algorithm that would exercise the need for all possible parameters, an apparent conclusion is that not all combinations need be tested in order to validate the overall spec.  This conclusion seems reasonable to me. 

 

The rationale for point 3 is unclear to me.  If entities A and B interoperate with underlying algorithm 1, and C and D (or A and D, where A supports both 1 and 2) interoperate with underlying algorithm 2, why would this be a weaker demonstration than having A, B, and C interoperate with algorithm 1 only?  Per the previous paragraph, this may allow for a broader set of parameter combinations to be tested. 

 

Per point 4, I’d think that the primary goal for interoperability testing would be to validate constructs newly defined by the spec, not the ability to perform ordinary XML processing.  Per the cited example, the ability to emit and process an xs:dateTime value or to accommodate its timezone specifiers doesn’t seem like a matter specific to this document.

 

--jl

 


From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Monday, April 03, 2006 11:18 PM
To: Paul Cotton; Hallam-Baker, Phillip; Linn, John; Anthony Nadalin
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 

  1. I agree we should only include identifiers for algorithms which are described in the specification or some other referenced document.
  2. I think we should interop test at least one of these among three or more parties. I don’t think we have to require that every one be interop tested. There are identifiers and algorithms elsewhere in the document set which were never tested. Of course more would be better.
  3. I do not think it is useful to have a series of pair wise tests of distinct algorithms.
  4. I don’t think blackbox testing is sufficient. Each algorithm includes additional parameters. It is important to check that, for example, the software correctly formats and interprets dates and times with proper timezones.

 

Hal

 


From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
Sent: Wednesday, March 29, 2006 11:02 AM
To: Hallam-Baker, Phillip; Linn, John; Anthony Nadalin
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 

> I do not see the need for the algorithm to be specified at all.

 

I think I explained my position on this in [1] in which replied to John’s reply to my message you replied to.  I repeat my position here:

“But I believe we should only include identifiers for OTP methods that:

a)       are implementable under the same terms as the other WSS specs and that

b)       the TC has done interop testing on.”

/paulc

 

[1] http://lists.oasis-open.org/archives/wss/200603/msg00037.html

 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com


From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: March 28, 2006 4:23 PM
To: Paul Cotton; Linn, John; Anthony Nadalin
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 

I do not see the need for the algorithm to be specified at all.

 

As far as this protocol is concerned the OTP sequence can be emulated by a perfectly random sequence. It is a black box as far as the protocol is concerned. The only point where algorithm interoperation is relevant is between the device itself and the corresponding authentication service.

 

If it is causing confusion we can strip out the algorithm identifiers altogether. The only reason they are in at all is to provide one possible means of disambiguating the ID namespace.

 

 


From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
Sent: Monday, March 27, 2006 12:37 PM
To: Linn, John; Anthony Nadalin
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

The minutes for last week’s meeting state:

http://lists.oasis-open.org/archives/wss/200603/msg00026.html

 

>Hal - reasonable to allow any identifier to be used, but spec should only list those that can be used. No need for proprietary identifier to be standardized.

>Chris - concern about references to encumbered algorithms/identifiers.

 

I don’t think the TC was asking for all the identifiers to be removed.   I agree with Tony that we need at least one OTP algorithm and identifier in the spec in order to permit interop testing.  

 

I don’t believe the TC should standardize a spec with an algorithm extensibility point if we do not do any interop testing on that extensibility point.

 

Shouldn’t we leave at least lines 169-171 in the spec and remove lines 172-177?

 

/paulc

 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com


From: Linn, John [mailto:jlinn@rsasecurity.com]
Sent: March 27, 2006 8:21 AM
To: Anthony Nadalin
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 

It’s also possible to demonstrate interoperability on a pairwise basis, using any underlying method for which claimant and verifier sides share common support. I don’t think it’s necessary for any one method to be supported universally.  Note also: it’s possible that a WSS endpoint receiving a WSS/OTP request can and will itself be largely method-independent; rather than validating the OTP value itself, it may instead dispatch it to a separate authentication server where users’ OTP credentials would be stored and any method-specific validation would be performed.

 

--jl

 


From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Sunday, March 26, 2006 10:50 PM
To: Linn, John
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 

I would think that there should be some OTP algorithm (and identifiers) that could be agreed upon so that there could be some level of interop

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Linn, John" <jlinn@rsasecurity.com>"Linn, John" <jlinn@rsasecurity.com>

"Linn, John" <jlinn@rsasecurity.com>

03/24/2006 11:48 AM

To


Anthony Nadalin/Austin/IBM@IBMUS, <wss@lists.oasis-open.org>

cc

Subject


RE: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

 


Lines 137-138 were intended as informative clarification only. They can be deleted without impacting the surrounding content.

Additionally, in recognition of the fact that there is no intent for the document to mandate or constrain the use of particular OTP algorithms, I propose that the current lines 169-178 be replaced with the following text: “This specification does not define identifiers for specific underlying OTP algorithms with which it may be used. Values for such identifiers are defined separately, in conjunction with independent OTP algorithm specifications.”

Given the above changes, it should also be possible to remove corresponding trademark references within the Notices section.

Would these proposals suffice to allay concern about occurrences of trademarks within the document?

--jl


From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent:
Tuesday, March 21, 2006 9:19 AM
To:
wss@lists.oasis-open.org
Subject:
Re: [wss] Groups - OTP Token Consolidated Input Submission (wss-v1 1-spec-os-OTPTokenProfile.pdf) uploaded

Line 133-138 reference a registered trade mark, seems that there are implications of this in a specification, I'm not sure of the reason why it is referenced.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]