Maybe one more while I’m at it:Inspired by Farazath’s recent question; the discussion and resolution of #163/#164/#168 concluding that the RS has quite a lot of HTTP status discretion; and this wording in Core Sec 3.5... “assuming the resource server chooses to respond to the client, it MUST give access to the desired resource” , I’m thinking we should reassess old issue #15: Must the host [RS] give access if the requester [client] has suitable permission?.At the time, we resolved it with softer wording than we have now — “When a requester presents a valid access token, the host SHOULD provide the requester with access to the desired resource. Note that that access to resources at a host remains at the discretion of the host, even in cases where the requester has presented a valid access token." — but we apparently never published the softer wording as an I-D, and undid the decision by rev 03.I remember that we discussed just keeping MUST because there’s nothing UMA can do about the RS’s actions, but it may make sense to be clear to RS developers and deployers that UMA is “discretionary access control”, and an RS always has the right to refuse service (so to speak), same as an authentication RP.EveOn 1 Sep 2015, at 9:34 AM, Eve Maler <eve@xmlgrrl.com> wrote:_______________________________________________Labor of love. :-) By the way, a couple of more editing/discussion/review items for this thread:
- Our two IETF I-Ds from the Recommendation versions of the specs (Core, RSR expire on Oct 6. We haven’t yet concluded our newly reopened discussion about the IETF Independent Submission/Informational RFC route, but I suspect it’s a good idea to keep updating the I-Ds for now, since, why not…?
- There’s a minor structural edit I’d like to make to Core Sec 3.6 and 3.6.1, to consolidate more of the token introspection info from the introduction into the subsection.
EveOn 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
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma