OpenID Connect: Under the Hood

From IIW

Conference: IIW10 May 17-19, 2009 this is the complete Complete Set of Notes

Monday Session 3 space I


Signatures


  • ID Format

  • Delegation

  • OAuth Enhancements
   
    • immediate mode
   
    • userid param
   
    • display
  • scoping/audience compartmentalizations.

  • get user/??  API
-    (Doscovery)

  • Session lifecycle (cookies, etc.)

  • which OAuth 2.0 flows?

  • Browser discovery

  • Client discovery

  • extension model



Discussion points outside the above"

 How do I trust a site to assert form domains other than the main domain?  This is a significant discovery question.  This is verification, not discovery.   The flexibility of allowign an ID provider to assert for other domains is good, but the cost is that we have a harder discovery problem for all the sub or delegated domains.  This is also the white label problem for white label products.



Are we willing to restrict this?  Domains can only assert IDs in their own domain? 


One of the nice things baout the URL format of an OpenID is that it's easy to get back to the sourcing domain.  (David R.'s rant)  This seqgues into "why isn't user@domain sufficient, since the URI is just a transform of that?



------


"So, what does OpenID Connect do?"



You need to end up with a domain and a scheme, form that you go do LRDD discovery.   It gets back an OpenID token endpoint.



Delegation today is really aliasing, but this is "utterly useless" and "everyone gets it wrong".  As yet there hasn't been a lot of demand for this.






"Is the stability of names a problem? What happens when a domain goes away?" 



In the end the user needs to have multiple identities.  The "rel" links allow you to connect between them.  This needs to solve this, if one ID goes away you need to have a backup.



------
 Scoping....



User impersonation is a problem.  Scoping is needed so that a token granted to one party is not valid when used by soemone else.  The way it's solved here is that the 3rd party is stored as part of the scope. 



Does this support delegation?



What is supported  is going from your preferred ID to an ID that is asserted by the provider.






http://openidconnect.com has the current stuff. 
http://specs.openid.net has specs.

We have several classes of data:

 Uncontrollably exposed
   

  • Here we are throwing up our hands.  


Controllably exposed (for example by contract)
retrivable/withdrawable/erasable
   

  • Vanish is an example of a product here.



Is there another level here which is "Assured destruction"
    Disappearing Ink was a company in this space.



Data security becomes very much like a DRM system.



How do we apply this to Identity Information?



Another taxonomy:


  • Permanent data that we might want to withdraw.

  • Transient data that should have a limited life.



What controls do we have here?


  • Contract

  • Legal obligation



Can a trusted 3rd party help ensure te dustruction/privacy/revocation.



A key question, "what is the incentive for people to be good actors?"  or what's the penalty for not obeying privacy restrictions?



Another interestion question of information lifecycle:  when the data changes context you may really care.  It can be a big problem.  The privacy boundaries here are significant and the user needs to be in control.


Retrieved from "https://iiw.idcommons.net/index.php?title=OpenID_Connect:_Under_the_Hood&oldid=3604"