Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EEF1AC423 for ; Mon, 15 Feb 2016 15:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMbr0ExbjzIE for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791871B2A24 for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id y89so121879750qge.2 for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IlKJnlh5VE1L0CPyYCb3fK5SrEJnnQ468BooldoT58c=; b=ibgrjfYhlcAuRq1EMdlg3at7aP77+qjExt43IL8K+ImdaNRMYUssHI07jX0qCxHBc0 10oGbkGoeX7PIV0Ax7iIo5AQAiIuYIzjZkS6zp76lmgJGaflZ7JkNyyGWoBUnJFqQj7B wxLFtXURmjXD9+kjS5UfELILki987MfJNCZYaWJSpwpi8wPmWd47s03iGLqZJzyFjEVO ykcMOegNcj23+O/fpd18nUupWq8Qqu4j61njGdDPmYbs9IgBpgf1B+r+w8Q6UGf2JQtC EXVhM/LFTVpDy7hxaV5U43MgdqT5jZ0lpZcvDbR6P24bg8NdiZMxaiFroLpJBwibrmRN e+Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IlKJnlh5VE1L0CPyYCb3fK5SrEJnnQ468BooldoT58c=; b=Rl0uCVattJVsxiYNv/3+rGOzxzu/zdj1LnpbRRkrv90tOOYFzSf2XbB3FJGOgKw+S9 WCQ3f0Ktf8yO8a0AXC9kcCwFsUP2Fmmq/3U6SK0ZktlvQ/6pODi9PFzf3z7oQU/JVstP 06hpT+OyTlIUp1a7hMHnDoFmpusSiheze7aDnSAGAAqQ4kzE3LeLFX4x7mz2WfYhpPv0 VaDd0SJHVJJm+ICzUAZts2xfQBviimHg9XaSzav5EkM1sAGtzZfkV8QqOC+SE5YO6aks dn7XxoTUQFd2oIQtFvhj+GYie1bBdYiQjciZtNygUZOOEpF+sBY+23dI6z0Wmyoa5JW1 PPrg== X-Gm-Message-State: AG10YOQ9IhnSFyCTYpGI+uLXBRpEM1tDIJSOo5uAVSKLkTX6Fwnqh+VwhARWVAFZ04JBAA== X-Received: by 10.140.216.212 with SMTP id m203mr25192035qhb.37.1455580242508; Mon, 15 Feb 2016 15:50:42 -0800 (PST) Received: from [192.168.8.100] ([181.202.151.161]) by smtp.gmail.com with ESMTPSA id e34sm12044614qga.4.2016.02.15.15.50.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Feb 2016 15:50:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> Date: Mon, 15 Feb 2016 20:50:38 -0300 Message-Id: References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> To: Jim Manico X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:50:50 -0000 --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39 Content-Type: multipart/alternative; boundary="Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0" --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The question is what counts as re-authentication. =20 It may be that the environment is changing. Re-prompting for a password = in many cased just tells you the user has a form filler. It may be better to use risk based factors such as prompting for a pin, = or using a local passive biometric, eg has the phone got screen lock and = is it in proximity to the persons smart watch etc. =20 What google seems to be doing is using the amr to say how they did the = last authentication and leave it up to the client to decide if it is = good enough. Simple always ask for a password may no longer provide the security that = most people think it is giving. Looking at what enterprise customers are asking for, they are becoming = more concerned with checking the MDM posture of the device at = authentication. This is a larger conversation about authentication context and methods. The establishment of the amr registry will provide a place to document a = part of this, however authentication context (there is already a = registry) and amr values themselves are probably out of scope for this = WG. John B. > On Feb 15, 2016, at 8:22 PM, Jim Manico wrote: >=20 > Polite comment, Google in general is pretty "open" about session = management in general - long idle timeout and no apparent absolute = timeout. For a bank or other organization that produces high risk = software, this is not standard practice. Re-authentication is a critical = security boundary, not prompting the user for re-authentication = credentials is unacceptable in those environments. >=20 > I may be jumping in out of context, but fair? >=20 > -- > Jim Manico > @Manicode > +1 (808) 652-3805 >=20 > On Feb 15, 2016, at 3:36 PM, William Denniss > wrote: >=20 >> We return 'amr' claims in ID Tokens if "max_age" is requested (per = OpenID Connect), e.g.: >>=20 >> = https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdev= elopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D4074= 08718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt= =3Dforce&access_type=3Doffline&max_age=3D1 = >>=20 >> The reason we do this is to be explicit about how we are processing = the "max_age" reauth request, specifically that we don't always prompt = the user to reauthenticate directly (but do perform in-session risk = analysis). >>=20 >> I can see us potentially using the more generic amr values like = "user", and "mfa" but we will probably avoid very specific ones like = "sms" or "otp" to avoid brittle relationships with RPs. That said, I = don't object to those being in the registry, perhaps there is value in = some tightly coupled enterprise configurations. >>=20 >>=20 >> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt = > wrote: >> Hi Denniss, >>=20 >> out of curiosity: Does Google use amr values?=20 >>=20 >> best regards, >> Torsten. >>=20 >>=20 >> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>=20 >>>=20 >>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones = > = wrote: >>> It's an acceptable fallback option if the working group decides it = doesn't want to register the values that are already in production use = at the time we establish the registry. But add William points out, = Google is already using some of these values. Microsoft is using some of = them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time. >>>=20 >>> That would be my preference. >>>=20 >>> +1, it is also my preference to register the current values. >>>=20 >>> I don't see any harm in the spec that establishes the registry also = seeding it with all known values in use at the time of drafting, = regardless of the group that originally specified them. Makes the = original spec more useful, and avoids the need to submit each value for = consideration separately =E2=80=93 they can be all be reviewed at the = same time.=20 >>>=20 >>>=20 >>> From: Justin Richer >>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>> To: Phil Hunt >>>=20 >>> Cc: >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>>=20 >>> Can we just do that, then? Seems to be the easiest way to address = various needs and concerns.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote: >>>>=20 >>>> Yes >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 13, 2016, at 07:59, " = torsten@lodderstedt.net = " > wrote: >>>>=20 >>>>> So basically, the RFC could also just establish the new registry = and oidf could feel in the values? >>>>>=20 >>>>> (just trying to understand) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Originalnachricht -------- >>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> Von: Mike Jones < = Michael.Jones@microsoft.com = > >>>>> An: torsten@lodderstedt.net ,John = Bradley < ve7jtb@ve7jtb.com = > >>>>> Cc: oauth@ietf.org >>>>>=20 >>>>> The context that most people on this thread probably don=E2=80=99t = have is that an IANA registry can only be established by an RFC. = Non-RFC specifications, such as OpenID specifications, can *register* = values in a registry, but they cannot *establish* a registry. The = OpenID Foundation inquired about this with the IETF before OpenID = Connect was finalized and learned that its specifications could not = establish IANA registries. Otherwise, they would have. >>>>>=20 >>>>> =20 >>>>> Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications. This = specification is one example of doing this. >>>>>=20 >>>>> =20 >>>>> -- Mike >>>>>=20 >>>>> =C2=A0 <> >>>>> From: OAuth [ = mailto:oauth-bounces@ietf.org = ] On Behalf Of = torsten@lodderstedt.net = >>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>> To: John Bradley < ve7jtb@ve7jtb.com = > >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>>=20 >>>>> =20 >>>>> We clearly have this problem between oauth and oidc. Just take a = look at the discovery thread. >>>>>=20 >>>>> According to you argument I see two options: >>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg = just publishes the registry entries. In this case, the spec should = clearly explain this. >>>>> (2) amr is of any use in oauth (although it has been invented in = oidc) - than define it and motivate it's use in oauth in this spec. >>>>>=20 >>>>> Right now, I think it creates the impression oauth is for = authentication. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Originalnachricht -------- >>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> Von: John Bradley < ve7jtb@ve7jtb.com = > >>>>> An: torsten@lodderstedt.net >>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org = >>>>>=20 >>>>> This is not a issue between oauth and OIDC. >>>>>=20 >>>>> =20 >>>>> This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 >>>>>=20 >>>>> We can=E2=80=99t ask them to all move the parts of there specs = that use JWT to OAuth. >>>>>=20 >>>>> =20 >>>>> Perhaps JWT should have been part of JOSE, but that is water under = the bridge. =20 >>>>>=20 >>>>> =20 >>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and = we will need to deal with registering claims. =20 >>>>>=20 >>>>> =20 >>>>> I guess that we can tell people that they need to publish the = specs defining the claims someplace else, and just do the registry part. >>>>>=20 >>>>> However doing that will probably not improve interoperability and = understanding. >>>>>=20 >>>>> =20 >>>>> This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. >>>>>=20 >>>>> =20 >>>>> John B. >>>>>=20 >>>>> On Feb 13, 2016, at 9:18 AM, = torsten@lodderstedt.net = wrote: >>>>>=20 >>>>> =20 >>>>> I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >>>>>=20 >>>>> What worries me is the back and forth between oauth and oidc. The = amr claim is defined in oidc (which sits on top of oauth) but the oauth = wg specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >>>>>=20 >>>>> As a WG we need to find a clear delineation between both = protocols, otherwise noone will really understand the difference and = when to use what. We create confusion! >>>>>=20 >>>>> For this particular draft this means to either move amr to oauth = or the registry to oidc. >>>>>=20 >>>>> best regards,=20 >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Urspr=C3=BCngliche Nachricht -------- >>>>> Von: Roland Hedberg < = roland.hedberg@umu.se = > >>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>> An: oauth@ietf.org >>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>>=20 >>>>> +1 >>>>>=20 >>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley < = ve7jtb@ve7jtb.com >: >>>>> >=20 >>>>> > +1 to adopt this draft. >>>>> >=20 >>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones < = Michael.Jones@microsoft.com = > wrote: >>>>> >>=20 >>>>> >> Draft -05 incorporates the feedback described below - deleting = the request parameter, noting that this spec isn't an encouragement to = use OAuth 2.0 for authentication without employing appropriate = extensions, and no longer requiring a specification for IANA = registration. I believe that it=E2=80=99s now ready for working group = adoption. >>>>> >>=20 >>>>> >> -- = Mike >>>>> >>=20 >>>>> >> -----Original Message----- >>>>> >> From: OAuth [ = mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>> >> To: oauth@ietf.org = >>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> >>=20 >>>>> >> Hi all, >>>>> >>=20 >>>>> >> On January 19th I posted a call for adoption of the = Authentication Method Reference Values specification, see = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15402.html = >>>>> >>=20 >>>>> >> What surprised us is that this work is conceptually very = simple: we define new claims and create a registry with new values. Not = a big deal but that's not what the feedback from the Yokohama IETF = meeting and the subsequent call for adoption on the list shows. The = feedback lead to mixed feelings and it is a bit difficult for Derek and = myself to judge consensus. >>>>> >>=20 >>>>> >> Let me tell you what we see from the comments on the list. >>>>> >>=20 >>>>> >> In his review at >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. >>>>> >>=20 >>>>> >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15426.html = >>>>> >>=20 >>>>> >> Justin is certainly the reviewer with the strongest opinion. = Here is one of his posts: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15457.html = >>>>> >>=20 >>>>> >> Among all concerns Justin expressed the following one is = actually actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >>>>> >>=20 >>>>> >> John agrees with Justin in >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >>>>> >> list: = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15441.html = >>>>> >> Most of them require more than just editing work. For example, = methods listed are really not useful, >>>>> >>=20 >>>>> >> Phil agrees with the document adoption but has some remarks = about the registry although he does not propose specific text. His = review is here: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15462.html = >>>>> >>=20 >>>>> >> With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with = various drafts. Not standardizing JWT in the IETF would have lead to = reduced interoperability and less security. I have no doubts that was a = wrong decision. >>>>> >>=20 >>>>> >> In its current form, there is not enough support to have this = document as a WG item. >>>>> >>=20 >>>>> >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >>>>> >>=20 >>>>> >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. >>>>> >>=20 >>>>> >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. >>>>> >>=20 >>>>> >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >>>>> >> Is this what others want as well? >>>>> >>=20 >>>>> >> After these items have been addressed we believe that more = folks in the group will support the document. >>>>> >>=20 >>>>> >> Ciao >>>>> >> Hannes & Derek >>>>> >>=20 >>>>> >>=20 >>>>> >>=20 >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> >=20 >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > OAuth@ietf.org >>>>> > = https://www.ietf.org/mailman/= listinfo/oauth >>>>>=20 >>>>> =E2=80=94 Roland >>>>>=20 >>>>> =E2=80=9DEverybody should be quiet near a little stream and = listen." >>>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth = Krauss >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The question is what counts as re-authentication.  

