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

We use it both ways. I would not use uri/url as a way to distinguish types. 

I think aud for logout is particularly important as it will often be identifying an SSO domain as well as a specific client id. 

Phil

> On Mar 1, 2017, at 12:12 PM, William Denniss <wdenniss@google.com> wrote:
> 
> 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 <Michael.Jones@microsoft.com> 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:wdenniss@google.com] 
>> Sent: Wednesday, March 1, 2017 12:06 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Phil Hunt <phil.hunt@oracle.com>; ID Events Mailing List <id-event@ietf.org>
>> 
>> 
>> 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 <Michael.Jones@microsoft.com> 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:wdenniss@google.com] 
>> Sent: Wednesday, March 1, 2017 11:21 AM
>> To: Phil Hunt <phil.hunt@oracle.com>; Mike Jones <Michael.Jones@microsoft.com>
>> Cc: ID Events Mailing List <id-event@ietf.org>
>> 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.  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 '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 <phil.hunt@oracle.com> 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:phil.hunt@yahoo.com”
>> 
>> *  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
>> 
>> phil.hunt@oracle.com
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>> 
>>  
>> 
>>  
>> 
> 