Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

[William Denniss <[e-mail]>]

Seems to me that if you're using iss/aud in Connect you should be careful
in using that same iss/aud combination outside Connect.

What if the guidance is not an outright prohibition, but a security
consideration to "be careful", with a suggested mitigation (being not to
re-use iss/aud tuples outside of Connect).

On Wed, Mar 1, 2017 at 12:09 PM, Mike Jones <[e-mail]>
wrote:

> I suspect that lots of non-OpenID-Connect OAuth 2.0 use cases also use the
> Client ID as the Audience value, especially since some OAuth clients don’t
> even have a URL associated with them.  Trying to prohibit the use of Client
> IDs as audiences will likely break things that we’re not even aware of.
>
>
>
> *From:* William Denniss [mailto:[e-mail]]
> *Sent:* Wednesday, March 1, 2017 12:06 PM
> *To:* Mike Jones <[e-mail]>
> *Cc:* Phil Hunt <[e-mail]>; ID Events Mailing List <
> [e-mail]>
>
> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in SET
> tokens
>
>
>
>
>
>
>
> On Wed, Mar 1, 2017 at 11:33 AM, Mike Jones <[e-mail]>
> wrote:
>
> Hi William,
>
>
>
> I appreciate you supporting using the standard definitions for “sub” and
> “iss”.  That said, I then find it confusing that you are suggesting that
> people be prohibited from using “aud” (audience) in the standard way.
>
>
>
> I’ll also note that if you prohibit using “aud” in the standard way,
> you’ll both break the usage in the OpenID Connect Logout Token
> http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken
> and in SETs https://tools.ietf.org/html/draft-ietf-secevent-token-00#
> section-2.1.  Please let’s not go there.
>
>
>
> I'm not suggesting an outright prohibition on "aud" being the client id, I
> realise my words were a little inarticulate.
>
>
>
> I see "aud as client id" as the domain of OpenID Connect (since that's
> where that usage of "aud" was defined). I completely understand why Connect
> Logout uses "aud as client id" and would expect other Connect specs to do
> so – but these specs understand Connect and can be written to avoid
> problems (as Logout does).
>
>
>
> My guidence would be that a *non*-Connect specs should use "aud as URI"
> (basically just !"aud as client id") to avoid accidently causing problems
> for Connect.
>
>
>
> When constrained that way, what do you think of the guidance?
>
>
>
> Implementations using both ID Tokens and SETs can already unambiguously
> distinguish between them by the presence of the “events” claim.  ID Tokens
> don’t use “events” whereas SETs do.  The fact that “nonce” is present in an
> ID Token but not SETs provides an extra means of rejecting SETs in ID Token
> contexts.  I don’t see there as being any actual practical problem to solve
> that rises to the level of causing us to do unnatural things to claims
> usage.
>
>
>
> +1
>
>
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* William Denniss [mailto:[e-mail]]
> *Sent:* Wednesday, March 1, 2017 11:21 AM
> *To:* Phil Hunt <[e-mail]>; Mike Jones <
> [e-mail]>
> *Cc:* ID Events Mailing List <[e-mail]>
> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in SET
> tokens
>
>
>
> My vote is for #1.  Iss and sub should take the definition from JWT.
>
>
>
> I fear that following the "access token confusion mitigation" logic here
> basically means that "sub" can only be used by authorization &
> authentication protocols which is wasn't the intent of the spec
> <https://tools.ietf.org/html/rfc7519#section-4.1>.  What is the point of
> these standard claims if we can't use them? Will every new spec
> prohibit/rename a different standard claim? This isn't scalable, and is
> super confusing.
>
>
>
> Back-channel logout "breaks" the id token mix-up by prohibiting
> <https://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken>
> 'nonce'.  When I spoke to Breno about the overall risk, he suggested not
> reusing "aud" in other systems (like RISC, SCIM, etc). OpenID Connect
> defines "aud" to be the client-id. If *every other spec* uses a URI-based
> approach for aud and recommends not re-using audience URIs between systems,
> then we can avoid conflicts and usage mix-ups.
>
>
>
> If I recall correctly in Buenos Aires, the preference of +Mike was to keep
> "sub" for compatibility with Backchannel Logout.
>
>
>
> I hope we can avoid going around in circles on this security topic, how
> about I propose some new text for https://tools.ietf.org/
> html/draft-ietf-secevent-token-00#section-3.5 capturing the "aud"
> suggestion?  We can confine all such "access token confusion" matters to
> that section, and just build the best SET spec we can without needing to
> bake in hacks.
>
>
>
> Mandating that different systems use non-overlapping "aud" sets doesn't
> not sound like a hack to me at all (unlike renaming "sub"), since the
> audience of a SET stream is surely different to that of an AuthZ/N token.
>
>
>
>
>
>
>
> On Wed, Mar 1, 2017 at 10:27 AM, Phil Hunt <[e-mail]> wrote:
>
> In the comments on idtoken-07, Yaron raised concerns around the confusion
> of “iss” of the subject of the event vs. issuer of the event.  The current
> text says that if there is a need to distinguish between “iss” of the “sub”
> vs. “iss” of the event, then the event should place the “iss” of the
> subject in the event payload area.
>
>
>
> I agree this does seem awkward.
>
>
>
> I have been thinking a related concern, that a SET could be confused as an
> access token if it has a “sub” value.  If we stop using “sub” then we’re
> potentially causing web access management systems to reject SETs as invalid
> access tokens — this is theoretically a GOOD THING.
>
>
>
> PLEASE INDICATE 1 or 2, or provide additional discussion.
>
>
>
> Two options:
>
>
>
> 1. Leave as is.
>
>
>
> 2.  Create a new attribute object, “esub” (event subject) which is a JSON
> object that contains the attributes needed to identify the subject.  For
> example:
>
>
>
> We currently have:
>
>    {
>
>      "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>
>
>
>      "sub": "248289761001",
>
>      "iat": 1458496025,
>
>      "iss": "https://my.examplemed.com",
>
>      "aud": [
>
>        "https://rp.example.com"
>
>      ],
>
>      "events": {
>
>        "https://openid.net/heart/specs/consent.html":{
>
>          "iss":"https://connect.example.com",
>
>          "consentUri":[
>
>            "https://terms.examplemed.com/labdisclosure.html#Agree"
>
>          ]
>
>        }
>
>      }
>
>    }
>
>
>
> Could be represented as:
>
>    {
>
>      "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>
>
>
>      “esub": {
>
>        “sub”:"248289761001”,
>
>        "iss":"https://connect.example.com”
>
>      }
>
>      "iat": 1458496025,
>
>      "iss": "https://my.examplemed.com",
>
>      "aud": [
>
>        "https://rp.example.com"
>
>      ],
>
>      "events": {
>
>        "https://openid.net/heart/specs/consent.html":{
>
>          "consentUri":[
>
>            "https://terms.examplemed.com/labdisclosure.html#Agree"
>
>          ]
>
>        }
>
>      }
>
>    }
>
>
>
> Comments:
>
> * “sub” remains untouched in the sense that it retains the meaning used in
> traditional access tokens.
>
> * “esub” contains the full information to address the subject.  No need to
> look around for a second “iss” (which may or may not be there)
>
>
>
> To do this would require defining “esub” and sub-attributes like, “iss”,
> “sub” (which follow current defs), and probably “uri” for those entities
> that are referenceable as a URI.  Examples of URI subjects:
>
> *  in implicit federation (from RISC):   “uri”:”mailto:[e-mail]
> <[e-mail]>”
>
> *  in SCIM where resources have URIs:  “uri”:”https://scim.example.
> com/Users/44f6142df96bd6ab61e7521d9"
>
>
>
> One catch. Profiling specs would not be able to define new ways of
> addressing subjects with esub.
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
>
> @independentid
>
> www.independentid.com
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>
>
>