Thank you, Cigdem! This ties into additional topics in the main body of the spec as well, since we're now up to the point of figuring out things like: - Can we now remove the MTI (mandatory-to-implement) requirement to introspect tokens, and just let RPTs be whatever kind of OAuth access tokens? -If so, if introspected, does the result still have to be profiled due to the resource set superstructure vs just scopes? - What does this mean for the UMA Bearer token profile? Should it go away, morph, stay the same? - What to say explicitly about refresh tokens, if anything? - What to say explicitly about PoP tokens, if anything? Note that we had discussed some of these potential "added options" under the #IoT roadmap item, e.g., being able to do local token validation at the RS instead of introspection at the AS. Oh, and we do have a tiny oblique mention of PoP in the following section ("holder-of-key-type approach")... We might want to update this now that time has marched on, especially once we've figured out our main-spec approach. https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#redirect-thre... Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Oct 18, 2016, at 9:20 AM, Cigdem Sengul <Cigdem.Sengul@nominet.uk> wrote:
Hello,
Eve suggested that I start the discussion about this in the list.
Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.
In addition, RFC 6750 recommendations may also be referred to in the draft.
Thanks, --Cigdem _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma