<div dir="ltr"><div><br></div><div>attending </div><div><br></div><div>John Bradley, Paul Madsen, Mike Varley, Darren Platt, Thomas DeBenning,Brian Campbell,Nat Sakimura, Morteza Ansari </div><div><br></div><div style>Paul taking notes</div>
<div style><br></div><div>Nat asks whether this is 1st or 2nd meeting of working group , John confirms we adopted scope at 1st meeting. provisionally accepted input document , presuming IPR agreements have been accepted - which has happened</div>
<div><br></div><div>Nat moves to accept previously provisionally accepted document as accepted input doc</div><div>John seconds</div><div><br clear="all"><div style>John moves that the input document become the basis for workgroup activities</div>
<div style>Darren seconds</div><div style><br></div><div style>John took the group through the current document.</div><div style><br></div><div style>nat asked about Step 5 - should be both arrows up/down</div><div style>
<br></div><div style>Nat posed question about how the TA obtains access tokens - whether from the Token Endpoint or some dedicated API - allowing for triples to be returned</div><div style><br></div><div style>John points out advantage of Token Endpoint, allowing for the TA to authenticate when obtaining access tokens</div>
<div style><br></div><div style>We can have </div><div style><br></div><div style>1) TA uses refresh token on call to Token Endpoint</div><div style>2) TA uses access token on call to 'AppInfo' API</div><div style>
3) both </div><div style><br></div><div style>More discussion</div><div style><br></div><div style>Nat suggests the TA might , on install, register a key pair, or do dynamic registration, to use subsequently to the AS</div>
<div style><br></div><div style>Nat suggests that credential provisioning is important . John agrees but argues that this spec neednt necessarily specify that</div><div style><br></div><div style>Consensus is that TA SHOULD be a confidential client, as opposed to MUST</div>
<div style><br></div><div style>Nat points out that the TA aggregates risk, and that may push the SHOULD to MUST for deployments</div><div style><br></div><div style>Morteza asks about how discovery might work, and goes onto ask about the scope of interoperability, ie is the goal that a given app work with any TA, or a specific TA?</div>
<div style><br></div><div style>John answer is that we need to explore what the mobile OSs provide</div><div style><br></div><div style>Morteza asks 'Will we have different bindings for the different OSs'? Things will change.</div>
<div style><br></div><div style>John suggests that the bindings will change evolve as the OSs change, and so may not belong in the same document. </div><div style><br></div><div style>Group agrees. What to call it? Or are there individual docs for each OS & version?</div>
<div style><br></div><div style>John will take first stab at pulling the content out.</div><div style><br></div><div style>John asks 'whether the AppInfo API definition belongs in the main spec?'</div><div style>Group says keep it in for now</div>
<div style><br></div><div style>Discussion as to what the TA should pass to the apps, just an access token, or also a refresh token, or maybe an id_token etc? Future discussion required</div><div style><br></div><div style>
Brian has questions/concerns about the TBD of 7.4.3, ie how a TA uses an id-token to obtain access tokens. More discussion required</div><div style><br></div><div style>People dont like the 'provisioning' in current spec title - has existing connotation. Agree to change spec names to</div>
<div style><br></div><div style>Native Apps Core</div><div style>Native Apps OS Bindings</div><div style><br></div><div style>Agree to have call bi-weekly, alternating between Tuesday 10 AM EST & Wednesday 6 PM EST.</div>
<div style><br></div><div style><br></div><div style><br></div><div style><br></div>-- <br>Paul Madsen<br>
</div></div>