Subject: [Ace] Review of draft-ietf-ace-oauth-authz-06

From: Jim Schaad <[email-masked]>
Date: Fri, 4 Aug 2017 14:41:22 -0700

As promised I finally got finished with this review.

1.  Need to decide if /token, /introspect and /authz-info are under
/.well-defined or not.  If they are then this needs to be noted and there
needs to be an IANA action if this has not already been done for OAuth.

2.  Add some of the actor terms to section 2- such as Resource Owner

3.  Still unhappy about the lack of POP between C and AS.  How does the AS
know that the key it is binding to the token is the right one.  The RS has
no problems, but assumes that the AS did its job.

4.  If I want to use the SCOPES field as defined by Carsten, then I do not
want the current restriction that is being imposed on the scope parameter in
Section 3 (?) Under "Scopes and Permissions".

5. In section 3.2 - s/so- called// - don't be pejorative.

6. In section 4 - 2nd paragraph before figure 1 - I want the ACE profile to
provide one method to do this.  There may be others that are specific to the
profile however.

7.  In section 4 - Under "ACE Profiles" - RECOMMENDS seems to be an odd
thing to have here - this is not really a protocol recommendation is it?
Are we allowing for JSON to be used rather than CBOR?  The text here on what
encodings to use could be made more declarative.  Are we expecting any JSON
use at this point for any profile define?  If so then a list of tradeoffs
for profile creators and how to detect would be in order rather than the big
RECOMMENDS.

8.  Section 5.1 - Awkward language "If the client should to act"

9. Section 5.3 - Is this really what you want to say is that one SHOULD
authenticate C to the AS?  I think this is a MUST.  I question if this is
really something that profiles should do rather than this document.  I
thought that the profiles were targeted at the C <-> RS conversation.

10.  Section 5.4 appears to create a new endpoint that has not been
discussed in other contexts.  Is this intentional?

11. Section 5.5.1 - OK - I am reversing thinking.  However I need to get a
summary of what a profile is going to need to specify a long ways before I
get to this point.  Perhaps has part of the overview.  One of the questions
is going to be can the C-AS section of one profile be used with the C-RS of
another profile and keep the same security guarantees.  The overview is
going to need to talk about this at some point.

12. Section 5.5.1 - I would like to add some additional parameters at this
point.  The first is a RS_Data field which is copied from the RS->C message
verbatim.  It allows for encrypted data to be passed from the RS to the AS
as part of the request.  Data type is COSE_Encrypt.

13. Section 5.5.1 - I would like to see an AS field documented here so th
that the 4 corner model can work.

14. Section 5.5.1 - What is the default - use this for "aud"?  How is a
client supposed to know what to put here for a new RS?

15. Section 5.5.1 - on cnf - Use "It is RECOMMENDED that an AS reject a
request with a symmetric key" as this is positive and where enforcement is
done.

16. Figure 3 - This example no longer looks correct.  the content type
should be the same as for Figure 2.  That is assuming it is really CoAP and
not HTTP?

17. Figure 4 - need to check out if client_secret is a real secret or not -
it seems odd to say don't use symmetric and then have an example of passing
one. Could be something else as I don't have RFC 6749 w/ me.

18. The set of operations should start with the C->RS response structure
from DTLS profile as this is really the first thing that happens.

19. Is there a reason for a client not being able to request a profile
rather than having it be configured into the AS?

20.  Section 5.5.2 - You are not being constant about encoding - this is
saying MUST be CBOR while earlier it was only a recommendation,

21. Section 5.5.2 - Post figure 5 it says examples - but only one example
exists.

22. Section 5.5.4.2 - Please make the abbreviations mandatory not optional.
I don't really want to support both.

23. Section 5.5.4.4 - Please define profile as being part of a CWT so that
it can be communicated to the RS in the event that more than one profile is
supported. Optional if RS only does one.

24. Section 5.5.4.5 - I don't know if it would not be cleaner to have a cnf
that is only for the client key info and an rs_cnf (defined for
introspection) that is for dealing with the RS keys.  That makes it cleaner
when looking a the case of an AS->C or an AS->R->C message as the fields
will be the same.

25. Section 5.5.4.5 - Figure 9 does not really make sense by itself.  It
needs to have some context because it looks the same as for a RS key.

26. Section 5.5.4.5 - Figure 10 is not formatted correctly as the map
wrapping is missing on unprotected.

Look @ section 3.3. RFC 6749 about scopes

27. Need to know how to think about the idea of a client doing an
introspection.  Is the response going to be different than a RS doing the
query?  I assume that the distinction would be based on the authentication
and internal knowledge - does not need to be documented except for response
differences.

28. Figure 14 needs to be updated

29. Section 5.6.2 - Need to add rs_cnf - if more than one key need to tell
the RS what key to use.

30. Section 5.6.4 - I think this is a required item if introspection is
going to be able to return a random symmetric key.  Not needed otherwise.

31.  Section 5.6.4 - last para - may want to state that this secret is
established at the same time that the token is established.

32. Section 5.6.4 - establish MTI algorithms here?

33. Section 5.7 - I think that you need to add rs_cnf in the event of an RS
w/ multiple keys so it knows which to use. usage would be optional.

34. Section 5.7 - last paragraph - should be JOSE and COSE not JSON and
CBOR.

35. Section 5.7.1 - Why would the RS respond with the cti - given a lack of
text it is not clear when the MAY would be triggered.

36. Section 5.7.1 - Not sure how much information is being leaked by having
different error codes being returned in these situations.  May only want to
have one code.

37.  Section 5.7.1 - under what circumstances is the introspection request
not made?  If the introspection request is done async how is the client
token communicated back to the client?  Would that be done as part of a
later access.  Seems to be dicey.

38.  Random thought - Is there a requirement that the same method be used
for both posting to /authz-info and to the resource?  Could one use OSCOAP
for one and DTLS for the other?  Question is because we are profiling and
the assumption is that profiles are whole.

39.  Section 5.7.2 - Last bullet - should note that tokens need to be shared
to the RS - AS may issue lots of tokens but if RS gets none then no
expirations

40.  Section 5.7.2 - Another "long running request" might be the case of
sending back an ACK for a request followed by a 4.01 because the token
expires before the request has finished processing.  Re-doing introspection
might also cause this sequence of messages

41. Section 6 - personal preference - remove the first sentence it is not
useful.

42. Section 6 - Protection is from signature or MAC - but we are using AEAD
for most of these.  Should probably have a security consideration that AEAD
is preferred to MAC in most cases because of confidentiality as well.

43. Section 6- the phrase 'long-term key shared with RS' implies to me that
this is a symmetric key.  May want different language to allow for people
thinking of asymmetric keys as well.

44. Section 6  - Please explain to me how targeting multiple RS with an
asymmetric key is a problem - change it form shared secret to symmetric key.

45.  Section 6- I think you want to use a different term than token replay
in this paragraph.  If a RS is rebooted and loses all token information,
there is nothing wrong with a C doing a replay of the token to the RS to get
access to the resources as long as it is still valid.

46. Section 6 - Is the confidentiality protection a requirement for
asymmetric keys as well?  -- Oh - and it may not be a session key, the
session key for DTLS is established later, it is just a POP value (or key if
asymmetric)

47. Section 6 - Sentence structure of this paragraph is difficult.  The AS
does not use shorter key sizes, it will perhaps create shorter POP keys.
However, even this may be a problem depending on how short they are.  A
tradeoff is going to occur here with the ability to record and later decrypt
keys depending how short the keys are.

47.  Section 6 - the next to last paragraph is a repeat - but probably
clearer.

48.  Section 6 - Please explain the reasoning behind the last paragraph.  It
does not make a great deal of sense to me.

49.  Section 7 - I don't understand what you are trying to say with the last
sentence in the second paragraph.  Given that the AS still needs to do ACL
control, this does not make sense to me.

For now I skipped IANA considerations and the appendixes.

Let me know if you would prefer that I place these items into the issue list
on github or if you prefer doing it.  

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 07 Aug 2017 11:16:11 +0200

> needs to be an IANA action if this has not already been done for OAuth.

Another option would be more flexible: You could have a well-defined
(and IANA-registered) resource type that allows linking to the token-
introspect and authz-info endpoints. In the /.well-known/core of
as.example.com, you would find

</token>;rt="auth-request"

or, in a resource directory, you could link to as.example.com's token
endpoint as follows:

</token>;rt="auth-request";anchor="coaps://as.example.com/"

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 7 Aug 2017 15:03:58 +0200

> As promised I finally got finished with this review.

Thank you for your very thorough review Jim. Comments inline (note that 
there are a few questions as well).

/Ludwig

> needs to be an IANA action if this has not already been done for OAuth.

I've added an issue to our issue tracker on this. However I would think 
that this is something that would need to apply to OAuth as well.

> 2.  Add some of the actor terms to section 2- such as Resource Owner

Ok, will do

> no problems, but assumes that the AS did its job.

I'm not sure what problem that would solve. That C binds the token to a 
key it doesn't own? What benefit would C have from that?

If C wants to relay a token to a "friend" it could always share the 
pop-key with said friend.

> Section 3 (?) Under "Scopes and Permissions".

I'm just reiterating the definition of the scope parameter from the 
OAuth spec. I think Carsten's approach can be modified to fit into that 
spec.

> 5. In section 3.2 - s/so- called// - don't be pejorative.

Ok, I'll rephrase that

> provide one method to do this.  There may be others that are specific to the

I've already made that change in the "insertDiscovery" branch 
(https://github.com/LudwigSeitz/ace-oauth/tree/insertDiscovery).

> for profile creators and how to detect would be in order rather than the big

You mean section 5 right?

Yes the intention is to allow profiles to specify JSON (or something 
else) as data format instead of CBOR.

> 8.  Section 5.1 - Awkward language "If the client should to act"

Yeah that whole section needed a review. Fixed.

> thought that the profiles were targeted at the C <-> RS conversation.

My intention for the profiles is that they specify the communication 
(and communication security protocols). This MUST cover C <-> RS and MAY 
include AS <-> *any*.

I agree there should be a default fallback for the MAY parts. Adding issue.

> discussed in other contexts.  Is this intentional?

No that's just an existing OAuth endpoint. Since I've had mostly on 
client credentials in mind, this endpoint wasn't discussed that much.

My impression is that this endpoint would mostly be used by 
non-constrained clients (towards the obviously non-constrained AS), and 
therefore it wouldn't need an ACE profiling, it could just be used as 
specified in OAuth.

> get to this point.  Perhaps has part of the overview.  

The summary of what a profile needs to specify is collected in Appendix 
C currently. This appendix reiterates points that are spread out (in 
contextually appropriate places) in the main body of the spec.

> One of the questions

This seems to be a "it depends" issue. We should have some text on this, 
the security considerations seem the right place to me for this. 
Creating issue.

> as part of the request.  Data type is COSE_Encrypt.

Are you referring to the "nonce" that can be part of the AS discovery 
message?  I'm not sure if that should go in this document or in a 
separate draft. What does the group think?

> that the 4 corner model can work.

Could you be more specific about the "4 corner model"? I'm not familiar 
with that.

> .

"aud" should contain be the identifier of the RS or a group of RS that 
the client wants to access.

Since the client ought to know which RS it wants to access with the 
token, I assumed it would know what to put in this field.

> request with a symmetric key" as this is positive and where enforcement is
Ok, fixed.

> should be the same as for Figure 2.  That is assuming it is really CoAP and
Right, fixed.

> one. Could be something else as I don't have RFC 6749 w/ me.

True, this method is specified on section 2.3.1. of RFC 6749, so we 
thought we'd offer an example.

I don't think this is a good feature security-wise.

> from DTLS profile as this is really the first thing that happens.

Sounds reasonable, fixed in the discovery branch. Merge pending approval 
of my co-authors.

> rather than having it be configured into the AS?

We had that in a previous version and decided it was over-engineered. 
The client needs to be registered at the AS anyways, and could then also 
specify preferred profiles.

> saying MUST be CBOR while earlier it was only a recommendation,

Right, I'm adding an issue about this. We're also inconsistent in 
section 5.5.1. although not in RFC 2119 language.

> 21. Section 5.5.2 - Post figure 5 it says examples - but only one example

Fixed.

> I don't really want to support both.

I'll add an issue, I'm not opposed to that change, but I'd like to have 
consensus.

(side note: Congratulations, you just contributed to creating the 100th 
issue on this draft on github)

> supported. Optional if RS only does one.

Wouldn't the RS be able to determine the profile from the message it 
receives from the Client?

Say the AS tells the client to use DTLS, the RS would notice receiving a 
DTLS handshake. Are there any scenarios where two profiles could be 
confused?

> introspection) that is for dealing with the RS keysWe need to specify that the .  That makes it cleaner

Indeed I argued the same way, but I was voted down by my co-authors. 
I'll raise the issue again with your newfound support.

> needs to have some context because it looks the same as for a RS key.

Your point makes sense, but this whole section is going to be rewritten 
when we transfer cnf to draft-jones-ace-cwt-proof-of-possession. I'll 
take that into account when we do the rewrite.

> wrapping is missing on unprotected.

Correct, this figure is also bound to disappear, but I'll see that 
draft-jones gets the right example instead.

> Look @ section 3.3. RFC 6749 about scopes

That look more like a note to self to me, right?

> and internal knowledge - does not need to be documented except for response

You mean if a client would do introspection on an access token it 
received? Depending on the AS its not sure it would be authorized to do 
so (mine has policies for determining who gets to introspect). I believe 
this can be left to the implementers. I might be convinced that it needs 
a security consideration though (if you insist).We need to specify that the

> 28. Figure 14 needs to be updated

Done.

> 
> 29. Section 5.6.2 - Need to add rs_UZWab0RScnf - if more than one key need to tell
> the RS what key to use.

I agree. Issue created

> going to be able to return a random symmetric key.  Not needed otherwise.

It could also be used to inform the client about the RS's public key for 
authentication.

> established at the same time that the token is established.

Sounds reasonable. Fixed.

> 32. Section 5.6.4 - establish MTI algorithms here?

For encrypting the client token? Is that really necessary? The AS should 
know what algorithms the client supports.

> w/ multiple keys so it knows which to use. usage would be optional.

Agree. I'm extending the existing issue from 31.

> 34. Section 5.7 - last paragraph - should be JOSE and COSE not JSON and
Right, fixed.

> text it is not clear when the MAY would be triggered.

It's just a suggestion to the implementer, not really necessary but 
useful in some scenarios (e.g. if the client later wants to delete or 
overwrite the token this could be good to have).

> different error codes being returned in these situations.  May only want to

This is a difficult one. One the one hand you are right some information 
is leaked, but on the other hand, withholding that information makes it 
very hard for the client to fix erroneous access tokens.

> not made? 

If the RS is not configured to do so. E.g. if it has intermittent 
connectivity and the token is self contained.

> If the introspection request is done async how is the client

It's not designed to be done async. We should mention that. Issue created.

> the assumption is that profiles are whole.

I'm assuming that /authz-info can be unprotected. It could use DTLS 
without client authentication, but it cannot use OSCOAP with a client 
that is not previously known, since the token sent to /authz-info 
contains necessary information to generate the OSCOAP context.

> to the RS - AS may issue lots of tokens but if RS gets none then no

I think that bullet is the best we can do in the described usecase. The 
last bullet refers to a RS that has not clock at all and no connectivity 
to the AS. If the RS had connectivity it could do introspection.

If you have a better suggestion I'm open for suggestions.

> might also cause this sequence of messages

Do you think it would be useful to give these additional examples?

> 41. Section 6 - personal preference - remove the first sentence it is not

I agree, I've heard this more than once now.

> is preferred to MAC in most cases because of confidentiality as well.

Agree, fixed.

> thinking of asymmetric keys as well.

Fixed.

> asymmetric key is a problem - change it form shared secret to symmetric key.

Yes that sounds like something that was meant to apply for symmetric 
keys, which is NOT RECOMMENDED anyways some paragraphs above. Fixed.

> access to the resources as long as it is still valid.

I reworded the whole paragraph.

> session key for DTLS is established later, it is just a POP value (or key if

That issue relates to your point made in 9. I'll update the issue to 
consider this as well. I also replaced "session key" with 
"proof-of-possession key".

> keys depending how short the keys are.

I've tried to rephrase that paragraph to clarify it. Please check again.

> 47.  Section 6 - the next to last paragraph is a repeat - but probably

Fixed: I deleted the other paragraph.

> does not make a great deal of sense to me.

If you issue an access token bound to a symmetric pop-key that is valid 
for a group of RS, then any of these RS that receives the token can use 
to towards the other RS, impersonating the client.

I'll try to clarify the text in the draft (I also noted that the context 
to using a symmetric pop key got lost in the second sentence of that 
paragraph).

> control, this does not make sense to me.

In other grants, you have the authorization performed by the resource 
owner and the AS just validates the grant provided by the client. These 
grants can be used to hide the client's identity towards the AS.

I'll reformulate to clarify.

> For now I skipped IANA considerations and the appendixes.
Noted, those are probably bound to change a bit when we extract cnf.

> on github or if you prefer doing it.

I'm creating issues as I go, thanks for the offer.

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Mon, 7 Aug 2017 10:57:16 -0700

Responses in line, I have trimmed things which did not seem to need a
response.

Jim

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Monday, August 7, 2017 6:04 AM
> To: [email-masked]
> Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
> 
> > /.well-defined or not.  If they are then this needs to be noted and
> > there needs to be an IANA action if this has not already been done for
> OAuth.
> 
that
> this is something that would need to apply to OAuth as well.

I would agree that it makes sense to have OAuth deal with this issue as
well. 

It is probably less of an issue for /token if the client always gets this
from the RS and does not try to find it on its own.  The /authz-info point
is probably more significant.

Be sure to catch Olaf's comment on using a resource type as another way to
identify this.

> pop-key with said friend.

If I can fool C into thinking that my key is it's key, when the process is
finished the RS has an access token with the privileges of C, but with my
key.  I now can do anything that C would be able to do.  This would only
need to be done the first time the AC sees the key as it could keep track
that the key is associated with C for later requests.

> > want the current restriction that is being imposed on the scope
parameter
> in

A sentence that says that other methods of doing scopes is permitted would
satisfy my desires.

> You mean section 5 right?

Yes - this should have been section 5.

> else) as data format instead of CBOR.

If one were to be using JSON why would one not just use OAuth rather than
ACE?  If JSON is really going to be a legal option then I think it should be
fully fleshed out as part of this document.  Otherwise you might end up with
MTI problems.

> therefore it wouldn't need an ACE profiling, it could just be used as

You might think about moving the out-of-scope statement closer to the front
of the section so that is clearer.

> contextually appropriate places) in the main body of the spec.

You should have an early pointer to this so people know it is there and read
it then.

> the security considerations seem the right place to me for this.

I think that this should be part of the "main" text and goes to what St
Johns (I think it was him) brought up at the mic where it needs to be clear
someplace what the security assumptions/requirements are for each leg of the
conversation are that a profile needs to be sure to include.  And how using
different profiles might interact.

> separate draft. What does the group think?

I am referring to more than just the "nonce" value, although that is one
such value.  If you look at draft-cuellar-ace-pat-priv-enhanced-authz-tokens
in section 4.3, they have a whole set of parameters that are to be
transferred from the RS to the AS via C.  One some parameter would be the RS
having an idea of what the scope is that needs to be authorized based on the
request (thus allowing C not to have to understand scopes). 

> Could you be more specific about the "4 corner model"? I'm not familiar

It is an old term that I learned early on in my career which actually refers
to how your credit card is setup to get authorized.  You have four parties
one on each corner - Card holder, Card Bank, Merchant bank, Merchant.  Looks
just the security model from actors if you omit the owners.  This is
basically short hand for saying that CAS != AS.

> token, I assumed it would know what to put in this field.

So the answer is [2001::1]?

> I don't think this is a good feature security-wise.

That is for Client Password authorization - This is not going to be
something that you ever want to support in this profile.  There are other
better ways to deal with a shared secret and you don't want the potential
multiple round trips to do http authorization here.

> specify preferred profiles.

The AS also needs to know the network layout as well since C and RS may not
be able to use DTLS if they need to go through a proxy.

> DTLS handshake. Are there any scenarios where two profiles could be

Say the AS tells the client to use DTLS.  C then posts the token to
/authz-info.  Is this DTLS, OSCOAP, PAT, IPSec?

> That look more like a note to self to me, right?

Yes this was a note to self.

> a security consideration though (if you insist).We need to specify that
the

The first sentence of section 5.6 says that the client can query for the
introspection point.  I this is not what is desired then just remove that.

If it is desired, then I assume that some of the response elements would be
different.  If so then that needs to be documented.

> It could also be used to inform the client about the RS's public key for

True - either way I support having this.

> know what algorithms the client supports.

