On 1 Sep 2015, at 8:27 AM, Maciej Machulak <maciej.machulak@gmail.com> wrote:Eve,
Thanks for all the work towards this draft!!!
Maciej
On Tue, 1 Sep 2015 16:25 Eve Maler <eve@xmlgrrl.com> wrote:I have attached HTML versions of the specs for you review. (I’m not posting them on the site, so that nobody gets the idea they’re finished/vetted.) Many thanks to Maciej for working on a fresh Kantara-specific XSLT transformation! His work isn’t complete, so there are a few formatting/front page things yet to do; don’t worry about those.Everybody please review these formatted specs carefully for ALL the issues you care about, and report any new issues in GitHub Or feel free to send notes to the list or to me privately if you like, and I can collate them. We will discuss everything this Thursday.I think we should probably take the time to continue our review through to Sep 10 if we feel at all rushed, or want to see complete new renditions. This is because, once we exit the 45-day Public Review period, we can no longer make technical changes without going back to square 1. We should be quite sure we’re happy with these drafts when they go into review. (Luckily, I no longer have a conflict with our Sep 10 meeting.)Here are some items that we already know need editing, discussion, or review:
- Don’t forget that there is new wording for permission ticket lifecycle management as discussed last week, which needs your review. See Core Sec 3.2.2.
- Our new wording in response to #161, Protocol assumes one resource owner per URL, says “When a client attempts access to a presumptively protected resource without an RPT,...”. This appears one place in RSR, where I changed “an RPT” to “an access token” and added an [UMA] cross-reference. But in the Core spec, should it say “an access token” generically?
- Maciej and I discussed some questions he had around the RSR security considerations, in RSR Sec 4. What does a “valid web page” (a phrase that came from OAuth’s version) mean? I also recently added a new issue #185, RSR user_access_policy_uri: security considerations, that may have us tweak that section a little further if we think it has merit.
- I actually implemented issue #179, Use OIDC specification style of providing a subsection for every type of response and restructured Core so that every request and response has its own subsection — couldn't resist. :-) Of course, this meant major structural changes! Mostly I rearranged existing text, but I did end up having to rewrite section introductions and invent new introductions. And because Section 3 has a flow to it, I redid how the “flow chart” feel of the entire section works. Now the organization is a bit flatter (there is one bug I’d like to fix, which is that Core Sec 3.3-3.5 should actually be subsections in a single Sec 3.3), and each main subsection contains a consistent “how you got here” intro (and no outro). E.g.: “If the client's request at the protected resource has no RPT, or an invalid RPT or insufficient authorization data associated with the RPT as determined through RPT status checking (see Section 3.6), then assuming the resource server chooses to respond to the client,…”
Thanks in advance, all, for your review and attention.Eve_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma