[Openid-specs-ab] FW: HEART Implementer's Drafts Approved

[Justin Richer]

Thomas,

I agree with your assessment: it's not a very good idea to treat the 
expiration of the ID token as a session management bound with no further 
mechanisms.

  -- Justin

On 2/22/2016 5:45 AM, Thomas Broyer wrote:
> Reading this, I can't help but think back about a question I asked 
> here that (AFAICT) never had an answer, but has now contradictory spec 
> texts that reinforce the confusion.
>
> OpenID Connect Session Management 1.0 – draft 26 says:
> > An ID Token typically comes with an expiration date. The RP MAY rely 
> on it to expire the RP session.
> > However, it is entirely possible that the End-User might have logged 
> out of the OP before the expiration
> > date. Therefore, it is highly desirable to be able to find out the 
> login status of the End-User at the OP.
> — Source: 
> https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification
>
> Health Relationship Trust Profile for OpenID Connect 1.0 says:
> > The ID Token MUST expire and SHOULD have an active lifetime no 
> longer than five minutes.
> – Source: 
> https://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2
>
> I believe I had seen that last recommendation elsewhere in OpenID 
> Connect specs (probably earlier drafts of the Core spec, back when it 
> was split in several documents), and that was what motivated my 
> question months ago (actually more like two years ago I believe) 
> related to the Session Management draft.
>
> My interpretation is that Session Management actually is wrong 
> recommending using the ID Token expiration as a baseline for session 
> expiration. Can someone please confirm?
> (if you prefer I instead create an issue at BitBucket, I can do that too)
>
> On Tue, Feb 16, 2016 at 2:40 AM Mike Jones 
> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
>     FYI
>
>     *From:* Mike Jones
>     *Sent:* Monday, February 15, 2016 5:39 PM
>     *To:* openid-specs-heart at lists.openid.net
>     <mailto:openid-specs-heart at lists.openid.net>
>     *Subject:* HEART Implementer’s Drafts Approved
>
>     The following notice was posted at
>     http://openid.net/2016/02/15/heart-implementers-drafts-approved/:
>
>     *HEART Implementer’s Drafts Approved*
>
>     The OpenID Foundation members have approved of the following
>     specifications as OpenID Implementer’s Drafts:
>
>     ·Health Relationship Trust Profile for OAuth 2.0
>
>     ·Health Relationship Trust Profile for OpenID Connect 1.0
>
>     ·Health Relationship Trust Profile for User Managed Access 1.0
>
>     An Implementer’s Draft is a stable version of a specification
>     providing intellectual property protections to implementers of the
>     specification.
>
>     The specifications are available at:
>
>     ·http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html
>
>     ·http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html
>
>     ·http://openid.net/specs/openid-heart-uma-1_0-ID1.html
>
>     The voting results were:
>
>     ·Approve – 34 votes
>
>     ·Object – 1 vote
>
>     ·Abstain – 11 votes
>
>     Total votes: 46 (out of 204 members = 23% > 20% quorum requirement)
>
>     — Michael B. Jones – OpenID Foundation Board Secretary
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160222/e0418c30/attachment.html>