http://docs.oasis-open.org/wsfed/issues/
WSFED TC Issues List
Date: 2007/10/16
Revision: 06
spec
schema
soap
wsdl
policy
all
interop
faq
New
Active
Pending
Review
Deferred
Closed
Dropped
OASIS formatted specs
Editors to produce OASIS template formatted version
wsfed
spec
editorial
First F2F
Editors
See Description
OASIS formatted Specs have been uploaded. Status changed to Review.
Status changed to Closed
OASIS spec version
WS-Federation version number should be bumped to version 1.2
wsfed
spec
editorial
First F2F
Editors
See Description
OASIS spec version has been incorporated into the OASIS formatted spec. Status changed to Review.
Status changed to Closed
i001
OASIS WSFED namespaces
Need to define OASIS WSFED namespaces
wsfed
spec
editorial
First F2F
Editors
http://docs.oasis-open.org/wsfed/federation/200706
http://docs.oasis-open.org/wsfed/authorization/200706
http://docs.oasis-open.org/wsfed/privacy/200706
OASIS namespaces have been incorporated into the OASIS formatted spec. Status changed to Review.
Status changed to Closed
Transitive closure spec dependencies
Transitive closure for cascaded references needs to be done to make sure that cascaded versions don't reference other spec versions
wsfed
spec
editorial
First F2F
Marc Goodner
See Desription
Complex claim data types
The Common Claims Dialect defined in WS-Federation supports only strings. Do we need a way to support more complex structured data types?
wsfed
spec
editorial
First F2F
Anthony Nadalin
WSFED FAQ
Need to write a FAQ for the WSFED TC home page
faq
faq
editorial
First F2F
Hal Lockhart
TC Members should review Hal's submission in preparation for vote for approval at the next meeting.
Status changed to Closed
Claim Type references
Claims are typed by URI. The type URI is not guaranteed to resolve. Where would a potential user of a claim type go to understand the semantics associated with a claim type? Should a claim type include a resolvable reference of some sort?
wsfed
spec
design
First F2F
Marc Goodner
Basically since claims are typed by
URI there was a question of 'are the claim type URI's guaranteed to
resolve?'. ANSWER: No. The WSFED spec can't change this since this
is clearly outside the control scope. Therefore, this issue should
be ultimately be closed by updating the spec with an editorial comment/
clarification that explicitly states out of spec. and that URI's are
not guaranteed to resolve. Issue Action: Leave as pending and assign
to the editors.
Changes applied in ed-02, status changed to review.
Status changed to closed on Oct 16th call.
Sign-out notification and priority
From banking industry it is important to establish when the user signed out. It is important to notify the user that they have sign-out. It is also important that if the user is notified that they have signed out, then it is absolutely the case that they are. Sign-out requests are browser redirects from IP to different web Services, but what is the priority/order of these redirects? Sharing some configured sign out priorities would allow the higher risk services, like banking services, to be configured accordingly.
Firstly I would like to clarify on the specification documentation (ws-federation-1.2.-spec-ed-01.doc).
http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/ws-federation-1.2-spec-ed-01.doc.
According to the depiction III.9.3 of Sign-Out the IP redirects a browser to clean-up at one
service provider and then once complete redirects a browser to clean-up at the next service provider.
This diagram depicts sequential, not parallel sign-out, even though section 4.2 states that parallel
approach SHOULD be used for sign-out. The same depiction also indicates some sort of reply being sent
from service providers indicating clean-up complete, while in section 4 of the document (first paragraph)
there is a statement about sign-out being a one-way message without any reply.
Now to expand on ISSUE i008
There were really three points there:
(1) Identity provider should be certain (as much as possible with stateless protocol framework) that sign-out requests sent to service providers were processed successfully.
In the proposed architecture sign-out is a one-way message. Therefore it is not possible to provide a confirm/reply that session is terminated. I would argue that sign-out should have a reply indicating successful session termination. Some parameter should specify to the requestor that the cleanup is completed at the service provider.
(2) Priority of sign-out was the second point
I will withdraw priority request from the issue, once I get confirmation on my clarification above that parallel sign-out is being used not sequential sign-out. If parallel sign-out is used prioritizing does not add any value.
(3) Informing the user about completed sign-out.
Once Identity Provider receives success sign-out replies from service providers (1) IP should be able to indicate to a passive requestor that sign-out was completed. If some service providers did not return a success reply to a sign-out request a user should be presented with that information as well. I realize that this may be beyond the score of the specification but it is not possible without (1).
wsfed
spec
design
Paul Lesov
Paul Lesov
Proposal accepted, assigned to editors
Changes applied in ed-02, status changed to review.
Status changed to closed on Oct 16th call.
Use of ds:KeyInfo in fed:TokenSigningKeyInfo Element
The sentence beginning at line 927 states: "Any top-level element legally allowed as a child of the ds:KeyInfo element
(as per [XML-Signature]) can appear as a child of the wsse:SecurityTokenReference
element."
The ds:KeyInfo element itself is can appear as a child of the wsse:SecurityTokenReference
element. There is no need for the explicitly call out the top-level child elements of ds:KeyInfo.
wsfed
spec
design
Marc Goodner
Editors
Proposal accepted, assigned to editors
Changes applied in ed-02, status changed to review.
Status changed to closed on Oct 16th call.
WS-Federation Conformance Clause
The Revised OASIS Technical Process requires all specifications to contain a conformance clause. We need to provide one for WS-Federation.
wsfed
spec
editorial
Marc Goodner
Editors
Proposal accepted, assigned to editors
Changes applied in ed-02, status changed to review.
Status changed to closed on Oct 16th call.
Add a "Supported Claims Dialect" element To FederationMetadata
The specification allows a federation provider to advertise supported claim types but there is no means to advertise the specific dialects in which those claims may be expressed. The ability to advertise supported claims dialects should be added to federation metadata.
wsfed
spec
editorial
Marc Goodner
Editors
Proposal accepted, assigned to editors
Changes applied in ed-02, status changed to review.
Status changed to closed on Oct 16th call.
Editorial changes to Section 2.7 Attributes, Pseudonyms,and IP/STS Services and section 5 Attribute Service
The WS-Federation 1.1 specification is inconsistent with respect to its recommendations about the potential interface to Attribute Services. Section 2.7 specifically identifies the STS model as a baseline interface to Attribute and Pseudonym services. Section 3.1.8 defined federation metadata for advertising an Attribute Service instantiated as an STS. However, section 5 states no interface is defined for an Attribute Service. Besides being contradictory, the wording in section 5 ignores the reusability of the WS-Trust STS service model and token issuance protocol as a potential interface for advanced federation services that is clearly recommended as an optional approach in other sections of the specification.
See message for more.
wsfed
spec
editorial
Don Schmidt
Editors
Proposal 1 accepted, status changed to pending on Oct 16th TC call.
Encoded wresult
There are two reasons why the next version of WS-Federation should support an optional requestor-advertised wresult encoding scheme.
See message for more.
wsfed
spec
editorial
Marc Goodner
Marc Goodner
Abbie will forward the conference bridge details to Mike McIntosh who will incorporate them into the agenda.
Done
Greg to send a note to Paul Lesov requesting further clarification of issue i008, preferably in the form of a proposal to resolve the issue.
Done