[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
I am looking for: >(a) definition within the spec of one
or more identifiers for example OTP methods that may be used by WSS-OTP
implementers desiring to interoperate 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. BTW the WS-I BSP WG seriously considered your
alternative b) when we profiled WSS 1.0 but decided to have separate
conformance URIs for the Core spec and each token profile (e.g. WS-I BSP 1.0
permits you to conform to WSS Core 1.0 and to a token not defined as part of
WSS 1.0). /paulc Paul Cotton, Microsoft From: Linn, John
[mailto:jlinn@rsasecurity.com] By analogy, I wasn’t able to find a
statement within the core WSS spec requiring that all conformant WSS
implementations must support any particular token profile so as to ensure
universal interoperability based on that token profile. Therefore, if I
understand correctly, it would appear that the necessary prerequisite for WSS
interoperability between a pair of peers must require support not only for core
WSS but also, in addition, intersecting support for at least one profile.
The case of support for particular OTP methods below the WSS-OTP profile
seems comparable, at a lower layer; for two given WSS-OTP peers to
interoperate, they must have intersecting support for at least one underlying
OTP method. To clarify, are you seeking (a) definition
within the spec of one or more identifiers for example OTP methods that may be
used by WSS-OTP implementers desiring to interoperate or (b) a requirement that
all conformant WSS-OTP implementations must support one or more specified
methods in order to achieve universal interoperability? If (b),
there’s an apparent need for the specification to identify the required
method(s), but (b) seems inappropriate in the context of a method-neutral
framework. If (a), the need for method identifiers within the spec (vs.
being obtained from independent documents) seems less clear. --jl From: Paul Cotton
[mailto:Paul.Cotton@microsoft.com] 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 From: Linn, John
[mailto:jlinn@rsasecurity.com] 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] 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
From: Anthony Nadalin [mailto:drsecure@us.ibm.com] 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]