It may be that the = environment is changing.  Re-prompting for a password in many cased = just tells you the user has a form filler.

It may be better to use risk based = factors such as prompting for a pin, or using a local passive biometric, = eg has the phone got screen lock and is it in proximity to the persons = smart watch etc.   

What google seems to be doing is using = the amr to say how they did the last authentication and leave it up to = the client to decide if it is good enough.

Simple always ask for a password may no = longer provide the security that most people think it is = giving.

Looking = at what enterprise customers are asking for, they are becoming more = concerned with checking the MDM posture of the device at = authentication.

This is a larger conversation about authentication context = and methods.

The= establishment of the amr registry will provide a place to document a = part of this, however authentication context (there is already a = registry) and amr values themselves are probably out of scope for this = WG.

John = B.


On = Feb 15, 2016, at 8:22 PM, Jim Manico <jim@manicode.com> = wrote:

Polite comment, = Google in general is pretty "open" about session management in general - = long idle timeout and no apparent absolute timeout. For a bank or other = organization that produces high risk software, this is not standard = practice. Re-authentication is a critical security boundary, not = prompting the user for re-authentication credentials is unacceptable in = those environments.

I may be jumping in out of context, but fair?
--
Jim Manico
@Manicode
+1 (808) = 652-3805

On Feb 15, 2016, at = 3:36 PM, William Denniss <wdenniss@google.com> wrote:

We return 'amr' claims in ID = Tokens if "max_age" is requested (per OpenID Connect), e.g.:

https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%= 3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type=3Dcode&a= mp;client_id=3D407408718192.apps.googleusercontent.com&scope=3Dopenid+= profile&approval_prompt=3Dforce&access_type=3Doffline&max_age=3D= 1

The reason we do this is to be explicit about how we are = processing the "max_age" reauth request, specifically that we don't = always prompt the user to reauthenticate directly (but do perform = in-session risk analysis).

I can see us potentially using the more generic amr values = like "user", and "mfa" but we will probably avoid very specific ones = like "sms" or "otp" to avoid brittle relationships with RPs. That said, = I don't object to those being in the registry, perhaps there is value in = some tightly coupled enterprise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the = current values.

I don't see any harm in the spec that = establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be = reviewed at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to = be the easiest way to address various needs and concerns. 

 =E2=80=94 Justin

On Feb 13, 2016, at 11:08 = AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht = --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably don=E2=80=99= t have is that an IANA registry can only be established by an RFC.  Non-RFC = specifications, such as OpenID specifications, can *register*= values in a registry, but they cannot *establish* = a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA = registries.  Otherwise, they would = have.

 

Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications.  = This specification is one example of doing this.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = torsten@lodderstedt.net
Sent: = Saturday, February 13, 2016 6:37 AM
To: John = Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized

 

We clearly have = this problem between oauth and oidc. Just take a look at the discovery thread.

According= to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I = think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we = will need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still = have almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of = oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCnglich= e Nachricht --------
Von: Roland Hedberg = <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I = believe that it=E2=80=99s now = ready for working group = adoption.
>>
= >>           =             &n= bsp;           &nbs= p;            =            -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.htm= l
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.htm= l
>> Most of them require more than just editing work. For example, methods listed are really not = useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> = _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody = should be quiet near a little stream and listen."
>=46rom =E2=80=99Open = House for Butterflies=E2=80=99 by = Ruth Krauss


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0-- --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTUyMzUwMzhaMCMGCSqGSIb3DQEJBDEWBBRQx+tV5njBTnMKHtGdrWEX 4Tep5zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCrdExTbAAOURhOB8K+lHQuOCHNY9oZ9GRDyv+Vw7kZMz1LjIrA2Jnu AaNaPy179D3jLtaQrWTu8WagSsDMf5OkQ0teo/7bgBb2TarnszxdrcVV48pyvdnlbI9VOeOH4gtF T/R8FrLoWbKFS5JzXW7wSxCzatKTzew586rQ6eWgqYfkqXKFo9XfRJiTCDo3H8KnaYPqcQqqvF8n v6FcJNxRjNHU6WGVpfLBd2zd7N35ZVJPi7dD26wOSGgJkjN3kOzmIG1ZRt3bBIDzoxFI4lfvwXKI huSwyWlb7ly0gfiUdiTy48JUwX6vsxLyDZ+GDQ0WRgrwkN0UuEJkQ1iUFl+4AAAAAAAA --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39--