- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2017-04-20
by Eve Maler 19 Apr '17

19 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 21 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html> and RReg is up to 08 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html> (back to editors' drafts) - Most issues were proactively closed because we had good consensus on substantive issue discussions and/or the issues were editorial - What was done (you've had this list since Monday): - #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) - #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) - #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) - #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) - Your turn to yell (*before* the call) if you're not happy with this - *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): Should have a concrete proposal for discussion - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses): a "flattened" claim token in native form-urlencoded format was implemented in Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back> -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation, so let's review - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303>* (Cleaning up the security considerations: JSON Usage): Possibly pass a quick eye over this one - *New:* *#304 <https://github.com/KantaraInitiative/wg-uma/issues/304>* (Do we need the UMA error invalid_request?): Let's consider this - *#297 <https://github.com/KantaraInitiative/wg-uma/issues/297>* (Add the authorization process flowchart or some other visual explanation): To be closed without action unless someone speaks up - Logistics/timing - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New editor's drafts: Core rev 21 and RReg rev 08
by Eve Maler 18 Apr '17

18 Apr '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd In these drafts you will find the following issue implementations (mostly closed): #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) #298 <https://github.com/KantaraInitiative/wg-uma/issues/298>: Reconsider whether ticket should be on all redirect-back AS responses core (see Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back>) -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) Please do check over the new text and examples, and the swimlane summary, and see what you think. Also please note that there are still a couple of issues that could use your opinion! *Existing:* #303 <https://github.com/KantaraInitiative/wg-uma/issues/303>: Cleaning up the security considerations: JSON Usage and OIDC for client authentication *New:* #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the UMA error invalid_request? I'm going to turn my full attention to the spec refactoring proposal now... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #295: Token revocation not that simple?
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/295 This was our token revocation discussion. It seemed so simple on our call on Thursday: Just define a new token type hint keyword, say "pct". But reading RFC 7009, I'm not sure that's quite the end of it. Token revocation requires <https://tools.ietf.org/html/rfc7009#section-2> authenticating the identity of the resource owner at the authorization endpoint a la OAuth Sec 3.1 <https://tools.ietf.org/html/rfc6749#section-3.1>. Of course, by analogy, that would be using the claims interaction endpoint for us, but we allow a lot more flexibility in our authorization process, e.g. pushing claims etc. And this isn't just because it's an asynchronous grant. So I think we need to do a bit more "surgery". I can't think of any reason why the client shouldn't be able to go ahead and ask to revoke any RPT it has, even if the RqP isn't around. Is that legit? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Issue #293: Not-that-editorial: example of pushed claims needs to be form-urlencoded
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/293 Hi folks-- Please take a look at the latest comment in this issue, which highlights what started as an editorial issue but discovered a (potentially minor) decision point around how the client pushes claims to the AS's token endpoint. Because we've gone from UMA1's custom RPT endpoint which takes JSON payloads to UMA2's regular OAuth token endpoint which takes form-urlencoded payloads, our carried-over spec text talking about a JSON-formatted claim_tokens structure -- combined with an old example -- needed an update. *The proposal:* An update that changes the actual structure of claim pushing slightly, so that: - It's a truly native and streamlined form-urlencoded format. - The client pushes a single claim token (say, one ID token) and can't push a bunch of them. The theory is that we'd normally think it odd to send a set of ID tokens or SAML assertions or whatever anyway, so the old design that had an array was probably overdesigned. I'm going to try this out in the latest editor's draft unless somebody tells me they were already using the multiples feature... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Full discussion on issue #298: Reconsider whether ticket should be on all redirect-back AS responses
by Eve Maler 15 Apr '17

15 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/298 Since a subset of the WG (Just, Robert, and me) kept going for about 30 minutes after Thursday's call ended, I said I'd pull out this part of the notes to highlight it for everyone and ensure you have a real chance to think about it. This was a really fascinating discussion. Our conclusion was that the redirect-back from the claims interaction endpoint, rather than try to duplicate the token (was RPT) endpoint status messages as it had kind of been doing, should sync up *directly* with what OAuth does instead. The basic thing it needs to achieve (as far as the client actually cares) is "yes, continue, everything went fine" or "something went wrong". If you *don't* agree, shout now! (I'm going to try and implement this in the next editors' draft so you can see what you think...) ==== *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end? *(The formal meeting ended and we kept going ad hoc.)* *Redirect-back:* Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop. Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>. Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference). *Token request:* Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process. Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used. - invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change) - invalid_scope: no - request_submitted: yes (a change) - need_info: - not_authorized: remove (a change) *AI:* Eve: Send separate note to the WG proposing this and asking for feedback. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: Will we have critical mass if we meet on Friday at 8am PT?
by Eve Maler 14 Apr '17

14 Apr '17

Hi all-- Tim has a draft of deliverable #2 for us to look at; we met today about it. But I know it's Good Friday, and many people may be taking off. Who is available to meet? Please let me know and I'll make a decision by tomorrow (Thursday) noon my time. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Legal: European Data Protection Supervisor publishes "toolkit" -- a checklist!
by Eve Maler 14 Apr '17

14 Apr '17

https://edps.europa.eu/sites/edp/files/publication/17-04-11_necessity_toolk… Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Notes from UMA telecon 2017-04-13
by Eve Maler 13 Apr '17

13 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-13 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09>: Deferred. Logistics - The Apr 11 ad hoc (which was quorate) worked through <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/G_cPnocQ8…> *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT)* - Concrete proposal for spec refactoring (*#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling)*) *may* be ready for consideration in Apr 20 meeting - Let's see if we can work through the rest of the open substantive issues in this meeting UMA V2.0 work *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* The Token Revocation spec (a coarse-grained mechanism of positively rescinding one's granted access from the client side) "should work" as usual; in this case, the client would be acting on behalf of the RqP instead of the RO. For any fine-grained recision, a la "I want to keep read access, but rescind write access" (or "I want to still get access to the trunk but rescind access to driving the car"), the client could simply ask for few scopes, but there's in-band way (OAuth or UMA) for the client to confirm that it then received the fewer scopes it wanted. The point of the issue is that Bob takes on accountability/responsibility/liability from the moment access is granted, whether or not he ever drives the car. The general idea <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> is that the juncture at which the technical artifact is issued has a corresponding agreement/contract. But if the client previously asked for "trunk" and "drive" scopes, but now asks for only "trunk", and the RS's documented pattern that it executes is to still always ask for "drive" scope, then our *RequestedScopes* set in that later calculation will still have "drive" in it because of the *PermissionTicket* portion. However, there's evidence from the client's request at the token endpoint that it *wished* to have fewer scopes. Is this enough to reduce Bob's accountability, if the token it gets back still has "drive" scope in it? This doesn't seem strong enough, but "fine-grained revocation" seems like a stretch goal for now anyway. Does the Token Revocation spec (RFC 7009 <https://tools.ietf.org/html/rfc7009>) work the same way for UMA? Justin says it should work the same, as the RPT is just an access token. What about revoking the PCT? What's the motivation for revoking a PCT? They're useful/usable across RPTs, but we wouldn't want to revoke RPTs that were issued on the basis of some PCT. The point of token revocation generally is security hygiene, allowing a client to clean up after itself and let the AS record that the client did so. Justin suggests an (optional) method for leveraging the existing token revocation mechanism, providing some sort of "pct" keyword as a new token type hint. We'd have to add more IANA registry stuff. The AS is required *not* to say what it did in response to the revocation request, in order not to give an attacker with a stolen token TMI. *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end? *(The formal meeting ended and we kept going ad hoc.)* *Redirect-back:* Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop. Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>. Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference). *Token request:* Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process. Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used. - invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change) - invalid_scope: no - request_submitted: yes (a change) - need_info: - not_authorized: remove (a change) *AI:* Eve: Send separate note to the WG proposing this and asking for feedback. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Eve 3. Cigdem Non-voting participants: - Robert - Justin - Ishan - Jin - Bjorn *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-13
by Eve Maler 12 Apr '17

12 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-13 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> - Logistics: - The Apr 11 ad hoc (which was quorate) worked through <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/G_cPnocQ8…> *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT)* - Concrete proposal for spec refactoring (*#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling)*) *may* be ready for consideration in Apr 20 meeting - Let's see if we can work through the rest of the open substantive issues in this meeting - UMA V2.0 work: - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 20 <https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html> and RReg is up to 06 <http://docs.kantarainitiative.org/uma/wg/oauth-resource-reg-2.0-07.html> (WG drafts; no change) - *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis - *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* Main issue seems to need no action, but a related issue came up about the appropriateness of not_authorized as an error that we could consider - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303> (Cleaning up the security considerations: JSON Usage):* Possibly pass a quick eye over this one - AOB - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA ad hoc telecon 2017-04-11
by Eve Maler 11 Apr '17

11 Apr '17

*Tuesday 9-10am PT* *Dial-in and screenshare:* http://join.me/findthomas *Calendar:* http://kantarainitiative.org/confluence/display/uma/Calendar *(if you are currently not being invited to WG meetings and want to be, or the reverse, let me know)* Attending: Eve, Robert, Justin, John, Cigdem, Prabath, Mike, Domenico, Maciej (quorum!) Our current substantive open issues look like this: - *#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling):* This is a biggie. Current proposal (*for which I hope to have some more details by call time!*) is to consider a different way of modularizing the specs. A group consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this further in London last Monday and there was a pretty strongly favorable impression. Eve reviewed her approach. Implied in the refactoring is two “operational modes”, that is, it would be possible to use the extension grant without using the federated authorization piece. Justin suggests that this is a 2.1-phase action, on the theory that it’s almost certainly backwards compatible. Mike likes the approach and is supportive of the suggested timeline. So commit to only going as far as backwards compatibility allows? Yes. Justin estimates that a 2.1 would be a 6-12 month effort. This sounds like a long time to Eve. :-) A big motivation is adoptability of even the 2.0 specs as they are, so she’d like to try the refactoring sooner. Before we make a decision, Eve agrees to create a second, more detailed proposal that amounts to draft specs on a branch that can be examined for viability. She’ll do this by Apr 21. - *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT):* This topic is broader by now, including token binding etc., and we suspect this all might "just work". This just needs to be analyzed a bit. *Prabath*, you were going to take a look -- can you, please, and write up? Prabath sent a nice writeup <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/EUVEot8ZM…> summarizing the state of play. Justin: RFC 7662 (token introspection) notes <https://tools.ietf.org/html/rfc7662#appendix-A>, in an appendix, that there’s — presumably — an extension being written to finish the unfinished PoP piece. Some options for our purposes: 1. Say nothing, since we incorporate (and profile) 7662. 2. Point explicitly at this language so that there is a mention of PoP. 3. Point explicitly at this language and add commentary regarding the need for extensions etc. 4. Define an extension ourselves at this juncture. 5. Mention in an appendix, a la 7662, the places where PoP would affect UMA but not do the work. This is like 2 but is more hands-off. Discussion: Eve’s rationale for no. 2 or 3 (prior to Justin’s suggesting no. 5) is that mentioning proof of possession in the spec would give implementers something to hang onto to answer their questions. Cigdem points out that we do mention PoP, in Sec 6.1.1. However, this is actually a different meaning, referring to the RqP’s proof, not the client’s proof, so should we remove this usage of the phrase and stick to “holder of key” instead (SAML-like)? We have consensus around no. 5. Eve proposes putting a new subsection in Sec Consid, discussing security properties of the RPT, modeling the language after the 7662 language. Let’s do that. Speaking of Sec 6.1.1, it really has two attacks in it: innocent Bob/malicious Carlos but also malicious Bob handing off the RPT to his malicious friend Carlos. There’s very little we can do about the latter other than legal enforcement remedies. (This has been called “ABC” for the Alice-and-Bob Collusion attack.) Note that the OAuth WG has rejected this as a form of attack. Some options: 1. Do nothing. Rationale: OAuth has chosen not to dignify the ABC attack. 2. Clarify that 6.1.1 is about innocent Bob, and if Bob is malicious, these mitigations are largely ineffective, but the premise of an access token is that the receiving side MUST keep it secure. No appetite for no. 2, so we keep the status quo. - *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis. *Justin*, this could use your eyeballs in particular, but it's really for *everyone*. - *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* Justin and Cigdem have been commenting on this one and seem to have consensus so far that we're okay, but it could use more eyeballs. But another related issue has come up about the appropriateness of not_authorized as an error that we could consider. Deferred to Thursday. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Apr 10, 2017 at 11:40 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > *Tuesday 9-10am PT* > *Dial-in and screenshare:* http://join.me/findthomas > *Calendar:* http://kantarainitiative.org/confluence/display/uma/Calendar > *(if you are currently not being invited to WG meetings and want to be, or > the reverse, let me know)* > > Our current substantive open issues look like this: > > - *#290 > <https://github.com/KantaraInitiative/wg-uma/issues/290> (Generality of > RReg spec?) and #296 > <https://github.com/KantaraInitiative/wg-uma/issues/296> (Out-of-the-box > profiling for tight AS-RS coupling):* This is a biggie. Current > proposal (*for which I hope to have some more details by call time!*) > is to consider a different way of modularizing the specs. A group > consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this > further in London last Monday and there was a pretty strongly favorable > impression. > - *#294 > <https://github.com/KantaraInitiative/wg-uma/issues/294> (Consider a > proof-of-possession option for the RPT):* This topic is broader by > now, including token binding etc., and we suspect this all might "just > work". This just needs to be analyzed a bit. *Prabath*, you were going > to take a look -- can you, please, and write up? > - *#295 <https://github.com/KantaraInitiative/wg-uma/issues/295> (When > a requesting party needs to withdraw their access):* This touches on > downscoping and token revocation, and thus could use some analysis. > *Justin*, this could use your eyeballs in particular, but it's really > for *everyone*. > - *#298 > <https://github.com/KantaraInitiative/wg-uma/issues/298> (Reconsider > whether ticket should be on all redirect-back AS responses):* Justin > and Cigdem have been commenting on this one and seem to have consensus so > far that we're okay, but it could use more eyeballs. But another related > issue has come up about the appropriateness of not_authorized as an > error that we could consider. > > > *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | > Twitter: @xmlgrrl > >

1 0