That is fine, until I have an AS that only does CCM and a client which only
does ChaCha-Poly1305.

> overwrite the token this could be good to have).

This is not at all clear or documented.

> very hard for the client to fix erroneous access tokens.

Should probably have a security consideration on this.

> connectivity and the token is self contained.

That was assumed.  The question is what are you doing in the 3rd to last
paragraph where you say the RS MAY introspect.  But does not say anything
about when or why.  I would take it as a given that if the token is
self-contained then it would never been done.  

> Do you think it would be useful to give these additional examples?

I am not really happy with how the paragraph is designed.  But no they
probably do not help.

> to using a symmetric pop key got lost in the second sentence of that

The problem with that statement is that the client is using an asymmetric
key pair here.

>From previous comments, looks like I should think about reading the
appendixes though.

By the way, a quick republish to update email addresses might be desirable
so that the author list does not send back so many bounces.

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 Aug 2017 17:02:07 +0200

> that the key is associated with C for later requests.

Ok, we could fix this by requiring that the key used by C when 
authenticating to AS is the one that is used as PoP key.

> A sentence that says that other methods of doing scopes is permitted would

I would favor a solution that says that scopes are strings by default, 
unless the AS and the RS specifically agree on something else. That way 
an implementation does not have to deal with binary data by default.

>>>
>>> 7.  In section 5 - Under "ACE Profiles" - RECOMMENDS seems to be an odd

> fully fleshed out as part of this document.  Otherwise you might end up with

Sounds reasonable to me, I'll propose that change

> of the section so that is clearer.

Ok I will try to clarify this.

Done.

> different profiles might interact.

Note that in discussion with Hannes today, he came up with the very 
reasonable scenario of  C<->AS with DTLS/CoAP and C<->RS with TLS/MQTT.

> request (thus allowing C not to have to understand scopes).

I would be in favor of moving these things into a separate document. The 
current draft is already quite long, and it doesn't feel like essential 
functionality to me.

> basically short hand for saying that CAS != AS.

The the 4 corner model would use the CAS as intermediary between C and 
AS. This means on the one hand that the CAS would need some token 
request parameters that indicate for which client it is requesting a 
token from the AS. On the other hand the client could query the CAS just 
like it queries the AS /token endpoint, so I don't see an immediate need 
for measures on that side of the communication.

Since I haven't seen strong industry demands for supporting the CAS so 
far, I'd suggest to move such specifications into a separate document.

> So the answer is [2001::1]?

For example, or just "aud" : "myTemperatureSensors", where the RS and 
the AS have a mapping of which RS correspond to "myTemperateSensors".

> multiple round trips to do http authorization here.

Indeed. I will modify that example to use some other method.

> be able to use DTLS if they need to go through a proxy.

These kind of things should be covered implicitly since RS and C are 
registered at the AS together with a list fo the profiles they support. 
I would expect that if either C or RS are deployed on a network that 
requires proxies, DTLS will simply not be a supported profile.

> /authz-info.  Is this DTLS, OSCOAP, PAT, IPSec?

Why would the RS need to know at that point? When a token is posted to 
/authz-info the only thing the RS needs to do is to make sure that it is 
valid and store it for future use. That does not require knowledge of 
the profile the client is going to use when requesting a resource later.

> different.  If so then that needs to be documented.

Why would the response elements be different? The response is the claims 
associated to the token subject to introspection. They are the same 
regardless whether the client or the RS asks. It's another question 
whether they are meaningful to the client.

> That is fine, until I have an AS that only does CCM and a client which only

I see, but that would be noticed when the client is registered at the AS 
(btw. see Appendix D for a list of assumptions what the AS knows about C 
and RS).

> This is not at all clear or documented.

Ok I'll try to clarify.

> Should probably have a security consideration on this.

Issue created.

> self-contained then it would never been done.

Why not? Even a self-contained token might be revoked before it expires, 
which would only work with introspection.

> I am not really happy with how the paragraph is designed.  But no they

Ok I'll try to rephrase then.

> The problem with that statement is that the client is using an asymmetric

Right, as I said the context got lost in some rewriting. I'll try to 
rephrase to make it clearer that only symmetric keys are affected (since 
in the symmetric case the RS has the symmetric key and thus can perform 
the PoP itself.

> so that the author list does not send back so many bounces.

I'll do that.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51