ER013 2119 terms for SC proposal

Here is my analysis for SC. The others will look the same
when I get to them.

 

ER013 – SC

Changes needed

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

Line 236 

If a token provides multiple keys then specific bindings and
profiles MUST describe how to reference the separate keys

 

Line 356 

In order for the security token service to process this
request it MUST have prior knowledge for which Web Service the requestor needs
a token

 

Line 612

the requestor is REQUIRED to re-authenticate the original
claims in every renewal request

 

Line 757

Using a common secret, parties MAY define different key
derivations to use.

 

Line 758

In order to keep the keys fresh (prevent providing too much
data for analysis), subsequent derivations MAY be used

 

Line 784 

The nonce seed is REQUIRED

 

Line 802

When a new key is required, a new <wsc:DerivedKeyToken> MAY be
passed referencing the previously generated key

 

Line 843

then a fault such as wsc:UnknownDerivationSource SHOULD be
raised.

 

English usages – No changes required

Line 192 “It should be noted”

Line 224 “Consequently producers of <wsc:SecurityContextToken>
tokens should consider”

Line 229 “Care should be taken”

Line 316 “It should be noted”

Line 317 “As receipt of these messages may be
expensive, and because a recipient may receive multiple messages”

Line 345 “As with all token services, the options
supported may be limited.  This is especially true of SCTs because the
issuer may only be able to issue tokens for itself”

Line 348 “SCTs are not required to have lifetime
semantics. That is, some SCTs may have specific lifetimes and others may be
bound to other resources rather than have their own lifetimes.”

Line 350 “it allows the optional extensions defined
for the issuance binding including the use of exchanges”

Line 358 “This may be preconfigured although it is
typically passed in the RST”

Line 365 “It should be noted”

Line 527 “It should be noted”

Line 534 “This binding allows optional
extensions”

Line 608 “This binding allows optional
extensions”

Line 611 “Because the security context token issuer is
not required to cache”

Line 757 “For example, four keys may be derived”

Line 802 “When a new key is required”

Line 805 “then additional token exchanges are not
required”

Line 875 “It should be noted”

Line 898 “then care should be taken”

Line 1025 “For a variety of reasons it may be
necessary to reference a Security Context Token”

Line 1090 “It should be noted” “should be
careful”

Line 1128 “It should be noted” “should be
carefully reviewed”

Line 1130 “should be careful”

Line 1131 “It may be desirable to use running hashes
as challenges that are signed or a similar mechanism to ensure continuity of
the exchange.”

Line 1156 “It should be noted”

Line 1174 “Depending on the type of challenge used
this may not be necessary because the message may contain enough entropy to
ensure a fresh response from the recipient.”

Line 1188 “This request may or may not be secured
depending on whether or not the request is anonymous”

 

All terms in section 10 are English and properly not capped,
no change

 

Schema exemplar description changes

Many issues with OPTIONAL and REQUIRED in the schema
exemplar descriptions. These are straightforward and I recommend that if the
above is acceptable that the editors simply produce a redline version for
review.